– and the Patent Window Most Teams Miss

PAT testing asks one simple question:

Is this software really ready for production?

But if you build valuable software or AI, there is a second question worth asking at exactly the same time:

Did we just build something worth patenting?

That question gets missed constantly.

During Production Acceptance Testing, engineers often discover the most valuable technical work in a release:

• a faster way to route requests;
• a new model-selection system;
• a memory-saving architecture;
• a safer recovery process;
• a better synchronization method;
• a new inference pipeline;
• an unusual security mechanism;
• a database architecture that survives failures;
• an orchestration layer that cuts latency or compute cost.

Then the team fixes the problem.

PAT passes.

The product ships.

Nobody tells the patent lawyer.

That can be a costly mistake.

This guide explains PAT testing from an engineering point of view. But it goes one step further: it shows software and AI companies how to turn PAT into an invention-capture checkpoint.

That matters because software patents are rarely about “an app.” They are about the technical machinery underneath it. PatentPC explains that distinction in its guides to what a software patent actually protects, what can be patented in software, and whether software can be patented at all.

---

What Is PAT Testing in Software?

PAT usually means Production Acceptance Testing.

It is the final production-readiness check before a system is released or accepted into live operation.

The terminology is not perfectly standardized. Formal testing literature often uses Operational Acceptance Testing, or OAT, for closely related work. The ISTQB framework includes operational testing around recovery, backup and restore, installation, maintainability, and related production concerns. See the ISTQB Certified Tester Foundation Level materials.

Google’s Site Reliability Engineering practice uses another closely related concept: the Production Readiness Review. Its goal is to determine whether a service is truly ready to operate reliably in production. See Google SRE’s Production Readiness Review model.

So ignore the acronym fight.

The useful definition is:

PAT is the evidence-based decision that a system can survive production—not merely work in a test environment.

A product can pass functional testing and still be dangerous to release.

It may work with 20 users but collapse with 20,000.

It may save data correctly until two services write at the same time.

It may recover from one failure but destroy state after a second.

It may run an AI feature beautifully until the model provider times out.

PAT tries to find those gaps before your customers do.

---

Why Should PatentPC Care About PAT Testing?

Because PAT happens at a rare point in the life of a technical invention.

By PAT:

The technology is mature enough to explain.

The engineering team has real evidence showing what improved.

The product may still be private.

That combination is valuable.

Very early in development, an invention may be too vague.

Months after launch, engineers may barely remember why an architectural decision was made.

PAT sits between those points.

And that makes PAT a natural moment for an IP review.

Think of the three questions:

Review	Core question
User Acceptance Testing	Can the user successfully use this?
Production Acceptance Testing	Can we safely run this at scale?
Patent review	Did we solve a technical problem in a new and protectable way?

For an important software release, all three can matter.

This does not mean every bug fix deserves a patent.

It means PAT often exposes the exact technical improvements that should at least be screened.

That is especially relevant to U.S. software patents because technical improvement can matter enormously to patent eligibility. PatentPC has deeper guides on technical improvements in software patentability and technical effects in software patent applications.

---

PatentPC Original Research: GenAI Patent Publication Velocity Is Now 5.21× the Previous Decade’s Pace

This is where timing becomes interesting.

We took WIPO’s public GenAI patent-family data and recombined it to answer a practical question:

How much faster is the public GenAI patent landscape changing now than it did during the previous decade?

WIPO identified 54,358 GenAI patent families published from 2014 through 2023 in its Generative Artificial Intelligence Patent Landscape Report.

Its newer GenAI data reports 18,862 published families in 2024 and 37,808 in 2025. See WIPO’s latest GenAI patent-trend data.

Now do the math.

2014–2023

54,358 families ÷ 10 years =

5,435.8 published patent families per year

2024–2025

18,862 + 37,808 = 56,670

56,670 ÷ 2 =

28,335 families per year

Acceleration

28,335 ÷ 5,435.8 =

5.21×

That means the recent GenAI patent-family publication rate was more than five times the annual average of the previous decade.

This is not somebody else’s headline.

It is a PatentPC calculation derived from WIPO’s public data.

And it leads to an even stranger number.

---

More Than Half of the 2014–2025 GenAI Families Arrived in Just Two Years

Add the periods together:

2014–2023: 54,358

2024–2025: 56,670

Total: 111,028

Now calculate the final two years’ share:

56,670 ÷ 111,028 = 51.04%

So:

Roughly 51% of all GenAI patent families published across the entire 2014–2025 period appeared in 2024 and 2025 alone.

WIPO reaches the same broad conclusion in its updated SPARK GenAI executive summary: more GenAI patent families were published during 2024–2025 than during the entire previous decade.

PatentPC tracks the wider race in its own analysis of the global AI patent boom.

---

Six Months Today Equals Roughly 2.6 Years of the Old GenAI Patent-Publication Pace

The comparison gets more useful when translated into a founder’s timeline.

At the 2024–2025 average:

28,335 ÷ 2 =

14,167.5 published GenAI families every six months

At the 2014–2023 average:

14,167.5 ÷ 5,435.8 =

2.61 years

So:

Six months of GenAI patent-family publications at the recent pace equals roughly 2.6 years of publications at the previous decade’s average pace.

That does not mean 14,168 patents suddenly become prior art against your invention every six months.

Many will be irrelevant.

Some concern completely different technologies.

Some belong to different jurisdictions or claim different subject matter.

The point is velocity.

A fast-moving technical field creates a fast-moving search landscape.

WIPO’s detailed global GenAI patent-trend analysis shows just how quickly applicant activity, countries, and underlying model types are changing.

PatentPC’s guide to AI patent analytics for competitive intelligence explains why monitoring patent data can be valuable well beyond the filing itself.

---

LLM Patent Publication Volume Grew Roughly 16× in Two Years

Large language models show the acceleration even more clearly.

WIPO reports:

2023 LLM patent families: 881

2025 LLM patent families: more than 14,100

14,100 ÷ 881 ≈

16×

In two years.

WIPO also reports about 5,245 GAN-related families in 2025, meaning LLM family publications were roughly:

14,100 ÷ 5,245 =

2.69× the GAN total

in that year.

See WIPO’s model-level GenAI patent analysis.

That is a useful warning for AI companies.

The patent landscape around a technical area can look materially different by the time a long product-development cycle ends.

PatentPC covers some of the legal consequences in Overcoming Challenges in AI Patentability and AI Patent Eligibility: Overcoming Barriers in Machine Learning Innovations.

---

There Is Another Problem: The Patent Landscape Has an 18-Month Blind Spot

Suppose your patent search looks clean today.

That does not mean nobody filed something relevant recently.

U.S. nonprovisional patent applications are generally published after roughly 18 months from the earliest claimed filing date, subject to statutory exceptions. See USPTO MPEP §1120 on eighteen-month publication.

That creates an unavoidable blind spot.

A company might have filed relevant technology twelve months ago.

You may not see it yet.

This is why a patent search should be treated as a risk-reduction exercise, not as a certificate saying “nobody else has this.”

And in a field where public patent-family volume is moving five times faster than the prior-decade average, stale searches become more dangerous.

PatentPC’s guide to conducting a patent search explains what a serious search should look for.

You can also search published U.S. patents and applications directly through the USPTO Patent Public Search database.

---

The PAT-to-Patent Pipeline

Normal PAT asks:

Will the system work in production?

IP-aware PAT adds:

What did we invent while making it work in production?

That requires surprisingly little extra process.

When a difficult PAT problem produces an important technical fix, capture six things:

Question	Why it matters
What technical problem occurred?	Defines the problem
What did the old system do?	Establishes the baseline
What exactly changed?	Finds the mechanism
Why did normal fixes fail?	Helps reveal what may be non-routine
What improved afterward?	Captures technical effect
Would competitors want this mechanism?	Tests commercial relevance

The most important rule is this:

Do not confuse the result with the invention.

“Latency dropped 43%” is a result.

The invention, if one exists, is how the system caused latency to drop.

“Hallucinations fell 30%” is a result.

The potentially patentable technology may lie in a new retrieval, validation, routing, memory, or generation architecture.

“GPU cost fell 38%” is a result.

The invention might be an inference scheduler that changes model selection based on request state, available compute, predicted token count, and cached intermediate representations.

That distinction is central to building strong software claims.

See PatentPC’s guide to getting strong software patents.

---

Ten PAT Findings That Should Trigger an IP Question

PAT finding	Ask this patent question	Preserve this evidence
Latency explodes under load	Did we invent new scheduling, caching, or routing?	Before/after latency, architecture
Memory spikes	Did storage, state, or retrieval architecture change?	Memory profiles, data structures
Throughput stops scaling	Did we create new batching, partitioning, or concurrency logic?	Load curves, bottlenecks
Failover loses state	Is recovery, replication, or reconciliation new?	Failure traces, state diagrams
Retries create duplicates	Is the transaction or idempotency mechanism unusual?	Old/new sequences
Deployment corrupts data	Is the migration or compatibility method novel?	Migration and rollback flow
AI inference costs too much	Did we invent routing, caching, distillation, or inference logic?	Cost, latency, and compute data
AI outputs fail unpredictably	Did we create new grounding, validation, or control architecture?	Error classes and mechanism
Security test exposes weakness	Did we invent a new isolation, authentication, or privacy technique?	Threat model, architecture
Edge devices lose synchronization	Did we invent conflict-resolution or offline-state handling?	Network and state-transition tests

Again:

Most fixes will not become patents.

That is fine.

The point is to stop the valuable ones from disappearing unnoticed.

---

What Should Production Acceptance Testing Actually Cover?

PAT needs to reflect the real failure modes of the system.

A serious release usually needs more than a final functional test.

---

1. Critical Workflows

Test the things the system simply cannot afford to get wrong.

For SaaS software, these may include:

• authentication;
• account creation;
• payments;
• permissions;
• data saving;
• imports and exports;
• API calls;
• integrations;
• admin controls;
• critical automation.

But do not ask only:

Does it work?

Ask:

Does it still work when the environment behaves badly?

---

2. Load, Latency, and Capacity

Test:

• P50, P95, and P99 latency;
• throughput;
• concurrent users;
• queue depth;
• database pressure;
• memory;
• CPU;
• storage;
• bandwidth;
• external API limits.

DORA’s current framework tracks software-delivery performance through metrics including change lead time, deployment frequency, failed-deployment recovery time, change fail rate, and deployment rework rate. See the DORA software-delivery performance metrics.

The deeper lesson is simple:

Speed without stability is not production readiness.

---

3. Reliability and Recovery

Break things.

Kill a process.

Make a dependency unavailable.

Expire a credential.

Drop network packets.

Fill the queue.

Restart a node.

Corrupt a message.

Then observe whether the system:

1. detects the failure;
2. contains it;
3. recovers;
4. preserves important data;
5. explains what happened.

Google’s Production Readiness Review specifically treats reliability, monitoring, emergency response, capacity, latency, dependencies, and operational readiness as production concerns. See Google’s SRE production-readiness framework.

---

4. Deployment and Rollback

A release is not safe just because the new version runs.

Test whether you can:

• deploy reliably;
• handle partial deployment;
• roll backward;
• fix forward;
• migrate databases;
• survive version mismatches;
• disable dangerous features;
• preserve state during change.

This is also one of the places inventions hide.

Teams sometimes solve deployment failures with genuinely new state-management, migration, synchronization, or compatibility techniques.

---

5. Backup and Recovery

Do not ask:

Did the backup job run?

Ask:

Can we actually rebuild the system from it?

A backup that has never been restored successfully is closer to a hope than a recovery plan.

---

6. Security

PAT should also test the security assumptions that matter in production.

NIST’s Secure Software Development Framework provides a structured approach to reducing software vulnerabilities across the development life cycle.

For AI systems, NIST has also published a dedicated Secure Software Development profile for generative AI and foundation models.

For web applications, the OWASP Application Security Verification Standard gives engineering teams a structured set of application-security verification requirements.

If your engineering team solves a security failure by creating a genuinely new technical mechanism rather than simply implementing a standard control, that mechanism may deserve an IP review too.

---

7. Observability

Ask:

If this breaks at 2:13 a.m., can we tell exactly what happened?

Test:

• structured logs;
• distributed traces;
• metrics;
• alert thresholds;
• dashboards;
• request IDs;
• model calls;
• external dependencies;
• state transitions;
• failure events.

A system is much harder to operate when the team only knows that something failed.

Good PAT proves that the team can diagnose why.

---

PAT for AI Systems Needs a Bigger Checklist

AI software adds failure modes that conventional applications may not have.

Depending on the system, test:

• hallucinations;
• retrieval failures;
• context-window overflow;
• tool errors;
• model outages;
• prompt injection;
• indirect prompt injection;
• unsafe tool permissions;
• runaway agents;
• agent loops;
• structured-output failures;
• confidence failures;
• fallback-model behavior;
• model-routing mistakes;
• token-cost spikes;
• latency spikes;
• memory failures;
• stale embeddings;
• unsafe autonomous actions;
• bad escalation decisions.

NIST’s AI Risk Management Framework provides a wider framework for managing AI risk.

Its separate Generative AI Profile identifies GenAI-specific risks and risk-management actions.

For security specifically, OWASP documents risks such as prompt injection against LLM systems.

But here is the patent question hiding behind all of these tests:

What new technical mechanism did we create to make the AI system work better?

PatentPC examines related issues in its guides to machine learning in AI patent applications and explainability in AI patents.

---

Recentive Gives AI Founders an Important Warning

In Recentive Analytics, Inc. v. Fox Corp., the Federal Circuit considered patents using machine learning for television scheduling and network-map generation.

The court affirmed patent ineligibility.

A central problem was that the claims effectively applied generic machine-learning technology to particular tasks rather than claiming a sufficient technological improvement in machine learning or another technical process. Read the Recentive decision.

That gives AI companies an important lesson:

“Use AI to do X” is not much of an invention story.

You need to dig deeper.

What changed technically?

What does the model or system now do differently?

How is data represented?

How does training work differently?

How are computer resources used differently?

How does the architecture solve a technical problem?

That is why PatentPC’s guide to the Alice test and software patents is important reading for software founders.

For a broader strategy discussion, see Software Patents Post-Alice.

The USPTO maintains its current subject-matter eligibility guidance and its detailed MPEP §2106 eligibility framework.

---

Desjardins Shows the Other Side of the AI Patentability Problem

Now compare that with Ex parte Desjardins.

The USPTO’s Appeals Review Panel found claims involving machine-learning improvements eligible under §101.

The USPTO described the technology as involving technical improvements to AI operation and later made the decision precedential. See the USPTO’s precedential Ex parte Desjardins announcement.

The USPTO subsequently updated its guidance to address technological improvements involving computers, data structures, learning models, and related applied fields. See the USPTO’s Desjardins-related eligibility update.

Recentive and Desjardins do not erase each other. They arise in different procedural contexts, and a Federal Circuit opinion carries different authority from a PTAB decision.

But together they expose the drafting question founders should care about:

Are you merely applying AI to a task?

Or:

Did you actually improve the technology?

The USPTO has also specifically published AI-focused subject-matter eligibility guidance.

PatentPC goes deeper in its guide to AI patent eligibility and machine-learning inventions.

---

Why PAT Evidence Can Be Gold for Patent Drafting

Compare two invention disclosures.

Weak

We created an AI system that improves responses and makes the application faster.

That tells patent counsel almost nothing.

Strong

Under peak load, the previous architecture sent all requests through the same inference path, increasing P95 latency to 1.8 seconds. We added a request-state classifier that predicts the minimum model class needed, checks reusable intermediate representations, and routes only unresolved requests to the larger model. Under the same load test, P95 fell to 620 milliseconds and GPU time per request fell 38%.

Now we have:

• a technical problem;
• the old architecture;
• a specific mechanism;
• measurable results;
• test conditions;
• possible alternative embodiments.

That is much better patent material.

It still does not automatically prove novelty, non-obviousness, eligibility, or enforceability.

But it gives an experienced software patent attorney something concrete to analyze.

That is why PatentPC emphasizes the technical architecture behind software inventions rather than merely restating product features. See PatentPC’s software patent attorney guide.

---

Save the Evidence While It Still Exists

A PAT team may have something a patent attorney interviewing the engineers six months later does not:

the actual experiment.

Save:

Evidence	Capture
Problem	What failed or bottlenecked?
Baseline	What did the prior architecture do?
Mechanism	What exactly changed?
Before architecture	Diagram it
After architecture	Diagram it
Data flow	What moves where?
Measurements	Latency, compute, memory, storage, accuracy, throughput
Test setup	Hardware, traffic, dataset, load
Failed approaches	What did you try first?
Alternatives	What else could implement the same concept?
Failure modes	What breaks when parts are removed?
Inventors	Who conceived which features?
Dates	When was each feature conceived?
Disclosure date	When will it become public?
Product role	Why does the feature matter commercially?
Detectability	Could competitor use be detected?

This evidence can also matter when arguing that an invention produces a real technical improvement.

The USPTO has issued guidance on using factual declarations in subject-matter eligibility disputes. See USPTO guidance on subject-matter eligibility declarations.

---

AI Companies Should Document the Humans Too

AI now helps engineers write code, explore architectures, generate tests, and propose technical solutions.

That creates another documentation problem:

Who invented what?

Current USPTO guidance says AI systems themselves are not inventors. Inventorship continues to turn on human inventorship principles even when AI tools assist the work. See USPTO’s revised inventorship guidance for AI-assisted inventions.

So when an important invention appears during PAT, record:

• who identified the technical problem;
• who conceived the architecture;
• who conceived important variations;
• what role AI tools played;
• what the humans contributed.

PatentPC discusses related protection questions in AI Copyright vs. AI Patents.

---

The Launch-Day Trap

Imagine this timeline.

Friday

PAT passes.

Monday

The product goes live.

Tuesday

Engineering publishes a technical blog post.

Wednesday

The CTO demos the architecture at a conference.

Thursday

Somebody asks:

“Should we patent this?”

That order is backwards.

The U.S. gives inventors a limited grace period for certain inventor-originated disclosures.

But foreign patent rights can be less forgiving.

The USPTO expressly warns that a disclosure that may still leave a U.S. filing path open can prevent patenting in foreign countries. See USPTO provisional application guidance.

So the cleaner operating rule is:

If international patent protection might matter, perform the IP review before public launch.

PatentPC explains the filing mechanism in What Is a Provisional Patent Application? and Basics for Provisional Patent Applications.

If the team needs to document the invention quickly, PatentPC also has a detailed guide to writing a provisional patent application.

---

A Rushed Provisional Can Create False Confidence

There is an important catch.

“File something before launch” does not mean:

Throw two slides and a product description into a provisional.

The USPTO explains that later claims only get the benefit of the provisional filing date when the provisional provides adequate support for the claimed subject matter. See the USPTO’s provisional application requirements.

For technical software, that means the filing should capture the actual invention:

• architecture;
• algorithms;
• data structures;
• steps;
• flows;
• interfaces;
• alternatives;
• embodiments;
• failure handling;
• variations.

The more strategically important the invention, the less sense it makes to treat the first filing as meaningless paperwork.

---

International Strategy Should Be Decided Early Too

Companies often assume that “filing a patent” means one worldwide patent.

It does not.

Patent rights are territorial.

The Patent Cooperation Treaty can simplify the process of seeking protection across many countries, but patent grants remain controlled by national and regional offices. See the USPTO Patent Cooperation Treaty guide.

The USPTO also provides a separate overview of filing patent applications abroad.

PatentPC breaks down the practical economics in its guide to international software patent costs.

---

Search the Mechanism—Not the Marketing Phrase

Suppose the company markets its product as:

“AI Copilot for Insurance Claims.”

Searching only for that phrase is weak.

Break the invention apart.

Input

What data comes in?

Transformation

What happens to the data?

State

What information is retained?

Decision

What determines the next step?

Output

What does the machine produce?

Constraint

What latency, memory, compute, security, accuracy, or reliability problem does the system solve?

Now your invention may look like:

claim-document ingestion → multimodal extraction → confidence classification → adaptive model selection → retrieval-scope generation → consistency verification → exception routing

That is far more useful.

You are searching the machinery.

Not the slogan.

---

Patent, Trade Secret, or Copyright?

PAT can also reveal that a patent is not the best answer.

Different parts of software can be protected in different ways.

Protection	Often useful for
Patent	New technical mechanisms
Trade secret	Valuable information that can realistically remain secret
Copyright	Original software expression and other copyrightable material
Trademark	Brand identity
Hybrid	Different layers of the same product

WIPO explains that copyright generally protects software expression, while patent protection may be relevant to software-related inventions. See WIPO on copyright protection for computer software.

Trade secrets can protect valuable confidential information so long as the legal requirements for secrecy are maintained. But trade-secret protection generally cannot stop someone who independently develops the same technology or lawfully reverse-engineers it. See WIPO’s Trade Secrets FAQ.

For AI-generated and AI-assisted content, the U.S. Copyright Office has separately analyzed the human-authorship requirement. See the U.S. Copyright Office Artificial Intelligence Study.

A serious IP strategy therefore asks:

Which parts should competitors be legally prevented from practicing?

Which parts can we realistically keep hidden?

Which parts are expression rather than invention?

That is a much better question than:

“Should we patent our software?”

---

Your Jira Backlog May Contain Your Next Patent

Search recently closed engineering tickets for words like:

• redesigned;
• optimized;
• custom;
• workaround;
• new architecture;
• replaced;
• reduced memory;
• reduced latency;
• new scheduler;
• new cache;
• routing;
• recovery;
• reconciliation;
• compression;
• adaptive;
• dynamic selection;
• synchronization;
• parallelized;
• new pipeline.

Then ask what actually happened.

Inventions rarely arrive with an engineering ticket labeled:

PATENTABLE INVENTION

They look like:

Production falls apart above 8,000 concurrent users. We need another architecture.

Or:

Every request goes through the expensive model. We need smarter model routing.

Or:

Offline devices keep overwriting newer state. The reconciliation model has to change.

Or:

The agent keeps taking unsafe actions when retrieved context is poisoned. We need another control layer.

Those sound like engineering problems.

Sometimes the solution is routine.

Sometimes it is not.

---

A 15-Minute PAT-to-IP Review

This should not become another giant internal meeting.

At the end of an important production-readiness cycle, put the CTO or engineering lead, product owner, and IP counsel together for 15 minutes.

Ask:

Time	Question
Minutes 0–3	What were the hardest technical problems in this release?
Minutes 3–6	Which fixes required us to invent rather than configure?
Minutes 6–9	What measurable technical effect did each fix create?
Minutes 9–11	Which mechanisms would competitors want?
Minutes 11–13	What is about to become public?
Minutes 13–15	File, investigate, keep secret, or ignore?

That is enough for triage.

Counsel does not need to sit inside every engineering meeting.

Engineering does need a reliable way to raise its hand when something important happens.

---

The PatentPC PAT Patent Score

For faster triage, score a PAT-originated improvement from 0 to 2 on six factors.

Factor	0	1	2
Technical novelty signal	Routine	Unclear	Clearly unusual
Technical effect	Little	Moderate	Strong
Strategic value	Minor	Useful	Core
Competitor relevance	Low	Possible	High
Detectability	Hard	Partial	Good
Disclosure urgency	None	Months away	Imminent

Maximum:

12 points

This is not a patentability test.

It is a management tool.

A 2/12 optimization can probably remain in engineering.

An 11/12 architecture that powers your main product advantage and will be demonstrated publicly next week deserves immediate legal review.

That is a far better allocation of patent-lawyer time.

---

Another PatentPC Calculation: “We’ll Review Patents Next Quarter” Now Means About 7,084 More GenAI Family Publications

At the 2024–2025 GenAI pace:

28,335 annual families ÷ 4 =

7,083.75 published patent families per quarter

Call it roughly:

7,084 every three months.

Again, this does not mean 7,084 relevant blockers appear against your product every quarter.

But it shows the scale of movement.

An AI company saying:

“Let’s think about patents in three or six months.”

is allowing two clocks to run.

Clock 1: Disclosure

Launches, demos, public docs, conferences, and sales activity may affect filing strategy.

Clock 2: Patent Landscape

New prior-art publications continue appearing.

And because of the normal publication delay, some pending applications are already in the pipeline while still invisible.

That is why the right time for an IP checkpoint is usually before launch, not months afterward.

---

Production Acceptance Should End With Four Decisions

Most software teams finish PAT with one:

SHIP / DO NOT SHIP

A mature technology company can finish with four:

1. Ship?

Can we safely release this?

2. Protect?

Did we create potentially valuable patentable technology?

3. Keep Secret?

Should any technical advantage remain confidential instead?

4. Preserve?

What engineering, inventorship, and performance evidence should we retain?

That fourth question is useful even when no patent is filed.

Good engineering evidence does not suddenly become useless because counsel decides against filing.

---

What Does This Look Like in an Actual AI Product?

Imagine a company building an AI customer-support agent.

Staging looks great.

Then PAT exposes four problems.

Problem 1

P95 response time jumps from 1.4 seconds to 7.8 seconds during bursts.

Problem 2

The system sends simple requests to the most expensive model.

Problem 3

Two tools occasionally modify the same customer record at once.

Problem 4

When retrieval confidence is low, the agent still produces a confident answer.

Engineering fixes them using:

A

A state-aware batching and scheduling architecture.

B

A predictive model router that chooses among models using request characteristics and confidence.

C

A transaction and reconciliation mechanism for parallel agent operations.

D

A retrieval-confidence controller that changes the agent’s allowed action set and escalation behavior.

The product now passes PAT.

A normal organization says:

Great. Ship it.

An IP-aware company asks:

Is A new?

Is B new?

Is C new?

Is D new?

Maybe none are.

Maybe B already exists.

Maybe C is best kept secret.

Maybe B + D together form the valuable architecture.

Maybe D becomes the core reason regulated enterprise customers choose the product.

That is the point of the review.

Do not guess.

---

The Real Software-Patent Question Is Not “Can I Patent My App?”

That question is too broad.

A stronger question is:

Which technical mechanism inside this product gives us an advantage worth owning?

Your UI may not be the invention.

Your business idea may not be the invention.

“Using AI for doctors” is not much of an invention by itself.

“Using machine learning for insurance” is not much of an invention by itself.

The protectable value may sit deeper inside:

• model training;
• inference;
• model routing;
• retrieval;
• caching;
• memory;
• distributed systems;
• synchronization;
• compression;
• security;
• privacy;
• networking;
• database architecture;
• fault recovery;
• resource allocation;
• computer vision;
• hardware/software interaction;
• agent orchestration.

That is why software patent work requires technical understanding.

---

Strong Software Patents Start With a Technical Story

A good invention disclosure can often begin with seven sentences:

1. The old system did _____.

2. That created technical problem _____.

3. Normal solutions failed because _____.

4. We changed the system by _____.

5. The new mechanism works by _____.

6. This produced technical effect _____.

7. The mechanism could also be implemented as _____, _____, or _____.

If your engineering team cannot fill those blanks, the invention may not yet be understood well enough.

If it can, you have the beginning of a useful patent discussion.

---

Patent Claims Should Protect the Invention—Not Today’s Exact Code

Suppose your current implementation uses:

• PostgreSQL;
• AWS Lambda;
• one specific embedding model;
• Redis;
• GPT-X.

Those implementation choices may change next year.

The invention may sit one layer above them.

Good patent drafting asks:

What is the durable technical idea?

Which elements are essential?

Which are optional?

How else could a competitor implement the same idea?

What would version two look like?

What design-arounds are obvious?

Can the claims cover those alternatives without outrunning the invention and prior art?

That is where experienced software and AI patent counsel earns its value.

PatentPC’s attorneys work across software, networking, cloud systems, AI, semiconductors, and related technology. Meet PatentPC’s patent and technology team.

---

Should Every Good PAT Fix Become a Patent?

No.

Some improvements are poor patent investments.

Examples:

• routine configuration;
• tiny implementation optimizations;
• features with a short useful life;
• improvements crowded by prior art;
• mechanisms competitors can easily avoid;
• methods impossible to detect in competitors;
• technology better kept secret.

Patents should serve the business.

Ask:

Does this protect a core product advantage?

Will competitors need something similar?

Does it matter to fundraising?

Does it matter to licensing?

Could it matter in an acquisition?

Can competitor use be detected?

Will the technical advantage still matter several years from now?

PatentPC discusses the business side in How Patents Help in Valuation Talks with Investors, How to Conduct an IP Valuation Investors Actually Trust, and How to Value IP Before Licensing, Sale or Fundraising.

---

What Should You Give Your Software Patent Attorney After PAT?

Not a pitch deck.

Give counsel:

1. the old architecture;
2. the technical problem;
3. the failed approaches;
4. the new architecture;
5. flowcharts;
6. sequence diagrams;
7. test results;
8. performance deltas;
9. alternative implementations;
10. inventor names;
11. upcoming disclosure dates;
12. the product roadmap;
13. known competitors;
14. relevant prior-art searches.

That lets the attorney ask better questions faster.

It also helps separate genuinely strategic technology from ordinary engineering.

---

Why PatentPC Is Built for Software, AI, and Advanced Technology Inventions

The best software patent work cannot be done by treating the invention as a black box.

The lawyer needs to understand:

What the system actually does.

Why it had to be designed that way.

What changed technically.

Which parts matter commercially.

How competitors might design around the claims.

PatentPC combines patent attorneys and technical specialists across software, networking, cloud systems, artificial intelligence, semiconductors, electronics, and other advanced technologies. See the PatentPC team.

The firm also builds technology itself, including patent analytics and AI-assisted IP workflows. Learn more about PatentPC.

For corporate patent teams, PatentPC also maintains a dedicated in-house counsel patent practice focused on converting R&D into defensible patent assets.

The objective is not merely to turn an invention disclosure into more pages.

It is to identify the valuable technical concept, understand the prior-art landscape, account for software and AI eligibility risks, and build claims around the technology that matters.

---

The PAT Checklist PatentPC Would Want a Technology Company to Use

Before releasing an important software or AI system, put these questions side by side.

Production question	IP question
Do critical workflows work?	Did any require a new technical mechanism?
Does performance hold under load?	What architecture produced the improvement?
Does failure recovery work?	Is the recovery mechanism technically unusual?
Can we roll back?	Did we create new state or migration technology?
Is data secure?	Did we develop a new security or privacy mechanism?
Can we diagnose incidents?	Did observability require new technical architecture?
Does the AI behave safely?	Did we invent retrieval, routing, training, memory, or control technology?
Did obvious fixes fail?	Why did they fail?
Are we ready to publish?	Should anything be filed first?
Is the release documented?	Did we preserve inventors, diagrams, metrics, and alternatives?

That is PAT done properly.

Not because patent lawyers should control engineering.

They should not.

But because PAT is one of the few moments when four things exist together:

A mature technical solution.

Hard evidence.

Engineers who still remember what happened.

A product that may not yet be public.

---

The One Rule to Remember

Do not wait until after launch to ask what you invented.

Ask during PAT.

That is when the problem is fresh.

That is when the failed approaches are still known.

That is when the before-and-after measurements still exist.

That is when the architecture is mature enough to explain.

And that may still be before the invention becomes public.

Production Acceptance Testing should answer:

Can we ship this?

For a serious software or AI company, it should trigger another question too:

Did we just build a technical advantage our competitors should not be free to copy?

If the answer might be yes, get the patent team involved before everybody moves to the next sprint.

Talk to PatentPC about a software or AI invention.

---

Recommended PatentPC Deep Dives

If PAT uncovered a potentially valuable technical improvement, these PatentPC resources are the logical next reads:

• How to Get Strong Software Patents
• What Can Be Patented in Software?
• The Role of Technical Improvements in Software Patentability
• The Role of Technical Effect in Patent Applications for Software
• Alice and Its Impact on Software Patenting
• Software Patents Post-Alice: Strategies for Tech Companies
• Overcoming Challenges in AI Patentability
• AI Patent Eligibility for Machine Learning Innovations
• The Role of Machine Learning in AI Patent Applications
• The Role of Explainability in AI Patents
• Conducting a Patent Search: Key Things to Look Out For
• What Is a Provisional Patent Application?
• How to Write a Provisional Patent Application
• How Much Is an International Software Patent?
• Software Patent Attorney: Protect Your Key Features

---

Research Sources

Production Testing, Reliability, and Security

• Google SRE — Production Readiness Reviews
• DORA — Software Delivery Performance Metrics
• DORA — History of Software Delivery Metrics
• NIST — Secure Software Development Framework
• NIST SP 800-218A — Secure Development for Generative AI
• OWASP — Application Security Verification Standard
• OWASP — Prompt Injection Guidance
• NIST — AI Risk Management Framework
• NIST — Generative AI Risk Management Profile
• NIST AI Resource Center
• ISTQB — Certified Tester Foundation Level

Patent Data

• WIPO — 2024 Generative AI Patent Landscape Report
• WIPO — Top Generative AI Patent Trends in 2025
• WIPO — GenAI SPARK Executive Summary
• WIPO — GenAI Global Patenting Trends
• WIPO — GenAI Key Takeaways and What Comes Next

U.S. Patent Law and Practice

• USPTO — Patent Public Search
• USPTO — Patent Subject Matter Eligibility Guidance
• USPTO MPEP §2106 — Patent Subject Matter Eligibility
• USPTO — AI Subject Matter Eligibility Guidance
• USPTO — Ex parte Desjardins Precedential Designation
• USPTO — Desjardins-Related MPEP Eligibility Update
• USPTO — Subject Matter Eligibility Declarations
• Federal Circuit — Recentive Analytics v. Fox Corp.
• USPTO — Revised Inventorship Guidance for AI-Assisted Inventions
• USPTO — Provisional Application for Patent
• USPTO — Eighteen-Month Publication of Patent Applications
• USPTO — Patent Cooperation Treaty
• USPTO — Pursuing International Patent Protection

Copyright and Trade Secrets

• WIPO — Copyright Protection of Computer Software
• WIPO — Trade Secrets FAQ
• U.S. Copyright Office — Artificial Intelligence Study
• U.S. Copyright Office — AI Copyrightability Report Announcement

---

Original Research Methodology

The calculations in this article use publicly available WIPO patent-family data.

WIPO reported 54,358 GenAI patent families published from 2014 through 2023. It later reported 18,862 in 2024 and 37,808 in 2025.

Source data:

WIPO Generative AI Patent Landscape Report

WIPO 2025 GenAI Patent Trends

WIPO SPARK GenAI Executive Summary

PatentPC then calculated:

Prior-decade annual average

54,358 ÷ 10 = 5,435.8

2024–2025 annual average

(18,862 + 37,808) ÷ 2 = 28,335

Publication-velocity multiplier

28,335 ÷ 5,435.8 = 5.21×

Share of 2014–2025 families published in 2024–2025

56,670 ÷ 111,028 = 51.04%

Six-month volume at recent pace

28,335 ÷ 2 = 14,167.5

Equivalent time at 2014–2023 average

14,167.5 ÷ 5,435.8 = 2.61 years

Quarterly volume at recent pace

28,335 ÷ 4 = 7,083.75

LLM publication growth

14,100 ÷ 881 ≈ 16×

2025 LLM-to-GAN publication ratio

14,100 ÷ 5,245 ≈ 2.69×

These figures measure published patent families.

They do not measure:

• granted patents;
• pending unpublished applications;
• enforceable claims;
• relevant prior art for any specific invention;
• the probability that a particular patent application will be granted.

They should therefore be read as indicators of patent-landscape velocity, not predictions of patentability.