Bösherz Goebel Patent AI Hub
en / DE
Zurück

Context Engineering in der Patentarbeit

Warum Drafting, Bescheidserwiderung und FTO weder in einem Prompt noch in einem Chat passieren dürfen, und wie man sie stattdessen aufbaut.

Artikel aktualisiert am 25. April 2026

Im Vollbild öffnen

Kernbotschaft: Patentarbeit heißt Arbeit mit vielen unterschiedlichen Dokumenten. Patentanmeldungen in Prüfung, Stand der Technik, Erfindungsmeldungen, Prüfungsbescheide, Kommentare, Produktspezifikationen. Wer das alles in einen einzigen Chat kippt, bekommt vom Modell eine Mischung aus Alltem und nichts davon wirklich. Context Engineering heißt, für jeden Arbeitsschritt den passenden Kontext bereitzustellen, und nichts darüber hinaus.

Die drei Stufen

Prompt Engineering, Prompt Chaining und Context Engineering sind eine Evolution, keine Alternativen. Jede Stufe löst ein Problem der vorherigen.

  1. Stufe 1: Ein Prompt. Man formuliert eine Frage und die Antwort kommt zurück. Funktioniert für isolierte Aufgaben wie eine Formulierungsfrage, eine Definition oder eine kurze Zusammenfassung. Bricht, sobald die Aufgabe mehrere Denkschritte oder mehrere Eingaben verlangt. „Entwirf mir einen Anspruchssatz für diese Erfindungsmeldung und schreib gleich die Beschreibung dazu" ist schon zu viel für einen Prompt.
  2. Stufe 2: Prompt Chaining. Man zerlegt die Aufgabe in Schritte und gibt jedem Schritt einen eigenen Prompt. Bewertung der Erfindung zuerst, dann Vergleich mit dem Stand der Technik, dann Anspruchsentwurf, dann Beschreibung. Jeder Schritt bekommt das Ergebnis des vorherigen als Input. Funktioniert in einem langen Chat, solange das Kontextfenster reicht und die Schritte denselben Kontext brauchen. Bricht, wenn die Schritte unterschiedliche Kontexte brauchen oder sich gegenseitig vergiften.
  3. Stufe 3: Context Engineering. Man baut für jeden Schritt den passenden Kontext neu auf. Verschiedene Chats, verschiedene Rollen, verschiedene Dokumentenauszüge. Man konsolidiert Ergebnisse am Ende eines Chats in einem Übergabe-Prompt, der in den nächsten Chat geht. Man trennt Vertrauliches von dem, was in die Cloud darf. Man prüft Behauptungen in einem frischen Chat, der das Modell nicht schon voreingenommen hat. Das ist die Arbeitsweise, die eine 300-Seiten-Akte, mehrere Entgegenhaltungen und eine Erfindungsmeldung gleichzeitig bewältigen kann, ohne dass sich die Kontexte ineinander vermischen.

Warum das für Patentpraktiker besonders greift

Unsere Dokumente sind lang, heterogen und vertraulich. Eine Patentanmeldung hat 40 bis 200 Seiten, eine Akteneinsicht mehrere tausend. Eine Erfindungsmeldung liegt als handgepinselte Word-Datei vor, ein Bescheid als gescannte PDF. Das Modell muss zwischen „unveröffentlichte Erfindung" und „frei zugängliche D1" unterscheiden können, und das kann es nur, wenn der Kontext klar strukturiert ist.

Der Reflex, alle relevanten Dokumente in einen Chat zu laden und dann Fragen zu stellen, führt zu Kontext-Vergiftung. Das Modell mischt Merkmale der Erfindung mit Merkmalen der Entgegenhaltung, es zitiert aus dem falschen Dokument, und es verliert im zweiten oder dritten Prompt die Trennung zwischen „was ist unser Anspruch" und „was ist die Vorveröffentlichung". Context Engineering trennt diese Ebenen, bevor das Modell sie vermischen kann.

Die sechs Context-Engineering-Pattern für Patentarbeit

1. Dokument-Triage vor dem ersten Prompt

Bevor das erste Wort an das Modell geht, wird das Dokument selbst aufbereitet. Welche Absätze der Anmeldung sind für die Frage relevant? Welche Spalten der Entgegenhaltung gehören in den Kontext? Man schneidet, was nicht gebraucht wird. Ein Anspruchsauslegungs-Prompt braucht nicht die Zeichnungsbeschreibung, und ein Problem-Lösungs-Prompt braucht nicht die Definitionen aus dem Prior-Art-Dokument.

2. Chain-per-Task, nicht Chain-per-Chat

Jeder logisch separate Arbeitsschritt bekommt einen eigenen Chat mit eigenem System-Prompt. Die Bewertung der Erfindung läuft in Chat 1, der Vergleich mit jeder Entgegenhaltung in einem eigenen Chat (Chat 2 für D1, Chat 3 für D2), das Claim Brainstorming in Chat 4. So kann der System-Prompt in Chat 2 so formuliert werden, dass das Modell nicht mehr weiß, was in Chat 1 bewertet wurde, und schon gar nicht, dass eine zweite Entgegenhaltung existiert. Das verhindert Voreingenommenheit und lässt jeden Schritt frisch denken.

3. Konsolidierungs-Prompt am Chat-Ende

Bevor man einen Chat verlässt, bittet man das Modell, alle Fakten, Entscheidungen und offenen Fragen in einem einzigen in sich geschlossenen Prompt zusammenzufassen, den ein neues Modell ohne den Chat-Verlauf weiterarbeiten kann. Dieser Übergabe-Prompt wird zum Einstieg in den nächsten Chat. Er ist die einzige Information, die rübergeht, und das ist gewollt.

4. Fresh Context für die Verifikation

Prüfungen gehören nicht in den Chat, in dem auch produziert wurde. Ein Modell, das gerade einen Anspruch entworfen hat, ist ein schlechter Richter seines eigenen Entwurfs. Für Belegpflicht, Self-Reflexion und Advocatus-Diaboli öffnet man einen neuen Chat mit dem fertigen Output plus Quelldokument und lässt das Modell blind prüfen. Das Quelldokument muss wortwörtlich vorhanden sein, Paraphrasen reichen nicht.

5. Vertraulichkeits-Isolation

Was die Erfindung ausmacht, bleibt aus dem Cloud-Kontext draußen oder wird durch Platzhalter ersetzt. Eine allgemeine Recherche zum Stand der Technik läuft in der Cloud mit anonymisierten Begriffen. Die eigentliche Anspruchsformulierung mit dem geheimen Merkmal läuft lokal oder in einer vertrauenswürdigen Cloud-Instanz. Das ist nicht nur eine Compliance-Frage, sondern auch eine Kontext-Qualitäts-Frage: ein Enterprise-Chat bekommt die echten Merkmale und kann präziser arbeiten als ein Consumer-Chat mit Platzhalter-X.

6. Rollen-getrennte Parallel-Chats

Wenn ein Arbeitsschritt aus einer Auseinandersetzung besteht, etwa Drafter gegen Reviewer oder Anwalt gegen Prüfer, dann laufen die beiden Seiten in getrennten Chats mit klaren System-Prompts. Der Orchestrator bist Du: Du nimmst die Ausgabe aus Chat A, gibst sie Chat B, gibst dessen Antwort wieder Chat A. Kein Chat weiß, dass die Gegenseite eine KI ist. Das erhält die Schärfe der Rollen, die in einem gemeinsamen Chat innerhalb von zwei Runden aufgeweicht wird.

Anwendung auf die typischen Patent-Szenarien

Drafting: Erfindungsmeldung bis Anmeldungsentwurf

Vorhandene Quellen: Erfindungsmeldung (EM), zwei Stand-der-Technik-Dokumente (D1, D2), Anmeldevorlage (AV). Eine fertige Anmeldung gibt es noch nicht; sie ist das Ergebnis. Alles läuft lokal, weil EM und Anspruchsentwurf vertraulich sind.

  • Chat 1: EM analysieren. Was ist die Erfindung, was sind die Erfindungsmerkmale?
  • Chat 2: Merkmalsliste aus Chat 1 mit D1 vergleichen. Welche Merkmale unterscheiden die Erfindung von D1?
  • Chat 3: Merkmalsliste aus Chat 1 mit D2 vergleichen. Welche Merkmale unterscheiden die Erfindung von D2?
  • Chat 4: Claim Brainstorming auf Basis der Ergebnisse von Chat 1, Chat 2 und Chat 3.
  • Chat 5: Anmeldungsentwurf aus den Ansprüchen von Chat 4, der EM und der AV-Vorlage. Ergänzt um die Zusammenfassungen aus Chat 6 und 7 für den Stand-der-Technik-Abschnitt.
  • Chat 6: Zusammenfassung von D1 für den Stand-der-Technik-Abschnitt.
  • Chat 7: Zusammenfassung von D2 für den Stand-der-Technik-Abschnitt.

Wer dieses Schema regelmäßig fährt, erkennt schnell, wie viel Orchestrierung am Menschen hängt: Chats öffnen, Reihenfolge halten, Outputs kopieren, Vertraulichkeits-Disziplin halten. Genau dann lohnt der Schritt vom Hand-Flow zum Agent-Graph. Parallele Knoten für Chat 2/3 und Chat 6/7 halbieren die Wallclock, mechanische Übergaben zwischen den Knoten ersetzen Copy-Paste, das Routing zwischen lokalem Modell und Cloud ist einmal definiert. Mehr dazu in Multi-Model-Workflows.

Bescheidserwiderung

  • Chat 1: Bescheid Absatz-für-Absatz strukturieren. Input: nur Bescheidstext.
  • Chat 2: Entgegenhaltungen gegen Ansprüche abgleichen. Input: Entgegenhaltungen plus Anspruchssatz, ohne Bescheid.
  • Chat 3: Erwiderungsstrategien entwickeln. Input: Konsolidierung aus Chats 1 und 2.
  • Chat 4 (fresh): Belegpflicht-Prüfung. Input: Strategie-Behauptungen plus Entgegenhaltungen, mit Verbatim-Zitaten-Pflicht.

Freedom-to-Operate

  • Chat 1: Produktbeschreibung in Merkmale zerlegen. Input: Produktspezifikation.
  • Chat 2: Trefferliste vorfiltern. Input: Merkmalsliste, keine Produktdetails.
  • Chat 3 pro Treffer: Verletzungsanalyse je Patent. Input: das eine Patent plus die Merkmalsliste, isoliert.
  • Chat 4: Risikomatrix konsolidieren. Input: die einzelnen Analysen, ohne die Volltexte der Patente.

Verbindung zu den anderen Artikeln

  • Context Engineering: Die zugrundeliegende Disziplin, Kontext klein und frisch zu halten. Context Engineering ist die Anwendung dieses Prinzips auf Patent-Workflows.
  • Absatz-für-Absatz-Durchsuchung: Das Pattern, mit dem man ein langes Dokument sauber in einen strukturierten Kontext überführt.
  • Belegpflicht: Der Verifikations-Baustein, der mit Fresh Context am besten funktioniert.
  • Prompt Engineering Patterns: Die Bausteine, mit denen innerhalb jedes Chats die Qualität der Einzelantwort gesteuert wird.
  • Multi-Model-Workflows: Rollen-getrennte Parallel-Chats im Detail, mit Drafter-Reviewer-Beispielen.

Newsletter

Bleib auf dem Laufenden zu generativer KI in der Patentpraxis.

GenAI-Newsletter abonnieren

Inhalte teilweise KI-generiert, kuratiert von Sebastian Goebel. Dies ist keine Rechtsberatung, sondern Trainingsmaterial für meine Workshops. Keine Gewährleistung für Richtigkeit oder Vollständigkeit. Keine Haftung. Software wird ohne Mängelgewähr bereitgestellt.