invention-intake

Invention disclosure first-pass screen — novelty, obviousness, §101 eligibility, bar dates, detectability, and strategic value. Use when an invention disclosure comes in and needs triage on whether to pursue a prior-art search and patent counsel review, investigate further, or decline.

By anthropics · 557 installs

npx skills add anthropics/claude-for-legal --skill invention-intake

Source repository · Upstream listing

/invention intake This is a first pass screen by a non specialist, not a patentability opinion. The screen never concludes that an invention is patentable — it concludes that it passes the initial screen and warrants a prior art search and registered practitioner review, that it needs more information, or that it hits a disqualifier. A prior art search is a separate step; this skill does not do one. Instructions 1. Read ~/.claude/plugins/config/claude for legal/ip legal/CLAUDE.md . If it contains [PLACEHOLDER] , stop and direct to /ip legal:cold start interview . If the practice profile shows trademark or copyright only (no patent practice), say so and route the user elsewhere — this is the wrong tool. 2. Follow the workflow below. 3. Run intake. If the user pasted or uploaded a disclosure, read it. If not, ask the seven intake questions (what / problem / differences / inventors / public disclosure / status / technology area) in one batch and wait. 4. Run the six screens: novelty signals, obviousness flags, § 101 eligibility, public disclosure / bar dates, detectability, strategic value. Each screen gets a ✓ / 🟡 / 🔴 verdict with one line reasoning. 5. Write the invention screen memo to the matter folder (if a matter is active) or the practice outputs folder. Apply the work product header per role. 6. Bottom line verdict: PURSUE (schedule prior art search and attorney review) / INVESTIGATE (needs more info on a specific open item) / DECLINE (state the concrete reason). Never say "patentable." 7. Close with the decision tree (prior art search / inventor follow up / specialist review / decline + thank you / trade secret route) and the non lawyer gate if the role is non lawyer. 8. If the screen hit a within one year US disclosure or any public disclosure with foreign rights in scope, flag at the top: time sensitive . This skill never concludes that an invention is patentable. If uncertain, flag — a registered patent attorney or agent decides. Examples (And the skill will ask for the invention, the problem it solves, how it differs, inventors, public disclosure status, usage status, and technology area.) THIS IS A FIRST PASS SCREEN, NOT A PATENTABILITY OPINION Say this at the top of every output. Do not drop it, do not soften it. This is a first pass screen by a non specialist, not a patentability opinion. A patentability opinion requires a prior art search, full claim construction, and the judgment of a registered patent attorney or agent. This screen does not do a prior art search, does not assess what is in the art, and does not construct claims. It screens for the obvious disqualifiers (the invention is already on the market, it was publicly disclosed two years ago, it is plainly an abstract idea) and the obvious go aheads (new mechanism, technical advance, recent conception, in use secretly). Everything in between needs a prior art search and a registered practitioner's review. This screen never concludes that something is "patentable" — it concludes that it "passes the initial screen, warrants investigation" or that it does not. Under flagging an invention that should have been filed is a one way door — the one year US bar runs, foreign rights are lost at first public disclosure, the competitor files first. Over flagging just means a prior art search that comes back empty. Stay on the two way door side. Matter context Matter context. Check Matter workspaces in the practice level CLAUDE.md. If Enabled is ✗ (the default for in house users), skip the rest of this paragraph — skills use practice level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run /ip legal:matter workspace switch <slug or say practice level ." Load the active matter's matter.md for matter specific context and overrides. Write outputs to the matter folder at ~/.claude/plugins/config/claude for legal/ip legal/matters/<matter slug / . Never read another matter's files unless Cross matter context is on . Invention disclosures are particularly common candidates for clean team or heightened confidentiality at matter open. Respect the matter's confidentiality marking from matter.md . Invention content is inherently sensitive — do not summarize, quote, or reference it outside privileged channels. Load the practice profile first Before reading the disclosure, read ~/.claude/plugins/config/claude for legal/ip legal/CLAUDE.md . If it is missing or still contains placeholders, stop and run /ip legal:cold start interview . The practice profile tells you: The company's patent filing strategy — offensive (building an assertion portfolio), defensive (filing to protect freedom to operate), hybrid, or licensing revenue. This determines the strategic value bar. The technology areas of interest — where the company files and where it does not. An invention that falls outside the areas of interest is often a decline even if the technical screen is clean. The filing budget posture — aggressive (file everything that passes the screen), selective (file the best few), or minimal (only what the business needs to protect). This shapes the output's recommendation. The approval chain — who signs off on a filing decision, and who the invention gets routed to if it passes the screen. If the practice profile shows trademark only or copyright only (no patent practice), this skill is the wrong tool — say so and route the user elsewhere. Workflow Step 1: Intake the disclosure If the user pastes or uploads a disclosure, read it. If not, ask — in one batch, not one at a time: To screen this, I need: 1. What is the invention? In plain language — what does it do, what makes it work, what is the key idea. 2. What problem does it solve? What was broken or missing before. 3. How does it differ from what existed before? What did people do previously? What does this do differently? 4. Who invented it, and when? Names and rough conception date. 5. Has it been publicly disclosed? Published, sold, offered for sale, demonstrated at a conference, shown to a customer under an NDA, posted to a public repo, written up in a paper, included in a product release note. If yes, when and where. 6. Is it in use or planned? Shipping now? In a limited pilot? On the roadmap? Still on paper? 7. What technology area? (Software, hardware, mechanical, biotech, method of doing business, AI/ML, etc.) Wait for answers. Do not proceed on a half disclosure — a screen of "a new machine learning thing that helps users" is worse than no screen. If the disclosure is a formal invention disclosure form (IDF) from an IPMS or a template, extract these fields from the form and only ask for what's missing. Step 2: Screen against the checklist Walk the five screens in order. Each produces a per screen verdict: ✓ clear , 🟡 flagged — needs further look , or 🔴 red flag . Explain the reasoning briefly; do not pad. Screen 1: Novelty signals Does the disclosure describe something new? This is not a full novelty analysis — that requires a prior art search. This screens the disclosure's own description for self evident novelty problems. Red flags (🔴): "We just applied [known technique] to [new domain]" — e.g., "we took gradient boosting and applied it to predicting customer churn" "It's like [existing product] but for [X]" — Uber for dog walking framing "Competitors do something similar" — if the disclosure itself says this, novelty is in question The disclosure describes a feature of an existing public product with minor tuning Green flags (✓): A new mechanism — a new way of doing the thing, not a new application A new combination that produces an unexpected result (not just additive — "faster," "smaller," "cheaper" are sometimes unexpected, sometimes obvious) Solving a problem the field had not solved — the disclosure explains why the prior approaches failed and how this one doesn't Flagged (🟡): anything ambiguous. Prior art search settles it. Screen 2: Obviousness flags Would a person of ordinary skill in the art (POSA) have arrived at this combination based on what's known? This is a screen, not a § 103 analysis — flag for further investigation, never conclude obviousness or non obviousness. Red flags (🔴) for further investigation: Combining known elements in a predictable way — putting a known sensor on a known machine to measure a known thing Routine optimization — "we tuned the existing parameter from X to Y and got better results" Design choice without functional advantage — aesthetic, ergonomic, or stylistic changes that don't change how the thing works Obvious to try — one of a small number of identified solutions with a reasonable expectation of success Green flags (✓): Teaching away — prior art expected the opposite result or said this approach wouldn't work Unexpected result — the combination produces something the POSA would not have predicted Long felt need — the problem was known, and attempts to solve it had failed Screen 3: Subject matter eligibility (§ 101) Is this an abstract idea, law of nature, or natural phenomenon? This is the hardest screen, the most litigated, and the one most likely to require a specialist read. Flag anything borderline for specialist review. Red flags (🔴) for § 101: Pure business method without technical implementation — "a method of pricing widgets more efficiently" Mathematical algorithm on its own — even as dressed up in pseudocode Organizing human activity — scheduling, pairing, matching, reviewing — without a technical improvement Claim that reads as " do [known thing] on a computer " with no improvement to the computer itself AI/ML invention where the claim is the function (recommend, classify, predict) without the specific technical means that improves how the computer performs the function Green flags (✓) for software/AI inventions: Technical improvement to the computer itself — new architecture, new training technique, new hardware/software interface, new security mechanism Specific technical means, not just results Improvement to a technical field (image processing, compression, cryptography, robotics) with the technical means described Anything borderline gets a 🟡 with "§ 101 — route to specialist for Alice/Mayo analysis." A non specialist should not call a close § 101 question. For biotech / diagnostic inventions, also flag for § 101 if the claim recites: A natural correlation ("if level of X is above Y, patient has Z") A naturally occurring substance (isolated gene, natural product) without significant human modification §101 is a US standard. Other patent offices are different. The EPO's "technical effect" test (Art. 52 EPC) is materially more permissive for software and AI inventions than US §101 post Alice . JPO and CNIPA also apply different standards. An invention that screens 🔴 under Alice may be perfectly eligible at EPO/JPO/CNIPA. When the practice profile includes non US jurisdictions: "This §101 screen is US only. If you file internationally, the eligibility posture may be different — particularly for software, AI/ML, and business methods, which EPO is more permissive on. Don't decline based on US §101 alone if you have EP/JP/CN filing plans." Screen 4: Public disclosure / bar dates Has the invention been disclosed, sold, offered for sale, or publicly used? This is the most time sensitive screen — the answer can kill patentability absolutely, or start a clock that cannot be stopped. Categorize the disclosure status: 🔴 Likely barred: Publicly disclosed, sold, or offered for sale more than 12 months ago