patent-filing-qc

分类: 数据库与数据存储 | 上传者: LeonardHope | 下载: 0 | 版本: v1.0（最新）
美国专利申请文件的全面质量控制。当用户要求在提交给 USPTO 之前对专利申请文件进行质量控制、检查、验证或审查时使用。对规范、图纸、ADS、声明、转让和授权书文件执行 70 多项自动和手动检查。检测跨文档不一致、格式问题、缺少必填字段和常见错误。
更新日志: Source: GitHub https://github.com/LeonardHope/Claude-Skill-for-Patent-Filing-Quality-Control
目录结构

当前层级: tree/main/
📁 docs/
- 📄 example-report.png 1.1 MB
📁 scripts/
- 📄 qc_patent_filing.py 257.0 KB
📄 .gitignore 778 B
📄 LICENSE 1.0 KB
📄 README.md 20.7 KB
📄 SKILL.md 17.9 KB
SKILL.md

---
name: patent-filing-qc
description: Comprehensive quality control for U.S. patent application filing documents. Use when the user asks to QC, check, validate, or review patent filing documents before submission to the USPTO. Performs 70+ automated and manual checks across specification, drawings, ADS, declaration, assignment, and power of attorney documents. Detects cross-document inconsistencies, formatting issues, missing required fields, and common errors.
---

# Patent Filing QC

## Overview

This skill provides comprehensive quality control for U.S. patent application filing documents immediately before filing with the USPTO. It systematically checks for internal document errors, cross-document inconsistencies, USPTO compliance issues, and common filing mistakes across all required and optional filing documents.

## When to Use This Skill

Trigger this skill when the user requests any of the following:
- "QC this patent application"
- "Check these filing documents"
- "Validate this patent package"
- "Review this application before filing"
- Any request to quality check, validate, or review patent filing documents

## Workflow

### Step 1: Identify the Documents Folder

Confirm the folder path containing all filing documents. The folder should typically contain:
- Specification PDF (required)
- Drawings PDF (required)
- Application Data Sheet / ADS (required)
- Declaration (eligible for missing-parts under 37 CFR §1.53(f) — see Step 8)
- Assignment (optional but common)
- Power of Attorney (optional)
- `inventors.txt`, `inventors.json`, or `*.eml` (optional — authoritative inventor list)

**Filenames don't matter — the script identifies documents by their *content*, not their names.** A specification named `Application.pdf`, a declaration named `Formals.pdf`, or any other naming convention works as long as the content of the file is recognizable. XFA forms (any PTO/AIA/* form, not just the ADS) are classified by inspecting their embedded XML rather than assuming form type from the filename.

**Format-wise, the spec can be `.docx` or `.pdf`.** The USPTO accepts the specification in Word format, and so does this tool — the classifier reads .docx the same way it reads PDFs and routes it to the Specification slot when its content matches. Other documents (declaration, ADS, drawings, assignment, POA) should be PDFs.

**Note on the ADS:** The USPTO web-fillable ADS (PTO/AIA/14) is an XFA form. The script reads the form's embedded XFA datasets stream directly, so no Adobe Acrobat Pro flattening is required. If the ADS extraction succeeds, the console will show `✅ XFA extraction successful` — every ADS field needed for cross-document checks is then available structured.

### Step 2: Install Dependencies

The user does not need to install anything by hand. If the script fails or warns about a missing dependency, you should install it for them automatically (asking permission once when prompted) and re-run.

Required:
- **PyPDF2** — `pip install PyPDF2 --break-system-packages`. Used for XFA stream extraction and AcroForm inspection. If you see `ModuleNotFoundError: No module named 'PyPDF2'`, install it before re-running.
- **pdfplumber** — `pip install pdfplumber --break-system-packages`. Used as the primary text extractor for spec/declaration/assignment/POA. Preserves paragraph structure that PyPDF2 strips, which the section-detection and claim-parsing checks rely on. Without it, the script falls back to PyPDF2 and many spec-content checks will produce false positives.

For Word (.docx) specifications (the USPTO accepts the spec in .docx; everything else stays PDF):
- **python-docx** — `pip install python-docx --break-system-packages`. Only required if a `.docx` file is present in the folder. The script will print an install hint if it encounters a `.docx` without python-docx installed.

The report is HTML with embedded CSS (no pandoc, no LaTeX, no weasyprint required). If the user wants a PDF copy, they open the HTML in any browser and use File → Print → Save as PDF.

Optional (only for image-based / scanned PDFs that aren't text-searchable; **not** needed for the USPTO XFA-based ADS):
- `pip install pytesseract pdf2image --break-system-packages` + `brew install tesseract poppler`

### Step 3: Run the QC Script

Execute the comprehensive QC check:

```bash
python3 /path/to/skill/scripts/qc_patent_filing.py <folder-path>
```

Optional: Specify output directory for reports:
```bash
python3 /path/to/skill/scripts/qc_patent_filing.py <folder-path> --output-dir <output-path>
```

The script will:
1. Automatically detect all filing documents in the folder
2. Extract text from PDFs
3. Run all 70+ quality control checks
4. Generate one self-contained HTML report file in the output folder

### Step 4: Ensure the Report Is Generated

The script writes one report file:
- `Patent_Filing_QC_Report.html` — self-contained HTML with embedded CSS. Opens in any browser. To save as PDF, the user uses their browser's File → Print → Save as PDF.

There is no longer a separate `.md` or `.pdf` artifact. The HTML is the canonical, visual report. Don't try to convert it to PDF yourself with pandoc, weasyprint, or any other tool — the user can print to PDF from their browser if they want one, and any conversion you'd run would just reintroduce the layout problems that made us stop generating PDFs directly.

**The script's output is canonical. Do not synthesize a substitute or supplemental report under any circumstances.**

- Do NOT write your own narrative report (executive summary, action items, "False Positives Identified," pre-filing checklist, etc.) and save it as `Patent_Filing_QC_Report.html` or any other filename. The script's report is the report.
- Do NOT re-classify, downgrade, override, or annotate findings in the script's report. If a check produces a false positive, the fix goes into the *check logic in the script* — not into a hand-authored override document. Open a follow-up with the user about the bad check; do not silently re-categorize it for them.
- Do NOT supplement the script's findings with your own manual review of the PDFs (POA wording, claim antecedent basis, etc.). Manual review is the user's job, not yours; the report flags items for manual review and stops there.
- If the script crashes or fails to produce the report file, **stop and tell the user** what failed. Do not generate a hand-authored substitute and pass it off as the script's output. The cost of a missing report is small; the cost of a freelance report that *looks* like the skill's output but isn't is high — it conceals what the script actually flagged.

### Step 5: Output Behavior

**IMPORTANT: Do NOT display the report content in the conversation.** The report file speaks for itself. After generation:
1. Confirm to the user that the report has been generated
2. Provide the file path of the `.html` report and tell the user they can open it in a browser
3. Mention only the high-level summary counts (e.g., "3 Critical, 6 Warnings, 36 Passes")
4. Do NOT echo, paste, or reproduce the report content in the chat

**IMPORTANT: Do NOT re-Read the source PDFs after the script has run.** The script already performs the full text/XFA extraction and runs all 70+ checks against the result. Re-reading the PDFs with the Read tool produces no additional information, slows the workflow, and (in default permission mode) generates a permission prompt for every file. Trust the script's output. Only Read individual PDFs if the user specifically asks you to inspect a passage they have a question about.

Reports include:
- **Executive Summary** - Pass/Warning/Critical counts
- **Documents Found** - Which required/optional documents were detected
- **Critical Issues** - Must fix before filing (highlighted first)
- **Warnings** - Should review (may indicate problems)
- **Potential Issues (Low Confidence)** - Possible problems that could not be confirmed with certainty; requires manual verification
- **Detailed Results** - All 70 checks organized by category

### Step 6: Avoiding False Positives

Be careful to avoid these known sources of false positives:

1. **PDF text extraction spacing**: PDF text extraction can merge words together across line breaks or column boundaries (e.g., extracting "testsfor" when the actual document reads "tests for"). Before flagging a missing-space typo, re-examine the extracted text in context. If the supposed typo falls at a line break, column boundary, or page margin, it is likely an extraction artifact, not a real error. Do NOT flag spacing issues unless you are confident the error exists in the actual document.

2. **Patent drafting conventions for sentence structure**: In patent specifications, sentences may begin with subordinate conjunctions like "Although" and contain a complete dependent clause that ends with a period, without an explicit independent/main clause in the same sentence (e.g., "Although FIG. 3 illustrates a set that includes agent A, agent B, and agent C. Other agents can be introduced..."). This is an accepted patent drafting convention. Do NOT flag these as sentence fragments or suggest changing the period to a comma. Patent prose intentionally uses this construction.

3. **Customer numbers in ADS form fields**: When reading customer numbers from ADS screenshots or images, be aware that form field boundaries can visually clip leading digits. A 6-digit number like "150740" may appear to show only "50740" if the leading "1" is at the very edge of the field. Do NOT flag a customer number as incorrect based solely on visual appearance in a tight form field. Cross-reference with other documents (Declaration, POA) to confirm the correct number, and only flag a discrepancy if the number is clearly and unambiguously different.

4. **When confidence is low**: If a potential issue is detected but you cannot confirm it with high confidence (e.g., a possible misread from a screenshot, an ambiguous formatting pattern, or an extraction artifact that might also be a real error), do NOT include it as a Critical or Warning. Instead, include it in a separate **"Potential Issues (Low Confidence)"** section of the report. This section should clearly state what was observed, why confidence is low, and what the user should manually verify. This ensures nothing is silently ignored while keeping the Critical/Warning sections reliable.

### Step 7: Address Issues

If the user asks for help with specific issues found in the report:
1. **Fix critical issues first** - These must be corrected before filing
2. **Review warnings** - These may indicate problems or may be false positives
3. **Complete manual reviews** - Some checks require human verification
4. **Re-run QC after fixes** - Ensure all issues are resolved

### Step 8: Handle "Missing Parts" Filings

If Check 9 reports a CRITICAL issue whose details begin with `ACTION REQUIRED:`, the script has detected a missing document (typically the Declaration) that *might* be intentional under the missing-parts procedure of 37 CFR §1.53(f). When you see this in the report:

1. **Ask the user:** "The folder is missing a Declaration. Is this an intentional missing-parts filing under 37 CFR §1.53(f)?"
2. **If the user says YES (intentional):** Tell them the issue can be downgraded from CRITICAL to a WARNING, and remind them:
   - The **§1.16(f) surcharge fee** is due at or after filing
   - The missing parts (e.g., the declaration) must be filed within **2 months** of the USPTO's Notice to File Missing Parts to avoid abandonment
3. **If the user says NO (oversight):** The missing document(s) must be added to the filing folder before submission. Ask the user to add them and re-run QC.

Do NOT auto-decide for the user. The CRITICAL flag exists to force a conscious confirmation. The same pattern applies to any future missing-parts-eligible documents (oath, inventor signatures).

### Step 9: Authoritative Inventor List (Optional)

If the folder contains any of the following, the script will use it as the **authoritative source** for inventor names and add a new check (Check 71, "Inventor Names vs. Authoritative Source"):

- `inventors.json` — list of objects `[{"first": "...", "middle": "...", "last": "...", "suffix": "..."}, ...]` or list of strings
- `inventors.txt` — one inventor per line, formatted as `First Middle Last [Suffix]` or `Last, First M., Suffix`
- `*.eml` — best-effort name extraction from email body text (for email correspondence with paralegals confirming inventor names)

Cross-document mismatches against the authoritative source are flagged CRITICAL. Diacritic differences (e.g., `José` vs `Jose`, `Müller` vs `Muller`) are tolerated automatically. If the user mentions they have email correspondence confirming inventor names, suggest they save those emails as `.eml` files in the filing folder so the QC tool can use them.

## QC Check Categories

The skill performs 70+ quality control checks across these categories:

### Cross-Document Consistency (8 + 1 conditional checks)
- Inventor names match across ADS, declaration, assignment, and drawings
- Application title consistency
- Attorney docket number consistency
- Correspondence address alignment
- Assignee name consistency
- Filing date logic
- Inventor count matching
- Citizenship/residency information
- **Inventor Names vs. Authoritative Source** (only runs if `inventors.txt`, `inventors.json`, or `*.eml` is present in the folder)

### Document Completeness (4 checks)
- All required documents present
- ADS required fields complete
- Declaration signatures present
- Assignment signatures present (if included)

### Specification-Specific (15 checks)
- Sequential claim numbering
- Valid claim dependencies
- Figure references match drawings
- Reference numeral consistency
- Abstract present and length compliant (≤150 words)
- Required sections present (Background, Brief Description, Detailed Description, Claims)

### Drawings-Specific (5 checks)
- Sequential figure numbering
- Figure labels present
- Sheet numbering format
- Black and white compliance
- Legibility

### ADS-Specific (5 + 1 conditional check)
- Complete inventor addresses
- First named inventor identified
- Entity status specified
- Correspondence address complete
- Attorney/agent registration numbers
- **Attorney vs. correspondence customer number** *(when XFA data available — warns on mismatch between the two customer-number fields)*

### Declaration-Specific (4 checks)
- All inventors named
- Proper oath vs. declaration format
- References correct application
- Logical execution date

### Assignment-Specific (5 checks)
- All assignors identified
- Assignee clearly named
- References correct application/docket
- Logical execution date
- Proper rights transfer language

### Power of Attorney-Specific (4 checks)
- All practitioners listed
- Registration numbers included
- Address matches ADS
- Proper signatures

### USPTO Formatting Compliance (5 checks)
- Line numbering every 5 lines
- Margin compliance (top: 2cm, left: 2.5cm, right: 2cm, bottom: 2cm)
- Font size (≥12 pt)
- Double spacing
- Page numbering

### Common Error Detection (5 checks)
- No placeholder text ([INSERT], TODO, XXX, etc.)
- No visible track changes or comments
- Consistent claim terminology
- Proper antecedent basis
- Claim terms defined in specification

### File Quality (4 checks)
- PDFs are text-searchable (not scanned images)
- Logical file naming
- No password protection
- Reasonable file sizes

### Cross-Reference Validation (4 checks)
- Claims reference specification elements
- Summary matches claims scope
- Figure count consistency
- Claim count verification

### Priority/Related Applications (3 checks)
- Priority claim consistency across documents
- Related application references match
- Foreign priority documentation

### Final Quality (5 checks)
- No obvious typos in critical fields
- Dates properly formatted
- No excessively long claims
- Specification supports all claims
- Consistent figure reference format

## Understanding Check Results

Each check produces one of five severity levels:

- **✅ PASS** - Check passed, no action needed
- **⚠️ WARNING** - Potential issue detected, review recommended
- **🚨 CRITICAL** - Issue must be fixed before filing
- **❓ LOW CONFIDENCE** - Possible issue detected but could not be confirmed with certainty; manual verification needed
- **ℹ️ INFO** - Manual review recommended, automated check not possible

## Best Practices

1. **Run QC multiple times** - After each round of fixes, re-run to ensure no new issues
2. **Don't ignore INFO items** - These require manual verification
3. **Fix critical issues immediately** - These will cause filing rejections
4. **Investigate warnings** - They may be false positives, but often indicate real problems
5. **Keep both reports** - Archive with filing records for future reference
6. **Review manually too** - Automated checks catch most issues, but human review is still essential

## Limitations

This skill provides automated detection for many issues, but cannot replace human judgment:

- Some checks require visual inspection (drawing legibility, formatting)
- Complex legal/technical issues need attorney review
- Context-dependent decisions (claim scope, specification adequacy) need human analysis
- The tool helps catch errors, but final responsibility rests with the practitioner

## Script Details

The main QC script is located at `scripts/qc_patent_filing.py` and includes:
- Automatic document detection using filename patterns
- PDF text extraction using PyPDF2
- **XFA datasets-stream extraction for the USPTO web-fillable ADS** (no Adobe Acrobat Pro flattening required; reads inventor names with first/middle/last/suffix fields, title, docket #, customer #, residency, assignee, signer, etc., directly from the embedded XML)
- OCR fallback (pytesseract + pdf2image) for image-only PDFs
- Optional authoritative-source inventor list (`inventors.txt` / `inventors.json` / `*.eml`) for cross-checking against ADS / declaration / assignment / drawings
- Pattern matching for common issues
- Cross-document comparison logic
- Comprehensive reporting in Markdown and PDF formats

The script is designed to be run directly from Claude Code CLI without modification.
登录后下载/点赞/收藏 ❤ 7 | ★ 0
patent-filing-qc

目录结构

SKILL.md

举报内容

提示
