Paravant Systems

Why Trademark Docketing Software?

A few years ago, I recognized that AI offered a once in a lifetime opportunity for an incredibly small team (or even one person) to punch above his or her weight and eat the lunch of software incumbents. I wanted to be part of that. I decided to niche down into highly narrow and specialized software because I didn’t want to worry about too many competitors, nor too many customers. Fewer customers (relatively) who pay well is infinitely preferred to trying to take on the whole world like a lot of these YC and a16z startups seem be trying.

Domain Expertise

How can a college student with no legal tech experience build highly specialized and narrow software for trademark attorneys? There are two ways. The first is by guessing at the needs of your customers and hoping that you are right. This is what I tried at first, and it got me maybe halfway there, which isn’t bad. The second is by going in on your company with a domain expert, aka a COFOUNDER. [There also is a third way, called going at it alone but while relentlessly gathering feedback from potential customers, but there are limits to this method]. I think it’s best to find someone who can put skin in the game so that they are just as committed as you to making the company work. If you can’t find someone like this, just stop. In my case, I reached out to and partnered with Markavo (r symbol), a top 1% trademark law firm. From this partnership I gained the critical access I needed to build actually useful software for our customers.

Technical Feats and Challenges

I’m including this section to prove that this application required thoughtful engineering and competence (not vibe coded).

Persistent Database Queue

I chose to build the job queue directly in PostgreSQL (as a Supabase table) to keep our business logic and job queue dispatch in one system and one transaction, allowing the queue itself to serve the scheduler role naturally. This way, the application can conduct business logic and enqueue the corresponding job in one atomic transaction. The alternative would be a transactional outbox to ensure that each transaction individually succeeds. Keeping job history alongside the application data also lets me trace failures through the affected automation, trademark case, client, and delivery record with SQL. Each job is already correlated with the original business logic, no need to cross reference between a Redis job queue and our application database.

Combatting Hallucinations to create an AI Agent Useful for Legal Work

To prevent the agent from hallucinating case law citations and getting the user disbarred, it’s best that the LLM’s output excludes the citations themselves. Instead, we provide the LLM with a structured representation of each case law excerpt from our living database of trademark case law. The agent writes the brief without direct access to the citations or even the exact excerpts cited. Instead, the agent receives the substantive meaning of each excerpt, which may contain more than one citation, and writes the brief without the chance to hallucinate case law. Next, we deterministically insert the citations into the model’s output. Problem solved!

In order for the user to trust our agent’s output, we also need to prove that there are no hallucinations. Since we already know where each citation was inserted, we display inline citations that link to the underlying legal source. Other citations in the generated brief (typically when the agent is addressing the examiner’s arguments), are flagged for special attention.

[More coming, still in progress...]

Real Impact

Paravant currently serves over 10000 records, hundreds of monthly automations, and an AI Agent used daily to search the TMID and TMEP, research case history, resize drawings, provide compliant TMEP § 808 descriptions, and generate office action briefs in real firms.