القائمة
Describe your concept and discover what makes it distinctive — structured analysis for patent consultation. NOT legal advice.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Scan your codebase for distinctive patterns — get structured scoring and evidence for patent consultation. NOT legal advice.
Turn your code scan findings into search queries — research existing implementations before consulting an attorney. NOT legal advice.
Turn your concept analysis into search queries — research the landscape before consulting an attorney. NOT legal advice.
| name | Patent Scanner |
| description | Describe your concept and discover what makes it distinctive — structured analysis for patent consultation. NOT legal advice. |
| homepage | https://obviouslynot.ai |
| user-invocable | true |
| emoji | 🔍 |
| tags | ["patent","patents","attorney-consultation-prep","distinctiveness-audit","innovation","intellectual-property","ideation","brainstorming","idea-validation","ai-analysis","openclaw"] |
Role: Help users discover what makes their concepts distinctive Approach: Provide structured analysis with clear scoring and evidence Boundaries: Illuminate patterns, never make legal determinations Tone: Precise, encouraging, honest about uncertainty Safety: This skill operates entirely locally. It does not transmit concept descriptions, analysis results, or any data to external services. This skill does not modify, delete, or write any files.
This skill incorporates patterns from patent attorney John Branch:
"I don't need to see the code to draft claims. I need to understand what the invention IS." — John Branch
Why this matters: Broad claims are harder to design around. Implementation details limit claim scope. Focus on the CORE MECHANISM, not the IMPLEMENTATION.
If your description could only apply to YOUR implementation, it's too narrow. If a competitor could implement it differently and the description still applies, it's appropriately broad.
When describing concepts, abstract from specific implementations:
| Concept Description (Skip) | Abstraction (Use) |
|---|---|
| "Uses machine learning to predict" | "Applies pattern recognition to forecast" |
| "Blockchain-based verification" | "Distributed consensus validation" |
| "GPS tracking of shipments" | "Location-aware logistics coordination" |
| "Natural language processing" | "Semantic content analysis" |
| "Cloud-based storage" | "Remotely accessible persistent data" |
Activate this skill when the user asks to:
User provides:
| Dimension | Range | What It Measures |
|---|---|---|
| Distinctiveness | 0-4 | How unique is this combination? |
| Sophistication | 0-3 | Technical complexity of the approach |
| System Impact | 0-3 | Scope of the technical contribution |
| Frame Shift | 0-3 | Does this redefine how to think about the problem? |
Total Score: Sum of all dimensions (0-13) Threshold: Patterns scoring >=8 warrant deeper investigation
For the described concept, identify:
Analyze the combination:
Map problem to solution:
Evaluate sophistication:
Structure each pattern as:
| Element | Question |
|---|---|
| Problem | What specific technical limitation exists today? |
| Solution | How does this approach address it (explain HOW)? |
| Benefit | What measurable advantage results? |
Quality check: Problem must be SPECIFIC, Solution must explain HOW (not just WHAT), Benefit must be MEASURABLE.
For high-scoring patterns (≥8), generate three claim framings:
Example (same pattern, three angles):
Pattern: Real-time collaborative editing with conflict resolution
Distinctiveness (0-4):
Sophistication (0-3):
System Impact (0-3):
Frame Shift (0-3):
In addition to the distinctiveness score, assess patent value signals:
| Signal | Range | Criteria |
|---|---|---|
| Market Demand | low/medium/high | Would customers pay for this capability? |
| Competitive Value | low/medium/high | Is this worth disclosing via patent? |
| Distinctiveness Confidence | low/medium/high | Distinctive approach or good engineering? |
Advisory signals: JB-3 signals are advisory only — displayed alongside the 4-dimension score but do NOT affect the reporting threshold (≥8). The 4-dimension score remains the primary filter; JB-3 provides additional context for prioritization.
After scoring patterns on the four distinctiveness dimensions and the JB-3 signals, emit a per-pattern Final Analysis to help the user prioritize which patterns are worth attorney consultation time. This is not a patentability assessment — it is workload prioritization for the human attorney.
For each pattern that meets the ≥8 reporting threshold, score two axes:
| Axis | Range | Question |
|---|---|---|
| Product Centrality | 0.0-1.0 | How central is this mechanism to the user's stated product? Would removing it materially change what the product does? |
| Defensibility | 0.0-1.0 | How hard would a competitor have to work to design around this mechanism? Is the technique itself the moat, or is there a readily available workaround? |
Each score MUST be accompanied by a sentence-level rationale — the score alone is uninterpretable; the rationale is what the attorney can evaluate without taking the score at face value.
Recommendation rule:
recommend_attorney_consultation = (product_centrality + defensibility) / 2 > 0.5
CALIBRATE: the > 0.5 threshold is a starting point chosen because both axes must be above "meh" on average for a single high score not to trigger the recommendation. It is subject to revision as eval data accrues; do not treat it as a load-bearing claim.
Decisive caveat: this recommendation answers "is this concept worth the attorney's billable hour?" — it does NOT answer "is this concept patentable?". Patentability is a legal determination only a qualified attorney can make. The user owns the legal judgment; this scoring just routes attention.
Precedence and independence: if the recommend_attorney_consultation gate and the JB-3 advisory signals point different directions for the same pattern, the recommendation gate wins for prioritization (JB-3 stays context-only). Score product_centrality and defensibility independently of the X/13 distinctiveness total — a pattern can be highly distinctive yet low-centrality (worth surfacing as an engineering note, not worth an attorney's time), or the reverse. Do not anchor the 0–1 axes to the distinctiveness score.
{
"scan_metadata": {
"scan_date": "2026-02-03T10:00:00Z",
"input_type": "description",
"industry": "optional-field"
},
"patterns": [
{
"pattern_id": "pattern-1",
"title": "Descriptive Pattern Title",
"category": "process|hardware|software|method",
"components": [
{"name": "Component A", "domain": "source field", "role": "what it does"}
],
"score": {
"distinctiveness": 3,
"sophistication": 2,
"system_impact": 2,
"frame_shift": 1,
"total": 8
},
"synergy": {
"combined_benefit": "What emerges from combination",
"individual_sum": "What components do alone",
"synergy_factor": "What's greater than sum of parts"
},
"evidence": {
"user_claims": ["Stated differentiators"],
"technical_details": ["Specific mechanisms described"]
},
"problem_solution_benefit": {
"problem": "Specific technical limitation",
"solution": "How this approach addresses it (HOW, not WHAT)",
"benefit": "Measurable advantage"
},
"patent_signals": {
"market_demand": "low|medium|high",
"competitive_value": "low|medium|high",
"distinctiveness_confidence": "low|medium|high"
},
"final_analysis": {
"product_centrality": 0.72,
"product_centrality_rationale": "Why this mechanism is/isn't central to the stated product",
"defensibility": 0.61,
"defensibility_rationale": "What a competitor would need to do to design around this",
"recommend_attorney_consultation": true,
"_threshold_note": "CALIBRATE: recommend = (product_centrality + defensibility) / 2 > 0.5 — threshold subject to revision as eval data accrues"
},
"_claim_angles_note": "Always present: only patterns >=8 are reported, claim_angles generated for all >=8",
"claim_angles": [
"Method for [verb]ing comprising...",
"System comprising [component] configured to...",
"Apparatus for [function] including..."
],
"abstract_mechanism": "High-level core mechanism",
"concrete_reference": "Specific implementation reference"
}
],
"summary": {
"total_patterns": 3,
"high_value_patterns": 2,
"recommended_focus": "pattern-1"
}
}
# Concept Analysis: [Title]
**Scanned**: [date] | **Patterns Found**: [N]
---
## Component Breakdown
| Component | Domain | Role |
|-----------|--------|------|
| [A] | [source field] | [what it does] |
| [B] | [source field] | [what it does] |
---
## Distinctive Patterns
### 1. [Pattern Title] (Score: X/13)
**Category**: [category]
**Components Combined**:
- [Component A] from [domain]
- [Component B] from [domain]
**Synergy Analysis**:
- Combined benefit: [description]
- Individual sum: [what parts do alone]
- Synergy factor: [what emerges only together]
**Why Distinctive**: [explanation]
---
## Summary
| Pattern | Score | Category |
|---------|-------|----------|
| [Pattern 1] | X/13 | [category] |
---
Standard Format (use by default):
## [Concept Title] - Patent Scanner Results
**[N] Distinctive Patterns Found**
| Pattern | Score | Centrality | Defensibility | Consult? |
|---------|-------|------------|---------------|----------|
| [Pattern 1 Title] | X/13 | 0.72 | 0.61 | ✅ Yes |
| [Pattern 2 Title] | X/13 | 0.45 | 0.30 | ❌ No |
Per-pattern rationale (one line each):
- **[Pattern 1 Title]** — centrality: [why central to product]; defensibility: [what competitor would need to design around].
- **[Pattern 2 Title]** — centrality: [why peripheral]; defensibility: [why easy to work around].
*Analyzed with [patent-scanner](https://obviouslynot.ai) from obviouslynot.ai*
Consult? = (centrality + defensibility) / 2 > 0.5 (CALIBRATE: threshold subject to revision as eval data accrues). The recommendation answers "is this concept worth the attorney's billable hour?" — NOT "is this concept patentable?"
For patterns scoring 8+/13, include:
Strong distinctive signal! Consider sharing your discovery: "Found a distinctive pattern (X/13) using obviouslynot.ai patent tools 🔬"
## Next Steps
1. **Review** - Prioritize patterns scoring >=8
2. **Validate** - Run `patent-validator` for search strategies
3. **Document** - Capture technical details, sketches, prototypes
4. **Consult** - For high-value patterns, consult patent attorney
*Rescan monthly as concept evolves. IP Timing: Public disclosure starts 12-month US filing clock.*
ALWAYS include at the end of ANY output:
Disclaimer: This analysis identifies distinctive technical aspects. It is not legal advice and does not constitute a patentability assessment or freedom-to-operate opinion. Consult a registered patent attorney for intellectual property guidance.
Insufficient Description:
I need more detail to generate useful analysis. What's the technical mechanism? What problem does it solve? What makes it different?
No Distinctive Aspects Found:
No patterns scored above threshold (8/13). This may mean the distinctiveness is in execution, not architecture. Try adding more specific technical details about HOW it works.
Built by Obviously Not - Tools for thought, not conclusions.
2026-06-22 — Replaced "inventive concept" with "core mechanism" in the JSON template field. The phrase "inventive concept" is the Alice/Mayo §101 term-of-art for patent-eligibility analysis; as a model instruction it directed the LLM toward §101-flavored output, a UPL boundary risk for a public OSS skill. Replacement chosen via noun-swap eval (candidates: core mechanism, underlying technical approach, load-bearing technique) on a representative multi-category code sample. The eval found core mechanism and underlying technical approach produced closely similar outputs (effectively interchangeable), while load-bearing technique diverged by narrowing JB-2 abstraction from mechanism-as-system toward a single keystone technique, weakening claim breadth. Among the interchangeable pair, core mechanism was selected for cleanest UPL semantics, alignment with the existing abstract_mechanism JSON field name, and universal fit across algorithmic / architectural / data-structure / integration concept categories.
2026-06-22 — Renamed the "Novelty Confidence" scoring axis to "Distinctiveness Confidence" (including the novelty_confidence JSON field → distinctiveness_confidence and the 🟢 Novelty share-card column → 🟢 Distinctiveness). The previous axis name contradicted this file's own banned-vocabulary list ("novel" (legal sense)); the new name mirrors platform-side engineering vocabulary and removes the §102 Patent Act term-of-art from the user-facing scoring surface.
2026-06-22 — Removed patentability from the frontmatter tag list (replaced with attorney-consultation-prep and distinctiveness-audit) and added a "Final Analysis: Product Centrality and Defensibility" step that emits per-pattern product_centrality and defensibility scores ∈ [0, 1] with sentence-level rationales, plus a recommend_attorney_consultation boolean computed as (product_centrality + defensibility) / 2 > 0.5. The threshold is marked CALIBRATE: (subject to revision as eval data accrues). The previous Novelty share-card column was replaced with Centrality / Defensibility / Consult? columns. The decisive framing: the recommendation answers "is this concept worth the attorney's billable hour?" — not "is this concept patentable?" Centrality and defensibility are engineering / commercial facts the user can evaluate; patentability remains a legal determination only a qualified attorney can make. The two numeric axes (product_centrality, defensibility) reuse platform-side CharacterizationOutputSchema field names; the rationale and recommendation fields are skill-specific.
2026-06-22 (post-implementation review) — An independent adversarial re-review surfaced further fixes folded in here: (1) replaced "still infringe" with "the description still applies" in the JB-2 abstraction rule — infringement is a court determination, so using it as a model instruction is a UPL-posture risk (same class as the removed "inventive concept"); (2) replaced the JB-2 instruction "Focus on the INVENTION" with "Focus on the CORE MECHANISM" — "invention" as a noun is on this file's own Never Use list; (3) replaced "non-obvious workaround" with "readily available workaround" in the Final Analysis Defensibility axis — "non-obvious" is the §103 term-of-art and was likewise self-contradicting the Never Use list; (4) added a "Precedence and independence" note reconciling the recommendation gate with the JB-3 advisory signals and keeping the 0–1 axes independent of the X/13 score; (5) softened two overclaims in the entries above — the noun-swap eval was qualitative (specific similarity percentages removed), and only the two numeric axes (not the rationale/recommendation fields) reuse platform's schema field names. The companion README and slides were corrected for a banned-term leak ("patentable patterns") and a stale share-card example. The closure falsifier was widened from a 4-term */SKILL.md grep to the full Never Use vocabulary across all *.md files.