Use when a client has received a cease-and-desist letter or similar IP demand and needs a structured triage memo — covering the assertion, exposure, response options, and immediate actions — for attorney review before responding.
When to use
A client has received a cease-and-desist letter, demand letter, or similar written IP demand asserting trademark, copyright, patent, trade secret, or related rights.
A user asks to "review this C&D," "what does this letter mean," or "what should we do about this demand."
A client wants a structured briefing document to share with outside IP counsel.
A client needs to understand the range of response options and their tradeoffs before consulting an attorney.
Required inputs
The inbound letter: the full text, or a detailed description including: the sender's identity; the right(s) asserted (trademark, copyright, patent, trade secret, or other); the alleged infringing conduct; the specific demand (cease use, remove content, pay damages, execute a license, etc.); any stated deadline; and the overall tone.
The client's factual self-assessment: the client's honest account of whether it is actually doing what the letter alleges, and any relevant context (when the conduct began, whether it was aware of the asserted right, any prior dealings with the sender).
If the letter text or description is not provided, stop and request it before proceeding. If the client's factual self-assessment is not provided, flag it as missing and note that the exposure assessment will be incomplete without it. Never fabricate any element of either input.
Optional input: the client's IP enforcement posture or policy, if available, which may inform the recommended response approach.
Use when preparing a takedown notice for infringing content or evaluating a takedown notice received against the user's content, including whether a counter-notice may be appropriate.
When to use
A user says "someone is using my [image/video/code/article] without permission" and wants to have it removed from a platform.
A user wants to draft a DMCA notice to send to a hosting provider, platform, or ISP.
A user has received a takedown notice and wants to understand what it means or whether to file a counter-notice.
A user asks whether they have a copyright claim against content appearing online.
A user needs to understand the required elements of a valid DMCA notice or counter-notice.
Required inputs
For Mode A (Preparing a Takedown Notice):
Description of the copyrighted work (title, type, date of creation or publication, and where the original can be found).
The user's ownership or authorization basis (original author, rights holder, authorized agent — specify which).
The URL or specific location of the allegedly infringing material.
The platform or service provider receiving the notice, and its designated DMCA agent contact if known.
The user's contact information (name, address, email, phone) for inclusion in the notice.
For Mode B (Evaluating a Received Notice):
The full text of the received takedown notice.
The user's description of the content that was taken down or flagged.
The user's basis for believing the content is lawful (ownership, license, fair use, other).
If the required inputs are not provided, stop and request them. Do not fabricate ownership information, URLs, contact details, or facts about the allegedly infringing material.
Use when a client needs a first-pass, structured triage of a potential intellectual property infringement issue — identifying the key factors, flagging their direction, and routing to IP counsel — without concluding whether infringement occurred.
When to use
A client believes someone may be infringing its intellectual property right and wants a preliminary read of the situation before engaging IP counsel for an enforcement action.
A client has received an informal infringement complaint, a demand, or internal notice that its own product or conduct may infringe a third party's intellectual property, and wants a preliminary structured assessment before engaging IP counsel.
A user asks to "triage this IP issue," "does this look like infringement," "what are the key factors," or similar first-pass framing.
A client wants a structured briefing document to share with outside IP counsel to frame the engagement efficiently.
Required inputs
The IP right(s) at issue: identify which type(s) — trademark, copyright, patent, trade secret, or some combination. If the type is unclear, flag it and attempt to identify the most likely right from the described facts before proceeding.
The party posture: is the client the potential senior party (owns or claims the right and believes it is being infringed) or the accused party (may be infringing someone else's right)? If unclear, request clarification before proceeding; the posture governs the routing recommendations.
The jurisdiction or governing law: identify the jurisdiction or legal system governing the dispute. If not provided, flag as [CONFIRM: governing law and jurisdiction] and note that the applicable factor framework cannot be confirmed without it.
The relevant facts and evidence: a description or copy of the allegedly infringing material, the asserted right (e.g., the claimed mark, the asserted work, the patent claims at issue, or the trade secret), and any known dates, priority dates, registration numbers, or registration status.
Timing information (if known): when the potentially infringing conduct began, any relevant priority or creation dates, and whether there is a known complaint or demand date. Timing may bear on whether a limitations or laches clock is relevant — but no clock is computed in this memo [deadline verification required].
If any required input is missing, stop and request it before proceeding, or note clearly that the analysis covering that input is incomplete. Never fabricate facts, registration details, priority dates, or claim language.
Optional input: the client's IP enforcement posture or policy, if available, which may inform the recommended next steps and the threshold for action.
Use when a user wants a structured first-pass screen of a proposed invention to assess whether it warrants patent-counsel attention, with filing-deadline urgency flagging.
When to use
A user presents a new invention and asks whether it is worth pursuing a patent.
An engineer, product team, or inventor needs a structured disclosure captured before meeting with patent counsel.
A user wants to understand whether public-disclosure timing creates an urgent filing concern.
A user needs a first-pass triage to decide whether to commission a formal patentability search and opinion.
A user wants a structured intake document to brief patent counsel efficiently.
Required inputs
The following information is needed to run the screen. Provide either a full written disclosure document that covers these points, or answers to each intake question individually.
Technical essence: what the invention does and how it works, in plain language.
Problem solved: the technical or practical problem the invention addresses, and why existing approaches fall short.
Points of distinction: how the invention differs from known prior approaches — in the inventor's own words, without legal characterization.
Inventors and conception date: names of all individuals who contributed to the inventive concept, and the date (or approximate date) the invention was first conceived. [CONFIRM: conception date with each named inventor]
Public-disclosure history: any public disclosures already made — including conference presentations, papers, preprints, product launches, trade-show demonstrations, press releases, social media posts, open-source commits, or any disclosure not protected by a non-disclosure agreement — with dates and venues. If all disclosures were made under NDA, confirm the NDA was in place before disclosure. [CONFIRM: whether any disclosure was made without NDA coverage]
Usage and commercialization status: whether the invention is already in a shipped product, a limited pilot, on the product roadmap, or described only internally or in a publication.
Technical area: the general field or domain (e.g., software, mechanical, biotech, chemical, electrical) to help route the disclosure to the right specialist.
If a disclosure document or answers to the above questions are not provided, stop and request them. Do not proceed on a partial or half-disclosure; an incomplete intake produces an unreliable screen.
Use when reviewing the open-source licenses present in or proposed for a project to identify compliance obligations and flag compatibility or disclosure risks for attorney review.
When to use
A user asks to "check our open-source dependencies" or "tell me what our OSS obligations are."
A project is preparing for a product launch, M&A due diligence, or investment round and needs a license inventory review.
A team is evaluating whether to change how software is distributed (e.g., from internal use to SaaS to binary distribution) and wants to understand the license implications.
A user has an SBOM (Software Bill of Materials), dependency manifest (package.json, requirements.txt, go.mod, pom.xml, Cargo.toml, etc.) or similar inventory and wants it reviewed for license risk.
A user is selecting an open-source license for a new project and wants to understand compatibility with existing dependencies.
A user has received an OSS compliance audit finding or a license violation notice.
Required inputs
Component inventory: a list of open-source components and their associated licenses — from an SBOM, dependency manifest, or manual inventory. Each entry should include: component name, version (if available), and license identifier (SPDX identifier preferred, e.g., MIT, Apache-2.0, GPL-3.0-only).
Distribution model: how the software is or will be delivered. Examples: internal use only (never distributed outside the organization), distributed binary or package (to end users or customers), SaaS / network service (users access the software over a network but receive no binary), open-source release (source code is published). More than one may apply.
Proposed outbound license (if applicable): the license the user intends to apply to their own code.
If the component inventory is not provided, stop and request it. If the distribution model is not provided, flag it as unknown — many license obligations depend on it and the review will be incomplete without it.
Use when a user needs a structured first-pass review of potential patent blocking issues for a product, process, or feature against a set of identified patents, to flag risk areas and route findings to patent counsel for a formal freedom-to-operate opinion.
When to use
A user asks to "check if our product is blocked by these patents" or "do an FTO triage" against a defined list of patents.
A product, process, or feature is approaching launch and the team wants a structured first-pass memo to brief patent counsel.
A user has a set of identified patents and needs a systematic, element-by-element first-pass read organized for counsel review.
A user needs to document preliminary patent risk considerations before engaging in a licensing or design-around discussion with counsel.
Required inputs
Technical description: a clear, precise description of the product, process, or feature being analyzed — the technical essence, not marketing language. The more specific the description, the more useful the triage.
Supporting technical detail: any additional specifications, drawings, flowcharts, claim charts, or design documents the user can provide.
Jurisdictions: the countries or regions where the product will be made, used, sold, offered for sale, or imported. Different jurisdictions may have different governing standards. [verify jurisdiction]
Patents in scope: the patents the user is already aware of — identified by patent number, publication number, or pasted claim text. This skill does NOT run a patent-database search.
Timing: the intended launch date or go/no-go decision deadline. [deadline verification required]
If the technical description is not provided, stop and request it before proceeding. If no patents are identified, stop and explain that this skill analyzes only patents the user supplies — it does not conduct a patent search. If jurisdiction is not provided, flag it as unknown and note that the triage will be incomplete and potentially misleading without it.
Use when a user wants a preliminary triage of a proposed brand name, product name, or logo before engaging trademark counsel for a formal clearance search.
When to use
A user asks to "check if a name is available" or "see if we can trademark this."
A user wants to know if a proposed brand name, product name, or slogan is likely to face trademark issues.
A client is in early brand development and wants a structured starting point before commissioning a full clearance search.
A user needs a triage summary to brief trademark counsel efficiently.
A user asks what a formal trademark clearance process involves and what inputs counsel will need.
Required inputs
The proposed mark: exact name, slogan, or description of the logo/design element.
Goods and/or services: a plain-language description of the products or services the mark will identify (e.g., "mobile app for personal finance," "organic coffee beans sold online").
International Classification (Nice Classes): if the user knows the relevant class(es), capture them; if unknown, note that class identification is an attorney task and provide a general description only.
Geographic markets: primary and secondary markets (e.g., United States, EU, Canada).
Intended use: whether use has already begun (use-in-commerce) or is planned (intent-to-use), and approximate timing.
If the proposed mark text is not provided, stop and request it before proceeding. If goods/services or geographic market are not provided, flag them as unknown and note that the triage will be incomplete without them.