Must-Read for In-House Patent Teams: Proving Software Patent Infringement Without Source Code – A Practical A-to-Z Guide to AI-Assisted Software Analysis

 

Software Patent Infringement: How Do You Prove It? This guide combines the latest reverse engineering techniques with Large Language Models (LLMs) to uncover crucial evidence within unseen code and create legally sound claim charts, all from the perspective of in-house patent experts.

 

Hello, patent professionals! Have you ever felt stuck, suspecting a competitor’s software infringes on your patent but having no way to prove it without the source code? Software patent infringement analysis is often compared to an investigation without a crime scene. You have to trace back the technical secrets using only one clue: the executable file distributed to the market.

Traditionally, this process required a massive amount of time and a high level of expertise. But now, Large Language Models (LLMs) are changing the game. LLMs are more than just assistants; they can be expert analytical partners with their own strengths—Claude for structuring vast documents, Gemini for multimodal analysis, and ChatGPT for drafting logical arguments.

This guide isn’t about turning patent attorneys or in-house counsel into reverse engineers. Instead, the goal is to provide a deep understanding of the process, enabling you to communicate effectively with technical experts and manage the quality of evidence that will ultimately decide the outcome of a lawsuit. So, shall we dive into the world of patent infringement analysis with AI? 😊

Notice: Guidance and Disclaimers

• This guide is for educational purposes only and does not constitute legal advice. Before beginning any analysis, you must consult with an intellectual property attorney in your jurisdiction.
• The legality of reverse engineering varies by country and is subject to laws and contractual agreements (like EULAs). Always confirm the applicable regulations with your legal team in writing beforehand.
• Do not send confidential code or assets to external LLM services. If unavoidable, proceed only after implementing safeguards like on-premise solutions, Data Loss Prevention (DLP), access controls, and a Data Processing Agreement (DPA).
• LLM outputs may contain errors or hallucinations. Treat any reasoning from a model as unverified information until it has been independently confirmed by an expert and corroborated with technical evidence.

 

Analysis Scenario: A Hypothetical Patent Infringement Case

To illustrate the process, let’s set up a fictional patent and an accused product.

Case Overview

• Fictional Patent: U.S. Patent No. 15/987,654, “Method for Data Processing and Transmission for Efficient File Synchronization.”
• Core Technology: A sequential process that ① detects file changes in real-time, ② compresses the data, ③ encrypts it with AES-256, and then ④ transmits it to a server.
• Target for Analysis: The Windows client for a cloud service called ‘SyncSphere,’ `SyncSphere.exe`.

 

Step 1: Legal & Forensic Pre-flight

Before any technical analysis begins, it’s crucial to establish the legal and procedural legitimacy of the entire process. The credibility of the evidence gathered in this stage will determine the direction of the entire case.

⚖️ Legal Pre-flight: Essential Checklist

• Authorization: Review the software’s End User License Agreement (EULA) to assess the validity and legal risks associated with any clauses prohibiting reverse engineering. (Must verify against local laws like the DMCA in the U.S. or the Copyright Act in South Korea).
• Attorney-Client Privilege: Clearly establish that the analysis is being conducted as part of legal counsel in anticipation of litigation. This helps protect the materials generated during the analysis.
• Counsel Sign-off: Obtain written approval from legal counsel before conducting legally sensitive actions, such as network traffic interception or memory dumps, which may be subject to communication privacy laws.
• Data Privacy: Evaluate the risk of collecting Personally Identifiable Information (PII) during dynamic analysis and establish measures to minimize or anonymize it in compliance with regulations like GDPR or PIPA.

Once the legal review is complete, begin the ‘Chain of Custody’ procedures, a fundamental principle of forensics. Calculate the SHA-256 hash of the `SyncSphere.exe` file to secure its “digital fingerprint” and meticulously document the versions of all analysis tools and the OS environment. All this information is recorded in a ‘Forensic Manifest’, which is the first step in ensuring the integrity and reproducibility of your evidence.

 

Step 2: Static Analysis – Uncovering the Code’s Blueprint

Static analysis involves dissecting the program’s internal structure without actually running it. This step helps verify if the program has the ‘capability’ to perform the patented technology and to form an infringement hypothesis.

Initial Reconnaissance

Before diving into the code, we use three reconnaissance techniques to set the direction of our analysis.

1. String Extraction: Use the command strings -a SyncSphere.exe > strings.txt to extract all hardcoded text from the file. Keywords like “zlib”, “AES”, and “OpenSSL” are strong initial clues that suggest the presence of compression and encryption functionalities.
2. PE Structure Analysis (PE-bear): Open `SyncSphere.exe` with a PE analysis tool to inspect the Import Address Table (IAT). The IAT is a list of external function dependencies, showing what functions the program borrows from Windows. File APIs from `kernel32.dll` (e.g., `CreateFileW`) indicate a capability for file detection (claim element a), while crypto APIs from `advapi32.dll` (e.g., `CryptEncrypt`) suggest an encryption capability (claim element c).
3. Library Signature Scanning (signsrch): If libraries like zlib or OpenSSL were statically linked (i.e., included directly in the code), they won’t appear in the IAT. A tool like signsrch can identify them by scanning for their unique code patterns (signatures).

📝 Note: Advanced Use of LLMs in the Reconnaissance Phase

Initial static analysis (reconnaissance and hypothesis formation) is about gathering clues to direct the analysis before deep-diving into decompilation. This process includes string extraction, PE structure analysis, and library signature scanning.

LLMs can be used here to efficiently organize vast amounts of output data. For instance, a `strings_output.txt` file can contain tens of thousands to millions of lines. An LLM can automatically summarize this, extracting only the keywords and surrounding context directly related to the patent claims (b) and (c), such as compression, encryption, and server communication.

Additionally, an LLM can normalize and deduplicate the imported APIs from PE-bear/DumpPE outputs, categorize them into functional groups like file I/O and cryptography, and map each item to a claim element. For example, `CreateFileW`, `ReadFile`, and `WriteFile` can be linked to (a) ‘file change detection capability,’ while `CryptEncrypt` or bcrypt-family functions can be linked to (c) ‘encryption capability.’ The LLM can then draft concise statements for each element and also note uncertainties, such as, “The presence of an import does not confirm its use at runtime,” and suggest what further evidence is needed.

Similarly, an LLM can normalize the results from Signsrch, remove duplicate signatures, and map each signature to its presumed library and version. This helps in describing whether static linking is present and connecting the detected libraries to claim (b) for compression (zlib) and (c) for encryption (OpenSSL/LibreSSL/AES).

*For the sake of readability, specific prompt examples for these tasks have been omitted from the main text.

Deep Dive with Ghidra & LLM

Using the clues from reconnaissance, we analyze the actual code logic with a decompiler like Ghidra or IDA Pro. By cross-referencing strings like ‘AES’, we can locate the core function containing the encryption logic (e.g., `process_file_for_upload`). We then examine the decompiled pseudo-code to see if the output of a `compress_data` function is passed directly as input to an `encrypt_data` function. This data flow is the key evidence that proves the sequential steps of the patent.

LLM Prompt Example: Code Logic Analysis and Structured Output

You can ask an LLM to translate complex pseudo-code into clear language that a legal professional can understand and to lay the groundwork for an analysis report.

# Role
You are a C++ reverse engineering expert supporting patent analysis.

# Input
Below is the pseudo-code for the `process_file_for_upload` function, decompiled using Ghidra.
[Paste Ghidra pseudo-code here]

# Task
1.  Describe the data processing pipeline (steps, order) of this function accurately.
2.  Confirm if the result of the compression is used as a direct input for the encryption and specify the variables that support this.
3.  State a clear conclusion on whether this function follows a 'compress-then-encrypt' architecture.
4.  Output the results in the JSON format below.

# Output Format (JSON)
{
  "finding_text": "A clear description of the function's behavior",
  "evidence_refs": ["Quote the lines of code that serve as evidence"],
  "confidence_score": 0.9,
  "uncertainties": ["What cannot be determined from the code alone"]
}
        

➡️ Expected LLM Output (JSON):

{
  "finding_text": "This function compresses the input data using zlib, then uses the compressed result directly as input for the AES encryption function, and finally sends it to the server. The compression clearly precedes the encryption, and the data flow is directly linked.",
  "evidence_refs": [
    "compressed_result = compress_data_with_zlib(original_data);",
    "final_payload = encrypt_data_with_aes(compressed_result->data, compressed_result->size);"
  ],
  "confidence_score": 0.9,
  "uncertainties": [
    "The AES mode of operation (e.g., CBC/GCM) and the key's origin cannot be determined from this code alone."
  ]
}
        

Heads up! The Limitations of Static Analysis
The findings from static analysis are merely a ‘hypothesis’ that must be proven with dynamic testing. The existence of a certain function in the code doesn’t guarantee it’s used at runtime in a manner that infringes the patent. Furthermore, if techniques like code obfuscation or packing are used, it can be extremely difficult to understand the true logic through static analysis alone.

 

Step 3: Dynamic Analysis – Capturing the Action

Dynamic analysis is the stage where you prove that the hypotheses formed during static analysis are actually put into ‘action’ at runtime, using objective logs and data. It is crucial that this process is conducted in a controlled environment (like a virtual machine or a rooted physical device).

1. Verifying Real-time Detection (Process Monitor): Use ProcMon to monitor file system access by `SyncSphere.exe`. Confirm with timestamps that as soon as a file is saved in the sync folder, `SyncSphere.exe` immediately triggers a related file event. This log becomes direct evidence of ‘real-time detection.’
2. Verifying Sequence and Data Flow (x64dbg): Attach a debugger (like x64dbg) to the running `SyncSphere.exe` process and set breakpoints at the memory addresses of the compression and encryption functions found in Step 2. When you sync a file, confirm the order in which the breakpoints are hit: ① the compression function should be hit first, followed by ② the encryption function. Crucially, verify that the memory address and size of the output buffer returned by the compression function exactly match the input buffer for the encryption function. This is the ‘smoking gun’ evidence that proves ‘compress-then-encrypt.’
3. Verifying Post-Encryption Transmission (Wireshark & Burp Suite): Capture the network traffic generated by the program with Wireshark. Analyze the entropy of the transmitted data. Well-encrypted data is close to random, so its entropy will approach the theoretical maximum of 8.0. High entropy is strong circumstantial evidence that the data was transmitted after encryption.

LLM Prompt Example: Correlating Multiple Logs

You can ask an LLM to synthesize disparate logs from ProcMon, x64dbg, and Wireshark into a single, coherent timeline of events.

# Role
You are a digital forensics expert.

# Input
[Paste combined, timestamped logs from ProcMon, x64dbg, and Wireshark here]

# Task
1.  Reconstruct a timeline by ordering all logs chronologically.
2.  Analyze whether a causal relationship exists for the sequence: "File Save → Compression Function Call → Encryption Function Call → Network Transmission."
3.  Confirm from the x64dbg log that the output buffer of the compression function matches the input buffer of the encryption function.
4.  Based on the above analysis, write a concluding statement that supports the patent infringement hypothesis.
        

Heads up! Real-World Hurdles in Dynamic Analysis
Commercial software employs various security measures to thwart analysis. SSL Pinning, for instance, hardcodes a specific server certificate into the app, causing the connection to fail if a man-in-the-middle (MITM) attack is attempted to intercept packets. Therefore, simply capturing packets is not enough to see the plaintext data. A dynamic instrumentation tool like Frida can be used to observe or manipulate function calls within the app, allowing you to see data before it’s encrypted. However, many commercial apps also include anti-debugging and anti-hooking techniques to detect and block these tools. For example, the app might terminate or branch to a different execution path if a debugger is detected, or it might block hooking attempts, rendering the analysis futile. Overcoming SSL pinning, MITM avoidance, and anti-analysis techniques requires a high degree of expertise and adherence to legal procedures.

 

Step 4: Creating a Claim Chart – Translating Evidence into a Legal Argument

The claim chart is the most critical legal document in a patent lawsuit. It’s an evidence comparison table that clearly maps the collected technical evidence to each element of the patent’s claims, acting as a bridge to help non-experts like judges and juries easily understand the infringement.

LLM Prompt Example: Drafting the Claim Chart Narrative

By providing the facts collected by the analyst, an LLM can be prompted to structure them into the prose suitable for a legal document.

# Persona and Mission
You are a technical expert in a patent litigation case. Using the provided evidence, draft the 'Evidence of Infringement' section of a claim chart. Your writing must be objective and fact-based. Each piece of evidence must be clearly cited with its corresponding label (e.g., [Evidence A]).

# Context
- Patent Number: U.S. 15/987,654
- Claim 1(c): ...a step of encrypting the compressed data using an AES-256 encryption algorithm and then transmitting it to a remote server...

# Input Data (Minimum Viable Evidence package)
- [Evidence B (Ghidra)]: `encrypt_data(compressed_result->data, ...)`
- [Evidence C (x64dbg)]: Input buffer: `0xDCBA0000`, size: 150 for `AES_256_encrypt`
- [Evidence D (Wireshark)]: Payload entropy: 7.98 bits/byte

# Task
For claim element (c), write a paragraph starting with "SyncSphere performs this step by..." and support your assertion with the provided evidence.
        

Final Claim Chart (Example)

Claim 1 Element of U.S. Patent No. 15/987,654	Corresponding Element and Evidence in Accused Product (‘SyncSphere’ Client v2.5.1)
(a) a step of detecting, in real-time, the creation or modification of a file within a designated local folder;	SyncSphere performs this step using an OS-level file system monitoring feature. When a user modifies a file in the designated ‘SyncSphere’ folder, the action is immediately detected, triggering the subsequent data processing procedures. [Evidence A: Process Monitor Log] clearly shows that the SyncSphere.exe process accessed the file immediately after the user modified it at timestamp 14:01:15.123.
(b) a step of first applying a data compression algorithm to the detected file before transmitting it to a remote server;	SyncSphere performs this step using a zlib-based compression library. [Evidence B: Ghidra Decompiled Code] shows that the `compress_data_with_zlib` function is called as the first step in the file processing function. [Evidence C: x64dbg Debugger Log] directly proves the actual execution order of this code. According to the log, the compression function (zlib.dll!compress) was clearly called before the encryption function.
(c) a method comprising the step of encrypting said compressed data by applying an AES-256 encryption algorithm, and then transmitting it to a remote server.	SyncSphere performs this step by directly passing the output of the compression step as input to the AES-256 encryption function. [Evidence B: Ghidra Decompiled Code] shows the data flow where the return value of the `compress_data_with_zlib` function is passed directly as an argument to the `encrypt_data_with_aes` function. [Evidence C: x64dbg Debugger Log] corroborates this data flow at the memory level. The output buffer address (e.g., 0xDCBA0000) and size (e.g., 150 bytes) from the compression function exactly matched the input buffer for the `libcrypto.dll!AES_256_cbc_encrypt` function. The subsequent transmission of the encrypted data is supported by [Evidence D: Wireshark Entropy Analysis]. The analysis revealed that the payload of data packets sent to the ‘SyncSphere’ server had a high entropy of 7.98 bits/byte, which is perfectly consistent with the statistical properties of AES-256 encrypted data.

 

Step 5: Expert Verification and Final Reporting – Giving Legal Weight to the Evidence

No matter how advanced AI becomes, it cannot assume legal responsibility. Every step of the analysis and all its outputs must be finally reviewed and signed off on by a human expert. All outputs generated by an LLM are merely ‘aids to interpretation,’ not evidence in themselves. This final step is what transforms the data organized by AI into powerful evidence with legal standing.

• Cross-Verification of Facts: Meticulously verify that all analytical content generated by the LLM (code explanations, log summaries, etc.) matches the source data, correcting any technical errors or logical fallacies.
• Integrity Assurance of the MVE Package: Finally, confirm the integrity of all items included in the Minimum Viable Evidence (MVE) package—from the hash value of the original file, to the versions of the tools used, all log records, and the records of interactions with the LLM.
• Signing the Expert Declaration (Affidavit): As the analyst, sign a legal document affirming that all procedures were followed and that the analysis results represent your professional opinion.

💡 Components of a Minimum Viable Evidence (MVE) Package
A Minimum Viable Evidence (MVE) package should consist of Identification Metadata, Static Evidence, Dynamic Evidence, Network Evidence, and a Concise Statement. It is best practice to store and share this as an archive (e.g., an encrypted ZIP file) along with an interchangeable JSON file.

Ultimately, it is the human expert who must testify in court and answer to cross-examination. It is only through these rigorous procedures that the data organized by AI is transformed into robust evidence that can withstand challenges in a legal setting.

📋

Patent Infringement Analysis Workflow Summary

🔒 1. Legal/Forensic Prep: Secure authorization for analysis and calculate the original file hash to start the Minimum Viable Evidence (MVE) package.

🔎 2. Static Analysis: Analyze the executable itself to identify the presence and order of code related to ‘compression’ and ‘encryption,’ forming an infringement hypothesis.

⚡ 3. Dynamic Analysis: Run the program to observe file I/O, function call order, and network traffic to substantiate the hypothesis.

✍️ 4. Claim Chart Creation:

Map the collected technical evidence (code, logs) to each claim element of the patent on a 1:1 basis.

👨‍⚖️ 5. Expert Verification: A human expert must finally verify all analysis results and LLM outputs, signing a legally binding declaration.

This systematic approach maximizes the credibility and legal defensibility of the evidence.

Conclusion: A Strategic Partnership Between Human Experts and AI

Using LLMs like ChatGPT, Gemini, and Claude in software patent infringement analysis is more than just a time-saver; it’s a strategic choice that elevates the depth and objectivity of the analysis. AI serves as a tireless partner, processing vast amounts of data and identifying patterns, while the human expert provides the creative insights and final legal judgment based on those findings.

Remember, the best tools shine brightest when they amplify the abilities of the person using them. We hope the forensics-based workflow presented in this guide will become a powerful and sharp weapon in defending your valuable intellectual property. If you have any further questions, feel free to leave a comment below!

 

Frequently Asked Questions (FAQ)

Q: Which LLM model is best to use?

A: There is no single ‘best’ model; there is only the ‘optimal’ model for each task. Claude might be better for summarizing and structuring long patent documents or logs, GPT-4o for complex code analysis and logical reasoning, and Gemini when visual materials like screenshots are involved. Understanding the strengths of each model and using them in combination is a key skill for an expert.

Q: Why is the ‘Minimum Viable Evidence (MVE) package’ so important?

A: The MVE is the core component that guarantees the ‘credibility’ and ‘reproducibility’ of the analysis results. During litigation, the opposing side will relentlessly attack questions like, “How was this evidence created?” and “Can the results be trusted?” The MVE transparently documents the entire process—from the original file to the tools used, all logs, and the analyst’s signature—defending against such attacks and serving as a legal safeguard that allows the judge to admit the evidence.

Q: Can I submit the JSON or code explanations generated by an LLM as evidence directly?

A: No. The outputs generated by an LLM (like JSON or code explanations) can be included in the MVE as a ‘record of the analysis process,’ but they are not the core evidence submitted directly to the court. The core evidence consists of the original log files, captured data, and, synthesizing all of this, the ‘Claim Chart’ and ‘Expert Report,’ written and signed by an expert. The LLM’s results are an intermediate product and a powerful aid in creating this final report.

Patentability of LLM Prompts: Overcoming Abstract Idea Rejections

 

Can a Simple Command to an AI Be Patented? This article provides an in-depth analysis of how LLM prompt techniques can transcend mere ‘ideas’ to be recognized as concrete ‘technical inventions,’ exploring key strategies and legal standards across different countries.

It seems that almost no one around us thinks of protecting prompt techniques or prompts that instruct LLM models with patents. At first, I was also skeptical, wondering, ‘Can a simple command to a computer be patented?’ However, as I delved deeper into this topic, I came to the conclusion that it is entirely possible if certain conditions are met. This article is a summary of the thought process I went through, and please bear in mind that it may not yet be an academically established view. 😊

 

🤔 Prompts Aren’t Patentable Because They’re Just ‘Human Thoughts,’ Right?

The first hurdle that comes to mind for many is the principle that ‘human mental processes’ are not patentable subject matter. In fact, the argument that “a prompt is fundamentally human involvement, and technology involving such human mental activity is not patentable” is one of the strongest reasons for rejection in patent examination. This standard has been particularly firm since the U.S. Supreme Court’s Alice Corp. v. CLS Bank decision. It means that merely implementing something on a computer that a person could do in their head is not enough to get a patent.

According to this logic, the act of instructing an AI through a prompt is ultimately an expression of human thought, so one could easily conclude that it cannot be patented. However, this argument is half right and half wrong. And this is precisely where our patent strategy begins.

💡 Good to Know!
What patent law takes issue with as ‘human intervention’ is not the act of giving a command to a system itself. It refers to cases where the core idea of the invention remains at the level of a mental step that can be practically performed in the human mind. Therefore, the key is to prove that our prompt technology transcends this boundary.

 

📊 A Shift in Perspective: From ‘Command’ to ‘Computer Control Technology’

The first step to unlocking the patentability of prompt technology is to change our perspective. We need to redefine our technology not as ‘a message sent from a human to an AI,’ but as ’a technology that controls the internal computational processes of a complex computer system (LLM) through structured data to solve a technical problem and achieve concrete performance improvements.’

If you take a close look at the algorithm of China’s DeepSeek-R1, you can see that it implements various prompt techniques as they are.

Think about it. The process of assigning a specific expert role to an LLM with billions of parameters, injecting complex library dependency information as context, and combining numerous constraints to control the generation of optimal code is clearly in a realm that ‘cannot practically be performed in the human mind.’ This is a crucial standard for recognizing patent eligibility in the guidelines and case law of the U.S. Patent and Trademark Office (USPTO).

 

🌍 A Comparative Look at Key Examination Standards of Major Patent Offices

The patentability of prompt technology is not assessed uniformly across all countries. If you are considering international filing, it is crucial to understand the subtle differences in perspective among major patent offices.

1. USPTO (United States Patent and Trademark Office) – Emphasis on the Abstract Idea Exception

The USPTO strictly applies the Alice/Mayo two-step test, which originated from Supreme Court case law. Instructions or general linguistic expressions that merely replace human thought processes can be dismissed as “abstract ideas.” However, if it can be demonstrated that the prompt is linked to a concrete technical implementation (e.g., improving model accuracy, optimizing specific hardware operations), there is a chance of it being recognized as patent-eligible subject matter.

2. EPO (European Patent Office) – Focus on Technical Effect

The EPO assesses based on “technical character” and “technical effect.” Simply presenting data input or linguistic rules is considered to lack inventive step, but if the prompt structure serves as a means to solve a technical problem (e.g., improving computational efficiency, optimizing memory usage, enhancing interaction with a specific device), it can be recognized as patent-eligible.

3. KIPO (Korean Intellectual Property Office) – Emphasis on Substantive Requirements for Software Inventions

KIPO places importance on the traditional requirement of “a creation of a technical idea utilizing the laws of nature.” Therefore, a prompt as a mere sentence or linguistic rule is not considered a technical idea, but if it is shown to be combined with a specific algorithm, hardware, or system to produce a concrete technical result, it can be recognized as an invention. In Korean practice, presenting a concrete system structure or processing flow is particularly persuasive.

Key Comparison Summary

Patent Office	Key Requirement
USPTO (U.S.)	Emphasis on ‘concrete technical implementation’ to avoid the abstract idea exception
EPO (Europe)	Proof of ‘technical effect’ is key; simple data manipulation is insufficient
KIPO (Korea)	Must be a technical idea using laws of nature + emphasis on systemic/structural implementation

⚠️ Implications for International Filing
The same “LLM prompt” technology could be at risk of being dismissed as an “abstract business method” in the United States, a “non-technical linguistic rule” in Europe, and a “mere idea” in Korea. Therefore, when considering international filing, a strategy that clearly articulates the ‘concrete system architecture’ and ‘measurable technical effects’ throughout the specification is essential as a common denominator.

 

🧮 A Practical Guide to Drafting Patent Claims (Detailed)

So, how should you draft patent claims to avoid the ‘human intervention’ attack and clearly establish that it is a ‘technical invention’? Let’s take a closer look at four key strategies.

1. Set the subject as the ‘computer (processor),’ not the ‘person.’

This is the most crucial step in shifting the focus of the invention from the ‘user’s mental activity’ to the ‘machine’s technical operation.’ It must be specified that all steps of the claim are performed by computer hardware (processor, memory, etc.).

• Bad 👎: A method where a user specifies a persona to an LLM and generates code.
• Good 👍: A step where a processor, upon receiving a user’s input, assigns a professional persona for a specific programming language to the LLM.

2. Specify the prompt as ‘structured data.’

Instead of abstract expressions like ‘natural language prompt,’ you need to clarify that it is a concrete data structure processed by the computer. This shows that the invention is not just a simple idea.

• Bad 👎: A step of providing a natural language prompt to the LLM.
• Good 👍: A step of generating and providing to the LLM a machine-readable context schema that includes library names and version constraints.

3. Claim ‘system performance improvement,’ not the result.

Instead of subjective results like ‘good code,’ you must specify objective and measurable effects that substantially improve the computer’s functionality. This is the core of ‘technical effect.’

• Bad 👎: A step of generating optimized code.
• Good 👍: A step of controlling the LLM’s token generation probability through the schema to generate optimized code that reduces code compatibility errors and saves GPU memory usage.

4. Clarify the ‘automation’ process.

It should be specified that all processes after the initial input (data structuring, LLM control, result generation, etc.) are performed Automatically by the system without further human judgment, demonstrating that it is a reproducible technical process.

 

📜 Reinforced Claim Example

By integrating all the strategies described above, you can construct a reinforced patent claim as follows.

[Claim] A computer-implemented method for generating optimized code, comprising:

1. (a) parsing, by a processor, a user’s natural language input to generate a persona identifier defining an expert role for a specific programming language;
2. (b) generating, by the processor, by referencing said input and an external code repository, structured context data including library names, version constraints, and hardware memory usage limits;
3. (c) generating, by the processor, a control prompt including said persona identifier and structured context data and transmitting it to an LLM, thereby automatically controlling the internal token generation process of the LLM;
4. (d) receiving, from said controlled LLM, optimized code that satisfies said constraints and has a compilation error rate below a predefined threshold and reduced GPU memory usage.

→ This example, instead of focusing on a simple result, greatly increases the chances of patent registration by clarifying system-level measurable technical effects such as ‘reduced compilation error rate’ and ‘reduced GPU memory usage.’

 

Frequently Asked Questions ❓

Q: Can a simple prompt like "write a poem about a cat" be patented?

A: No, that in itself is just an idea and would be difficult to patent. The subject of a patent would be a technical method or system that uses a prompt with a specific data structure (e.g., a schema defining poetic devices, rhyme schemes) to control an LLM to generate a poem, resulting in less computational resource usage or more accurate generation of a specific style of poetry.

Q: What are some specific ‘technical effects’ of prompt technology?

A: Typical examples include reduced compilation error rates in code generation, savings in computational resources like GPU and memory, shorter response generation times, and improved output accuracy for specific data formats (JSON, XML, etc.). The important thing is that these effects must be measurable and reproducible.

Q: Do I need to draft claims differently for each country when filing internationally?

A: Yes, while the core strategy is the same, it is advantageous to tailor the emphasis to the points that each patent office values. For example, in a U.S. (USPTO) specification, you would emphasize the ‘concrete improvement of computer functionality,’ in Europe (EPO), the ‘technical effect through solving a technical problem,’ and in Korea (KIPO), the ‘concreteness of the system configuration and processing flow.’

In conclusion, there is a clear path to protecting AI prompts with patents. However, it requires a strategic approach that goes beyond the idea of ‘what to ask’ and clearly demonstrates ‘how to technically control and improve a computer system.’ I hope this article provides a small clue to turning your innovative ideas into powerful intellectual property. If you have any more questions, feel free to ask in the comments~ 😊

※ This blog post is intended for general informational purposes only and does not constitute legal advice on any specific matter. For individual legal issues, please consult a qualified professional.