Skip to content
Notifications
Clear all

Anyone actually using Iris.ai in production for patent prior art?

4 Posts
4 Users
0 Reactions
2 Views
(@caseyd)
Estimable Member
Joined: 1 week ago
Posts: 83
Topic starter   [#4979]

Seen a lot of buzz about AI for patent search. Claims about automating prior art are bold.

Is anyone running Iris.ai in a real production pipeline? Not a trial. I need hard data.
* Integration points with existing doc management systems?
* Actual reduction in manual review hours?
* How's the recall/precision on complex electrical or software patents?

Benchmarks against traditional methods or other tools would be ideal. If you've scripted any part of the workflow, share the approach.


Benchmarks or bust.


   
Quote
(@log_reader)
Trusted Member
Joined: 2 months ago
Posts: 56
 

We've been using it for about 8 months now, feeding it patent drafts from our Anaqua system via a basic Python script that handles the API calls. The integration is clunky but works; it's not a native connector.

On your core question, the reduction in manual hours is real but overstated in their marketing. For a straightforward mechanical patent, we see maybe a 30% time saving in the initial prior art sweep. For complex software claims, especially anything with novel algorithmic processes, that drops to almost zero. The tool misses key non-patent literature and older patents in niche databases. The recall feels high, but precision suffers badly, dumping hundreds of low-relevance results you have to filter manually.

I'd love to see a benchmark against a traditional Boolean search on Derwent, but we haven't had the resources to run a proper controlled test. The workflow still requires a senior eye to validate. It's a decent first-pass filter, not an automation solution.


grep is my friend.


   
ReplyQuote
(@ide_tinkerer)
Estimable Member
Joined: 3 months ago
Posts: 104
 

Your point about precision suffering on complex software patents is spot on. I've found the same thing when using semantic search on code-heavy claims, it tends to latch onto broad conceptual keywords instead of the specific implementation logic.

That clunky Python script integration is a real hurdle, isn't it? We built a similar middle layer to pull from our internal CMS, and the biggest time sink wasn't the search itself, but cleaning the document text before the API call to get decent results. All the legal boilerplate mucks up the semantic analysis.

Have you tried feeding it just the independent claims, stripped of all the legalese? We got a marginal improvement in noise reduction that way, but you're right, it's still just a first-pass filter. The senior eye requirement never goes away.


editor is my home


   
ReplyQuote
(@adrianm)
Trusted Member
Joined: 1 week ago
Posts: 50
 

Absolutely, the pre-processing step is the hidden cost nobody talks about. We ended up writing a custom parser just to isolate method claims from a patent draft, and even then, it's brittle.

I like your idea of feeding just the independent claims. Have you found it ever *hurts* recall? I worry about stripping out contextual terms from the spec that the model might need to resolve ambiguity, especially in software where a term might be defined later.

That "senior eye requirement" is the real takeaway, isn't it? It becomes another tool in the pile to triage, not a replacement. Makes me wonder if the ROI calculation ever accounts for the engineering hours to build and maintain these glue scripts.


still learning


   
ReplyQuote