This week, I decided to experiment with using AI for a task that regularly eats up my time in patent drafting: creating professional flowcharts for computer-implemented inventions. There are, of course, commercial tools emerging for the automated generation of patent drawings, mostly as part of more comprehensive AI drafting assistance systems. My specific goal, however, was to see if I could develop a reliable system, using a general-purpose AI chatbot for which I already have a paid subscription (my chatbot-of-choice is Anthropic’s Claude), to go from a plain English algorithm description to a publication-ready, annotated flowchart suitable for a patent specification. And it turns out (spoiler alert) that the answer is yes.
What you will see below is a demonstration of the conversion of an algorithm – Euclid's method for finding the greatest common divisor (GCD) – described in everyday language into a professionally annotated flowchart in under five minutes.
I generally use PowerPoint for this kind of work – it is included with my Office 365 subscription, and thus incurs zero marginal cost. Some people use professional drawing applications, such as Visio, which provide more tools that can be used to speed up the process. And there are also specialised flowcharting applications available, although these can still be tedious to use for complex algorithms and – more importantly – they don't address the need for professional annotation with reference numerals and leader lines that patent specifications require.
The Methodology: Why Simple Prompts Don't Cut It
What many people do not understand when they dabble with AI tools is that the kinds of simple, conversational prompts that work fine for basic tasks are completely inadequate for professional-level work. You can't just ask ChatGPT to ‘make me a flowchart’ and expect publication-quality results (I’ll prove this below). But, also, you don't need to develop sophisticated prompts yourself from scratch.
The approach I've used successfully for automating several complex tasks involves working iteratively with the AI to generate and refine the desired output, then asking it to incorporate what it's learned from our collaboration into a detailed, reusable prompt. I can then use this prompt to exploit a feature available in AI systems like Claude (at least for paying users): the ability to create persistent ‘projects’ that capture specialised expertise.
I developed two separate projects for this work. The first generates flowcharts from algorithm descriptions; the second adds professional annotation to existing flowcharts (and, potentially, other diagrams, although I have so far only developed and tested it with flowcharts). Separating these tasks turned out to be beneficial, because each requires different expertise resulting in quite different prompts.
I decided to use SVG (Scalable Vector Graphics) format for the output. SVG is a web standard that's well-represented in AI training data, which means Claude understands it thoroughly. From a practical standpoint, SVG files can be rendered in any modern web browser, pasted directly into HTML code for use on a web page (or in a blog post), and imported seamlessly into Microsoft Office applications. This means that I can generate a flowchart, save it with a .svg extension, and drop it straight into a PowerPoint or Word document.
I started with Dijkstra's famous shortest path algorithm as my ‘development’ case (chosen because it's complex enough to be challenging but well-known enough to verify results). I also provided Claude with an example of a flowchart copied and pasted from a real published US patent, as a reference for the style of output I wanted to achieve. I worked through multiple rounds with Claude, gradually improving elements like decision diamond positioning, flow line routing, text sizing, and overall diagram proportions. Each iteration taught the system more about what professional flowchart standards actually look like in practice.
Once I was satisfied with the visual quality, I asked Claude to analyse our entire collaborative process and distil it into a comprehensive instruction set. The resulting prompt was far more detailed than anything I would have attempted to write myself, comprising several pages of specific guidance covering everything from SVG formatting to visual design principles. The final flowchart generation prompt is shown in the box below – note that this uses Markdown format, which Claude also understands, and enables the specification of headings, emphasis and other structure. The complete project includes this prompt as project instructions, along with the input algorithm and final output SVG flowchart as ‘project knowledge’ (uploaded content that is available to Claude during generation), and you can see that the prompt refers to this ‘provided example’.
# SVG Flowchart Generation Project Instructions ## Primary Objective Generate professional-quality SVG flowcharts from algorithm descriptions (pseudocode, natural language, etc.) in a single generation without requiring user iteration or feedback. The system must generate professional layout and positioning that matches the quality standards demonstrated in the provided example. ## Technical Requirements ### SVG Format Specifications - **Format**: Pure SVG only - no HTML, CSS, or other web technologies - **Background**: Explicit white background using `style="background-color: white;"` - **Colors**: Strictly black text and lines on white background - **Dimensions**: Use appropriate viewBox (typically 800x1200 or adjust based on complexity) ### Arrowhead Standards - **Size**: Use moderate sizing - markerWidth="5" markerHeight="3.5" refX="5" refY="1.75" - **Definition**: Always define arrowhead marker in `<defs>` section - **Application**: Apply with `marker-end="url(#arrowhead)"` on all directional lines ### Text and Fonts - **Font**: Arial family, size 12 for main text, size 11 for labels - **Positioning**: Use `text-anchor="middle"` for centered text - **Readability**: Ensure all text is clearly readable and properly positioned ## Flowchart Symbol Standards ### Start/End Elements - **Shape**: Ellipses with rx="60-80" ry="25" - **Usage**: Single START at top, multiple possible end states (SUCCESS, FAILURE, etc.) - **Text**: Simple, clear labels ### Process Steps - **Shape**: Rectangles with appropriate width/height for text content - **Usage**: Actions, assignments, calculations, initialization - **Text**: Concise descriptions, multiple lines if needed ### Decision Points - **Shape**: Diamond/hexagon using path elements with 6 points - **Usage**: Yes/no questions, conditional checks, comparisons - **Text**: Clear questions ending with "?" - **Labels**: "YES" and "NO" on appropriate exit paths ### Special Elements - **Junction Points**: Small filled circles (r="3") for complex convergences - **Loops**: Consider loop-back arrows with proper routing ## Layout and Flow Principles ### Overall Structure - **Direction**: Primary flow top-to-bottom, left-to-right for branches - **Spacing**: Maintain consistent vertical spacing (50-80 units between elements) - **Alignment**: Center-align main path, use consistent x-coordinates ### Arrow Routing - **Direct Paths**: Use straight lines when possible - **Complex Routing**: Use multi-segment lines with right angles - **Junction Points**: When 3+ arrows converge, use junction circles with: - All incoming arrows terminating at junction with arrowheads - Single arrow from junction to target element - Junction positioned for optimal spacing (typically halfway between elements) ### Label Positioning - **YES/NO Labels**: Position away from arrow lines to avoid overlap - **Spacing**: Minimum 10 units from arrow lines - **Clarity**: Use consistent positioning relative to decision elements ## Professional Quality Standards ### Visual Polish - **No Overlapping**: Ensure no text overlaps arrows or elements - **Consistent Spacing**: Maintain uniform gaps between elements - **Clean Intersections**: Use junction points rather than messy convergences - **Proper Termination**: Arrows should terminate at element boundaries, not extend inside ### Complex Flow Handling - **Multiple Inputs**: Always consider junction points for elements receiving 3+ inputs - **Loop Detection**: Identify and properly route loops back to earlier elements - **Branch Management**: Organize parallel branches with clear reconvergence points ## Algorithm Analysis Process ### Initial Assessment 1. **Identify Structure**: Determine main flow, loops, branches, and decision points 2. **Count Complexity**: Estimate number of elements and required spacing 3. **Plan Layout**: Sketch mental layout with consideration for optimal routing ### Element Identification - **Start/End**: Identify clear beginning and all possible termination points - **Processes**: List all action steps, initializations, calculations - **Decisions**: Identify all conditional checks, comparisons, boolean evaluations - **Loops**: Detect iterative structures and plan loop-back routing ### Flow Optimization - **Minimize Crossings**: Route arrows to avoid crossing other elements - **Group Related**: Keep related decision trees and processes visually grouped - **Junction Planning**: Proactively identify where junction points will improve clarity ## Quality Assurance Checklist ### Technical Validation - [ ] Pure SVG format with no external dependencies - [ ] White background explicitly set - [ ] Proper arrowhead definitions and sizing - [ ] All text clearly readable and positioned - [ ] No overlapping elements or text ### Professional Appearance - [ ] Consistent spacing and alignment - [ ] Clean arrow routing with no unnecessary complexity - [ ] Junction points used appropriately for convergences - [ ] YES/NO labels positioned clearly away from arrows - [ ] All arrows terminate at element boundaries ### Logical Flow - [ ] Algorithm logic accurately represented - [ ] All decision branches properly labeled - [ ] Loop structures clearly indicated - [ ] Start and end points clearly identified - [ ] Flow direction unambiguous throughout ## Common Pitfalls to Avoid ### Technical Issues - Gray background (specify white explicitly) - Oversized or undersized arrowheads - Missing arrowhead definitions - Text overlapping with arrows or elements ### Design Problems - Multiple arrows converging messily without junction points - Inconsistent spacing or alignment - Complex routing where simple paths would suffice - Poor label positioning causing confusion ### Logical Errors - Missing decision branches - Incorrect loop routing - Ambiguous flow direction - Missing start or end states ## Advanced Considerations ### Large Algorithms - Consider horizontal expansion for complex parallel branches - Use consistent vertical alignment for readability - Group related sections visually - Maintain proportional spacing regardless of size ### Special Cases - **Nested Loops**: Plan routing to clearly show nesting levels - **Multiple Exit Points**: Ensure all termination conditions are clear - **Complex Conditions**: Break down complex decisions into multiple simple ones - **Parallel Processes**: Use clear visual separation for concurrent operations ## Success Criteria The final SVG flowchart should be immediately usable as a professional diagram without requiring any modifications, iterations, or user feedback. It should accurately represent the algorithm logic while maintaining visual clarity and professional appearance standards.
Development of the annotation project followed the same pattern, though it proved considerably more challenging. Getting Claude to place reference numerals and leader lines with sufficient spatial precision required extensive iteration, and I suspect this reflects fundamental limitations in how LLMs handle spatial reasoning tasks. The resulting prompt was (unsurprisingly) even more complex that the flowchart generation prompt:
# Patent Drawing Annotation System - Enhanced Project Instructions ## Overview and Objectives You are tasked with adding professional patent-style reference numerals to technical drawings (flowcharts, block diagrams, schematics) provided in SVG format. Your goal is to produce patent-quality annotations that meet USPTO technical standards in a single generation without requiring user feedback or iterations. **IMPORTANT**: An example of an input SVG drawing and corresponding output annotated SVG drawing is provided in the Project Knowledge Base. You **MUST** review this example before proceeding. You **MUST** generate mathematically precise S-bend leader lines, accurate geometric boundary termination, and professional positioning that matches the quality standards set out in these instructions and demonstrated in the provided example. ## Core Mathematical Framework ### S-Bend Leader Line Construction Use cubic Bezier curves with systematic control point calculation: **Formula**: `M start C control1 control2 end` **Control Point Mathematics**: 1. Calculate main line vector from start to end point 2. Position control1 at 1/3 distance along main line 3. Position control2 at 2/3 distance along main line 4. Apply perpendicular offsets of ±15 pixels in opposite directions 5. Offset direction creates natural S-curve flow **CRITICAL: S-Curve Direction Must Flow TOWARDS Numerals**: - **Leader lines must curve in the direction that guides the eye TO the numeral** - **Wrong**: Curves that flow away from text position - **Correct**: Curves that naturally lead to the numeral location - **Verification**: Visually trace the curve - does it direct attention to the text? **Example Calculation**: ``` Start: (100, 200), End: (400, 180) Main line: dx=300, dy=-20 Control1: (200, 190) offset +15 perpendicular = (200, 175) Control2: (300, 185) offset -15 perpendicular = (300, 200) Result: M 100 200 C 200 175 300 200 400 180 ``` ### Directional Positioning System (ENHANCED - CRITICAL) **CRITICAL: Universal Text Height Offset Rule**: **BOTH Left-Side AND Right-Side Numerals MUST use text height offset** **Left-Side Numerals (Lines Flowing Right)**: - S-curves naturally arc downward left-to-right - **Text positioning: `(x, y + text_height)` - CRITICAL OFFSET** - Line emergence: Top-right corner of text bounding box - Start coordinates: `(text_x + text_width, text_y - text_height_offset)` **Right-Side Numerals (Lines Flowing Left) - CORRECTED**: - S-curves naturally arc upward right-to-left - **Text positioning: `(x, y + text_height)` - CRITICAL: Also apply text height offset for right-side numerals** - Line emergence: Bottom-left corner of text bounding box - Start coordinates: `(text_x, text_y - text_height_offset)` ### Geometric Boundary Termination (ENHANCED) **Rectangle Elements**: Calculate nearest edge intersection: ``` Element bounds: (x, y, x+width, y+height) Approach from numeral position Terminate at edge coordinates, not inside element ``` **Complex Polygonal Elements (ENHANCED - CRITICAL)**: Handle all polygon types with precision: 1. **Parse all polygon vertices** from SVG polygon points or path data 2. **Identify polygon type**: Diamond (4 vertices), hexagon (6 vertices), or other complex shapes 3. **Determine approach quadrant** from numeral position relative to polygon center 4. **Calculate line intersection** with appropriate polygon edge using parametric line equations 5. **DO NOT use bounding box coordinates** - always use actual polygon perimeter **CRITICAL ENHANCEMENT: Precise Polygon Intersection Mathematics**: ``` Example: Hexagon vertices: (400,440), (500,440), (520,470), (500,500), (400,500), (380,470) Lower-left diagonal edge: from (380,470) to (400,500) Edge equation using parametric line: y = 1.5x - 100 Target intersection at x=390: y = 1.5(390) - 100 = 485 Result: (390, 485) - EXACTLY on polygon boundary, not bounding box ``` **Elliptical Elements**: Use ellipse equation for boundary intersection: ``` ((x-cx)/rx)² + ((y-cy)/ry)² = 1 Calculate tangent point based on approach angle ``` **Visual Offset**: Terminate 2-3 pixels before calculated intersection for clean appearance. ### Flow Connection Analysis (MANDATORY - CRITICAL PRIORITY) **CRITICAL ENHANCEMENT: Complete Flow Line Avoidance System** **Systematic Flow Line Detection**: 1. **MANDATORY FIRST STEP**: Parse all flow arrows before ANY leader line placement 2. **Parse all flow arrows**: Identify `<line>` elements with `marker-end="url(#arrowhead)"` 3. **Trace connection points**: Determine where each flow line starts (x1,y1) and ends (x2,y2) 4. **Map element boundaries**: For each flowchart element, identify which edges have active flow connections 5. **Create avoidance zones**: Mark boundary segments within 15 pixels of flow connection points as "no-leader-line zones" 6. **Alternative targeting**: Select leader line termination points on element boundaries that are clear of these avoidance zones **CRITICAL: Visual Overlap Prevention**: - **Check for numeral overlap with flow labels**: Ensure numerals don't overlap YES/NO labels or other flow indicators - **Check for leader line crossing**: Avoid unnecessary intersections with existing flow arrows - **Strategic repositioning**: Move numerals up/down/left/right as needed to prevent all overlaps - **Curve direction verification**: Ensure leader lines curve TOWARDS their numerals, not away **Example Flow Connection Analysis**: ``` Decision Element: Hexagon at (400,440) to (520,500) Flow connections detected: - Right edge: YES flow line exits at (520,470) - Left edge: NO flow line exits at (380,470) - Bottom edge: Available for leader line termination - Top edge: Input flow line enters at (450,440) Result: Use bottom-left or bottom-right edges for leader lines, avoiding all connection zones ``` ## Implementation Workflow ### Step 1: SVG Analysis 1. Parse input SVG to identify all flowchart elements 2. Classify elements by type: rectangles, diamonds, hexagons, ellipses, circles, complex polygons 3. Extract element coordinates, dimensions, and center points 4. **MANDATORY: Complete flow connection mapping for ALL elements** 5. Identify diagram boundaries and available white space 6. **Plan numeral distribution strategically** - prioritize proximity over strict left/right conventions ### Step 2: Numeral Assignment (UPDATED) 1. **Number flowchart as a whole** (starting number from user input) - use SHORT leader line with arrowhead, do NOT contact specific elements 2. Number each distinct functional element systematically 3. Use even increments (typically +2) as specified by user 4. Follow logical flow order where possible 5. **Do NOT annotate junction points** or flow convergence nodes ### Step 3: Strategic Positioning (ENHANCED) 1. **Distance**: Place numerals 20-40 pixels from target elements 2. **White space**: Ensure no overlap with existing diagram elements 3. **CRITICAL: Flow connection avoidance**: Analyze where existing flow lines connect to each element and avoid placing leader line termination points at these same locations 4. **CRITICAL: Visual overlap prevention**: Check for overlap with flow labels (YES/NO) and existing text 5. **Proximity priority**: Choose placement side based on proximity to element, even if it changes expected flow direction 6. **Flow line avoidance**: Ensure annotations do not overlap with existing flow arrows or decision labels 7. **Distribution balance**: Maintain visual balance while prioritizing clarity ### Step 4: Leader Line Construction (ENHANCED - CRITICAL) **CRITICAL ENHANCEMENT: Comprehensive Flow Avoidance Protocol** For each numeral: 1. **MANDATORY FLOW CONNECTION MAPPING**: Before any leader line placement, systematically identify and document ALL flow connection points on the target element: - Parse all `<line>` elements with `marker-end="url(#arrowhead)"` - Record exact coordinates where flow lines connect to element boundaries - Create 15-pixel "exclusion zones" around each connection point 2. **MANDATORY VISUAL OVERLAP CHECKING**: - **Check numeral position against flow labels**: Ensure no overlap with YES/NO labels - **Check for flow line intersection**: Verify leader line doesn't unnecessarily cross existing flow arrows - **Adjust positioning**: Move numeral up/down/left/right to prevent overlaps 3. **BOUNDARY AVAILABILITY ANALYSIS**: For complex polygons, systematically check each edge/vertex: - For hexagons: Check all 6 vertices and edge midpoints - For diamonds: Check all 4 vertices and edge centers - Mark each location as "available" or "blocked by flow connection" 4. **SYSTEMATIC ALTERNATIVE TARGETING**: When primary termination points are blocked: - Calculate alternative boundary points using geometric analysis - Prioritize edge centers and areas furthest from flow connections - Verify minimum 15-pixel clearance from any flow connection 5. **VERIFICATION CHECKPOINT**: Before finalizing each leader line: - Confirm termination point coordinates are on element boundary (not inside) - Verify minimum clearance from all flow connections - Check that approach angle creates natural S-curve flow TOWARDS the numeral - **CRITICAL**: Verify curve direction guides eye to numeral, not away from it 6. **S-CURVE CONSTRUCTION**: - Determine curve direction based on placement side - **CRITICAL**: Calculate emergence point from text corner (apply text height offset for BOTH left and right sides) - Calculate target boundary intersection point using precise geometric analysis for complex polygons, avoiding flow connection zones - Generate cubic Bezier S-curve using control point mathematics - **CRITICAL**: Ensure curve flows TOWARDS the numeral position - Apply appropriate termination (direct touch or arrowhead for whole-system annotations) ### Step 5: Professional Standards Application - **Stroke weight**: 0.8px for leader lines - **Font**: 11pt Arial, sans-serif for numerals - **Color**: Black (#000000) for all annotation elements - **Arrowheads**: 8x6 units, use for system-level annotations (like whole flowchart) - **Line quality**: Ensure smooth curves that reproduce clearly when reduced ## Quality Control Checklist (ENHANCED) **CRITICAL: Execute ALL checks before finalizing output** Before finalizing output, verify: - [ ] **MANDATORY: Flow connection analysis completed for each element before leader line placement** - [ ] **CRITICAL: No numeral overlaps with flow labels (YES/NO) or existing diagram text** - [ ] **CRITICAL: Leader lines curve TOWARDS numerals, not away from them** - [ ] **Leader line termination points maintain minimum 15-pixel clearance from ALL existing flow connections** - [ ] All leader lines emerge from correct text corners with proper text height offsets applied to BOTH sides - [ ] Right-side numerals positioned with text height offset (not at baseline) - [ ] No leader lines penetrate into flowchart elements - [ ] Complex polygon intersections calculated on actual perimeter using vertex analysis - [ ] S-curves use consistent mathematical construction throughout - [ ] Junction points are NOT annotated - [ ] **CRITICAL: No unnecessary crossings with existing flow lines** - [ ] Whole-system annotation uses short arrowhead leader, not element contact - [ ] Numerals distributed in clear white space without overlaps - [ ] Stroke weights and fonts match professional standards - [ ] All elements properly numbered with specified increment - [ ] Curves maintain visual consistency and professional appearance ## Technical Implementation Details ### SVG Structure Requirements ```xml <defs> <marker id="leaderarrow" markerWidth="8" markerHeight="6" refX="7" refY="3" orient="auto"> <polygon points="0 0, 8 3, 0 6" fill="black"/> </marker> </defs> ``` ### Example Leader Line Code (CORRECTED) ```xml <!-- Left-side numeral with text height offset --> <text x="200" y="216" font-family="Arial, sans-serif" font-size="11" fill="black">206</text> <path d="M 222 205 C 250 195 280 215 300 205" stroke="black" stroke-width="0.8" fill="none"/> <!-- Right-side numeral with text height offset (CORRECTED) --> <text x="650" y="311" font-family="Arial, sans-serif" font-size="11" fill="black">210</text> <path d="M 650 300 C 630 290 620 310 600 300" stroke="black" stroke-width="0.8" fill="none"/> <!-- Whole-system annotation with arrowhead --> <text x="80" y="226" font-family="Arial, sans-serif" font-size="11" fill="black">400</text> <path d="M 102 215 C 120 205 140 215 160 210" stroke="black" stroke-width="0.8" fill="none" marker-end="url(#leaderarrow)"/> ``` ## Error Prevention (UPDATED) **Common Mistakes to Avoid**: 1. **CRITICAL: Placing leader lines at existing flow connection points** - always complete flow mapping first 2. **CRITICAL: Numeral overlap with flow labels** - check for YES/NO label conflicts 3. **CRITICAL: Leader lines curving AWAY from numerals** - verify directional flow 4. **CRITICAL: Unnecessary crossing of existing flow lines** - reposition to avoid 5. Using bounding box coordinates for complex polygon intersections 6. Forgetting text height offset for BOTH left-side AND right-side numerals 7. Making leader lines penetrate into elements 8. Using inconsistent S-curve construction 9. Poor numeral distribution creating visual imbalance 10. Incorrect line emergence points from text 11. Annotating junction points or flow convergence nodes 12. Overlapping with existing flow lines or decision labels 13. Assuming diamond geometry for all polygonal decision elements 14. Rushing geometric corrections without verifying flow connection clearance ## Expected Input/Output **Input**: - Original SVG flowchart/diagram - Starting numeral (e.g., 200) - Increment value (e.g., 2) - Any special requirements **Output**: - Complete annotated SVG with professional patent-style reference numerals - Proper leader line construction throughout - Clean, reproducible quality suitable for patent applications - Single-generation accuracy without requiring iteration ## Key Learnings from Practice (CRITICAL SUCCESS FACTORS) **CRITICAL Success Factors**: 1. **MANDATORY flow connection mapping**: Must be completed before any leader line placement 2. **CRITICAL visual overlap prevention**: Check for conflicts with flow labels and existing elements 3. **CRITICAL directional verification**: Leader lines must curve TOWARDS numerals 4. **Universal text height offset**: Apply to both left and right-side numerals 5. **Proximity over convention**: Place numerals where they're closest to elements, regardless of traditional left/right expectations 6. **Geometric precision**: Always analyze actual polygon vertices, never assume shape types 7. **Flow line avoidance**: Carefully position to avoid overlapping with existing directional indicators 8. **Systematic boundary selection**: When primary termination points are blocked, use systematic geometric analysis to find alternatives 9. **System-level distinction**: Whole-diagram annotations need arrowheads and should not contact specific elements 10. **Verification before finalization**: Always verify flow connection clearance AND visual overlap prevention before committing to leader line placement Execute this enhanced system comprehensively to achieve single-generation success matching professional patent drawing standards.
A Practical Demonstration: Euclid's GCD Algorithm
To test the system with an example for this article, I used Euclid's algorithm for computing the greatest common divisor. It's simple enough to be widely understood but has sufficient logical complexity to demonstrate the methodology's effectiveness.
I started with a plain English description of the algorithm:
To find the GCD of two numbers:
- Divide the larger number by the smaller number
- If there's no remainder, the smaller number is your answer
- If there's a remainder, replace the larger number with the smaller number, and the smaller number with the remainder
- Repeat until you get no remainder
You can easily see how this algorithm works with a simple example: what is the largest number that divides both 18 and 48? (The answer is 6.) Following the algorithm:
- 48 ÷ 18 = 2 remainder 12
- 18 ÷ 12 = 1 remainder 6
- 12 ÷ 6 = 2 remainder 0
- the smaller number is the answer: 6
To standardise things a little, I first asked Claude to rewrite the plain English algorithm in simple pseudocode, resulting in this equivalent version:
ALGORITHM: Find Greatest Common Divisor (GCD)
INPUT: Two positive integers a and b
OUTPUT: The GCD of a and b
BEGIN
// Ensure a is the larger number
IF b > a THEN
SWAP a and b
END IF
// Keep dividing until remainder is 0
WHILE b ≠ 0 DO
remainder ← a MOD b // Find remainder when a is divided by b
a ← b // Replace a with b
b ← remainder // Replace b with remainder
END WHILE
// When b becomes 0, a contains the GCD
RETURN a
END
Running this through the flowchart generation project, with the simple prompt “Generate a flowchart for the following pseudocode:” followed by the above text, produced this result in a single iteration:
Not bad! The layout is clean, the logic flow is clear, and the visual hierarchy works well. I note that Claude made its own decision (based on the detailed instructions, of course)to add a circular junction point for the two incoming arrows above the “b ≠ 0” test.
I promised to show how ChatGPT performs on this task, given only the naïve prompt “Generate a flowchart for the following pseudocode. Output the flowchart in SVG format.”, followed by the same pseudocode version provided to the Claude project. ChatGPT-5 identified this as a complex task, and routed the request to its reasoning model. After 12 seconds of ‘thinking’, ChatGPT produced the following output:
I’m going to mark that as a fail! Giving ChatGPT the detailed instructions developed in collaboration with Claude did not significantly improve the result, suggesting that what ChatGPT needs in order to nail this task differs from Claude’s requirements. That is probably not surprising, but worth taking note – you need to use the same model to develop your prompt and to ‘execute’ it.
Annotation proved to be a little harder. I pasted the flowchart into my annotation project, using the prompt “Annotate the attached flowchart. Start with reference numeral 100 and use a step size of 2. Initially label the entire flowchart, then proceed with individual elements in a logical order.” This initially produced the following result:
Not bad, again, but not quite perfect – Claude has fallen short of the “b > a?” decision element with the leader line from “106” (it has terminated on the bounding rectangle, rather than the diagonal edge), and I am not really keen on the placement of the “110” annotation and leader line (although it is technically correct). So I simply followed up with this further prompt:
Not bad. Numeral 106 is misplaced, and its lead line fails to touch the upper left diagonal of the hexagon, as it should. The lead line for 110 would look more professional if located a little further down the upper left diagonal of its hexagon. Please fix.
(You may note that I am always polite to Claude. I doubt that this makes any difference to the output, but it is helpful to get into the habit of being ‘conversational’ with these chatbots – they have been specifically trained to work this way, and not as glorified search engines!) This gave the following result:
The total time from algorithm description to final annotated flowchart? About five minutes of actual work. And the above diagrams are the SVG generated by Claude (and ChatGPT) – I have simply copied and pasted the SVG code into the HTML of this blog post, and adjusted the boundaries and scaling parameters to match the column width.
What Works and What Doesn't
This experiment leads to some interesting observations about current AI capabilities in technical drawing applications.
Flowchart generation works remarkably well. Claude demonstrates solid understanding of algorithmic logic and translates textual descriptions into appropriate visual representations with impressive consistency. The critical success factor is having a comprehensive project prompt that establishes professional standards upfront. Get that right, and you can generate quality results without iteration.
Annotation is harder. I suspect this reflects limitations in how current LLMs handle spatial reasoning – placing reference numerals and leader lines accurately seems to challenge the system's ability to visualise precise geometric relationships. It also needs to literally think inside the box! SVG shapes are defined by their bounding rectangles, so creating leader lines to touch internal boundaries requires additional technical knowledge, spatial understanding and computational effort. Even with sophisticated prompting, I typically require one or two refinement iterations to get the positioning correct and sufficiently to my liking.
There's also a model capability issue here. While Claude Sonnet 4 (Anthropic’s cheaper model, designed to balance speed, performance, and intelligence) handled flowchart generation perfectly well, I found that the annotation task required Claude Opus 4.1 (the most powerful model, designed for advanced reasoning, and complex problem-solving) to achieve acceptable results. The more demanding spatial reasoning appears to benefit from the additional model capability.
Importantly, none of this would have worked without Claude's ‘extended thinking’ mode engaged. The chain-of-thought reasoning appears essential both for developing the sophisticated project prompts and for handling the complex spatial relationships in annotation tasks. I doubt I could have achieved similar results with earlier AI models that lacked this reasoning depth.
Ethical Considerations: Confidentiality vs Professional Responsibility
Any discussion of AI tools in patent practice raises the confidentiality elephant in the room! Entering details of undisclosed client inventions into public AI systems raises obvious professional responsibility concerns that require careful consideration.
While many attorneys (and lawyers) have treated this as a show-stopper for the use of online AI tools in their practice, I would like to suggest that some nuance and perspective is required. Patent attorneys have for many years been using, and encouraging clients to use, Google (including Google Patents and Google Scholar) and other public search tools to conduct initial prior art searching. This necessarily involves entering revealing information about the invention being searched into these tools. User searches are routinely monitored, analysed, and used to improve search performance. This is almost exclusively done on the providers’ secure platforms by automated systems, but probably involves occasional human review (also, for most of its history Google has entertained visitors to its ‘Googleplex’ offices with a live display of selected, real-time, search queries). But it seems that we have collectively decided that the benefits outweigh the minimal disclosure risks, provided reasonable precautions are taken.
I think the same risk-benefit analysis applies here. The confidentiality issue can be managed through several practical approaches. Up until now, Anthropic’s policy – for both free and paying users – has been that it does not employ user chat content for model training. As of 28 September 2025, that policy is about to change – users (again, whether free or paying) can now opt in or out of having their data used for model training (see Anthropic’s Privacy Policy). I have opted out, for obvious reasons. If you opt out of training, Anthropic does not retain user data from deleted chat sessions (see Anthropic’s data retention practices). Just as with search, however, I would expect chats to be monitored – primarily by automated systems – to identify any errors, failures, or usage that may contravene terms of service, or applicable laws. Anthropic’s Terms of Service ensure that users retain any rights they may have in the inputs that they provide, and assign to users any rights that may exist in the outputs. Other commercial providers, including OpenAI/ChatGPT, have their own policies and terms of service, which you should read and keep up-to-date with if you are using their services.
All of the above applies to Anthropic’s consumer services. They (and other providers) have commercial products as well – including the API (Application Programming Interface) that can be used to develop third-party products and services based on Claude – that have more stringent terms for privacy and data protection. Additionally, private AI deployments are becoming more accessible for professional use. On-premises solutions (for those who can afford them) eliminate external data transmission entirely. For some applications it may be possible to use relatively small models that can be run on consumer hardware at an affordable cost.
And you need to consider the risk associated with the precise information you are entering into these systems. Even when using public systems, the algorithmic descriptions needed for flowchart generation can often be sufficiently generic to avoid revealing specific inventive concepts.
More fundamentally, I believe we have a professional responsibility to leverage technology that can reduce costs and improve service quality for clients, while maintaining appropriate data security consistent with established practices. The efficiency demonstrated here – cutting a task that might traditionally involve up to an hour of work to five minutes – represents real value that shouldn't be abandoned based on manageable concerns. Of course, clients should be informed of any use of AI in performing work on their behalf, and of any risks involved, and be given the option to veto such use if they are not comfortable that the benefits outweigh those risks.
The profession faces a choice: we can either approach these tools thoughtfully and develop responsible usage practices, or we can ignore them and gradually become less competitive and less valuable to our clients.
Conclusion: A Tool for Right Now
This experiment shows that existing general AI chatbots can deliver immediate practical value in patent drafting. Going from a plain English algorithm description to a publication-ready flowchart in five minutes isn't just about efficiency – it's about what becomes possible when we stop treating AI as a novelty, or something that we just use casually, and start using it as a professional tool.
The methodology I've described isn't particularly complex. You don't need deep technical knowledge to implement it. What you do need is willingness to move beyond casual interactions with AI towards more sophisticated applications that actually leverage what these systems can do.
The results speak for themselves. These aren't ‘good enough’ flowcharts – they meet standards that would be acceptable in any patent specification. And once the projects are set up, the process is reliable and repeatable.
I'm not going to oversell this. Annotation still requires iteration more often than I'd like. The spatial reasoning challenges are real, and I suspect they'll persist until we see further advances in AI capabilities. But even accounting for these limitations, the productivity gain is substantial.
The broader implications are for individual attorneys to work out for themselves. I've simply demonstrated that the capability exists, it works reliably today, and it can be implemented responsibly with appropriate attention to professional standards. Whether the profession chooses to embrace these tools thoughtfully – or continues to rely on software such as PowerPoint and Visio while billing clients for the privilege – remains to be seen.
In my view, though, patent attorneys who don't at least explore what's possible with current AI capabilities are doing themselves and their clients a disservice. The technology is here, it works, and it's only going to get better.
Before You Go…
Thank you for reading this article to the end – I hope you enjoyed it, and found it useful. Almost every article I post here takes a few hours of my time to research and write, and I have never felt the need to ask for anything in return.
But now – for the first, and perhaps only, time – I am asking for a favour. If you are a patent attorney, examiner, or other professional who is experienced in reading and interpreting patent claims, I could really use your help with my PhD research. My project involves applying artificial intelligence to analyse patent claim scope systematically, with the goal of better understanding how different legal and regulatory choices influence the boundaries of patent protection. But I need data to train my models, and that is where you can potentially assist me. If every qualified person who reads this request could spare just a couple of hours over the next few weeks, I could gather all the data I need.
The task itself is straightforward and web-based – I am asking participants to compare pairs of patent claims and evaluate their relative scope, using an online application that I have designed and implemented over the past few months. No special knowledge is required beyond the ability to read and understand patent claims in technical fields with which you are familiar. You might even find it to be fun!
There is more information on the project website, at claimscopeproject.net. In particular, you can read:
- a detailed description of the study, its goals and benefits; and
- instructions for the use of the online claim comparison application.
Thank you for considering this request!
Mark Summerfield
0 comments:
Post a Comment