This is the story of how a mundane complaint — "the VPN is slow" — turned into a US patent application. Not a granted patent. An application. I want to be precise about that from the start, because the distance between the two is the whole point of this post.
It started with a slow VPN
The company I work for had an internal VPN that everyone routed through. It lived in the Tokyo office, it was old, and it was not something I built. Then the complaints started arriving — from a lot of people, all saying the same thing: it's slow.
I work from Thailand most of the time. That detail matters. If that aging box in Tokyo had fallen over, I would have been the person furthest from the power button, in the worst position to fix it. A slow VPN is annoying. An unreachable VPN, when you're a few thousand kilometers away, is a real problem.
So I started moving it to the cloud. I stood up a WireGuard VPN — modern, fast, and something I could actually reason about and operate remotely instead of inheriting a black box.
Down the WireGuard rabbit hole
Around that time I was deep into building my own iPhone apps. So the cloud migration turned into a personal project on the side: I built my own server and wired WireGuard into an iPhone app of my own. And to do that properly, I started studying how WireGuard actually works under the hood — the Noise protocol, the handshake, the key exchange.
That study is where everything else came from. I wasn't trying to invent anything. I was just trying to understand the thing I was now responsible for.
The SYN flood that primed my brain
Not long before, the same company had been hit with a SYN flood attack. If you've dealt with one, you know it lodges the mechanics of connection handshakes firmly in your head — the back-and-forth, the round trips, the cost of every "hello" before any real data moves.
So I had handshakes on the brain. And then, reading through how WireGuard establishes a session, a thought stopped me:
Wait — does it really handshake every single time?
The club-stamp idea
Here's the analogy that made it click for me.
Think about getting into a club. The first time, there's a whole process: they check your ID, you pay the cover. But once they stamp your hand, you can walk back in again and again — no re-checking every time — until the stamp wears off.
HTTPS already does something like this. The first connection does the expensive handshake; later ones can resume more cheaply. So I wondered: why can't a VPN handshake work the same way? Do the full handshake on the first connection, and from the second connection onward, present a kind of token — a stamp — and walk straight in. With an expiry, of course.
That's the essence of it: a zero round-trip (0-RTT) handshake. The first session sets things up and hands the client a one-time "re-entry" credential. The next session uses that credential to establish a provisional session key on the very first message, instead of paying for another full round trip. After it's used, the server destroys it, so the stamp can't be replayed.
I'm keeping the cryptography deliberately light here — this is a story about a journey, not a spec. But that "club stamp for VPNs" was the idea.
"Wait... can I patent this?"
The first thing I did was check whether someone had already done it. I went looking for prior art: QUIC's crypto, TLS 1.3's 0-RTT, NoiseSocket, and a pile of academic work. I searched patent databases for 0-RTT key exchange on WireGuard and Noise.
I found nothing. Zero prior patents for a cached-ephemeral-key 0-RTT handshake on WireGuard.
That's the moment the question shifted from "is this a neat idea?" to "wait — could I actually patent this?"
Filing it myself, solo
I expected the answer to be: hire a patent attorney, spend a small fortune, wait. The quotes I gathered for the full attorney route ran into the thousands of dollars, easily five figures by the time you add drafting and prosecution.
I went a different way. I filed it myself, without hiring a patent attorney. A few things made that possible:
- The design was already done. I had written up the full cryptographic flow while studying WireGuard, so the hard intellectual work — the part you'd normally pay an attorney to extract from you — already existed in my own documents.
- Multi-LLM review. I used several different LLMs (Claude, ChatGPT, Gemini, and others) to review and stress-test the specification and claims from different angles, instead of a single human reviewer.
- Micro-entity status. As a solo inventor under the income threshold, USPTO fees drop to a few hundred dollars rather than thousands.
- Direct non-provisional. I initially planned to file a cheap provisional first, then convert it within 12 months. In the end I filed the non-provisional directly, since the spec and drawings were ready.
The identity verification was its own small adventure. I went through ID.me and ended up on an online meeting with a US-side representative to confirm I was who I said I was. It cost real money along the way, and the realistic timeline I was warned about is long — examination and a potential grant are measured in years, on the order of two and up.
In March 2026 I filed it with the USPTO — "Zero Round-Trip WireGuard Handshake Method and System Using Cached Ephemeral Keys." Sole inventor. Filed by me.
What I actually learned
The thing I want to leave you with isn't the cryptography. It's this: filing a patent is something one person can do. I assumed it required a firm, a budget, and permission. It required a real idea, documentation I'd already written for my own understanding, and a willingness to read the rules carefully.
And the second thing: filing is the start, not the finish. An application is not a granted patent. Mine is sitting in the queue at the USPTO, and it'll be years before I know whether it becomes a real, granted patent — or gets rejected. I haven't "gotten a patent." I've filed one. That distinction is easy to blur and worth keeping honest.
It all started because a VPN was slow and I happened to be the wrong distance away to ignore it.
