[michaelt]

Patents are in principle supposed to be non-obvious, and detailed enough that an expert in the domain can reproduce the invention from the description.

I can assure you that in practice they are neither.

There are merely a lot of people in the legal profession whose jobs depend on ignoring that fact.

[marcinzm]

> I can assure you that in practice they are neither.

Having written some patents that has not been my experience.

For example, this is one of the patents in the lawsuit:

https://patentimages.storage.googleapis.com/67/67/7c/1299b0c...

This patent includes network diagrams, actual C data structure, technical terminology galore, etc, etc. It's got a ton more implementation details versus, for example, a scientific publication on this topic.

Like, seriously, it's got 20+ page of this technical implementation details and not bland lawyer jargon:

>The second redirection mechanism, which is specified as a future extension of NDTP is having the server return an NDTP RDR RSP message in response to an NDTP request for which the NDTP server has no ownership of the supplied identifier string. Those skilled in the art will note that unlike the embedded redirection links mechanism, the NDTP RDR RSP mechanism applies to all NDTP requests, not just NDTP GET.

[pclmulqdq]

I didn't read this patent before making a sister comment, but looking through it, this one is actually really clear on exactly what is happening (which makes sense with everyone here saying "it's just DNS for data" - everything is obvious in hindsight) and relatively low on patent jargon.

A lot of patents give you a bunch of alternative implementations and component definitions, which can muddy the waters a bit. On the other hand, the figures can help you a lot.

[everforward]

Eh, this is like "first draft of a design document" level detailed.

The big issue is that it's a protocol, not a system. I.e. it's detailed only because it specifically _does not specify how to build anything_. Were they required to actually specify how to build something, i.e. a server that implements this protocol rather than the protocol itself, this would be woefully insufficient.

How are the mappings stored on disk? Does this entire protocol genuinely lack authentication? How is this meant to fail over when a server dies? If it's distributed, how do the nodes reach consensus?

You can't just jam stuff like this into a doc:

> Also, each update is preferably performed atomically > to avoid creating an inconsistent state in the string Store.

They're just handwaving away how the data gets stored. Y'know, the part of the patent that's actually useful and does something.

What's left over after you discount the parts they don't specify is basically just a wire protocol for a KV store that doesn't exist. They might as well try to patent a method for making imaginary mittens for imaginary friends, because that's basically what this is.

[pclmulqdq]

Patents are usually narrowly tailored to a specific part of a design document of a complex system, not the entire thing. The idea is that a "person of ordinary skill in the art" can implement the normal stuff (ie the current state of the art) around the new innovation, and the new thing gives that system a non-obvious benefit.

A lot of research papers are written the same way. They will go into great detail on a specific thing like a protocol or a storage format and then say something along the lines of "bolt this onto Redis" before presenting their data.

[everforward]

I’m fine with that in research papers. They have a very different goal where practical applications are not necessary yet (or ever in some cases).

> The idea is that a "person of ordinary skill in the art" can implement the normal stuff (ie the current state of the art) around the new innovation, and the new thing gives that system a non-obvious benefit.

Why specify a protocol at all then? Im sure a person of ordinary skill in the art can also come up with a protocol without an implementation. Takes like 15 minutes if you don’t have to worry about pesky details like having a working implementation.

There is no benefit, obvious or not, because there is no implementation. Whether it is safer or faster or whatever would be defined by an implementation. They’ve patented the digital equivalent of letterhead while positing that it will make mail more efficient.

[pclmulqdq]

Have you ever designed a protocol before? I'm not referring to something along the lines of "slap these fields in a JSON" for a service that gets 1 QPS, but an actual wire protocol intended for millions of QPS per endpoint. A good wire protocol is extremely difficult to design, far more difficult than an implementation of that protocol, and involves thinking ahead about all of the possible implementations and faults you will see.

That's why protocols like TCP are designed by huge collaborations of engineering teams across companies, while an individual who knows the protocol spec can implement TCP in a couple of days.

[michaelt]

> it's got 20+ page of this technical implementation details

Yeah fantastic, like an entire page devoted to showing requests that have numerical identifiers. Groundbreaking stuff.

And it's all completely irrelevant noise because you can infringe on the patent even if your implementation in no way depends on any of those details

The only thing that matters is the claims, and they're written so broadly and interpreted by the courts so creatively that a subject matter expert cannot read the document and determine if something does or does not infringe on it.

Seriously, how does Claim 1 not cover 99% of HTTP requests ever made given that people were using reverse proxies and passing requests between backend servers for decades before this patent was filed?

[marcinzm]

You claimed:

>...and detailed enough that an expert in the domain can reproduce the invention from the description. I can assure you that in practice they are neither.

I provided a counter-example. I'm going to take the the fact you're not responding to the counter-example but rather changing the argument as acceptable that you were wrong.

[cycomanic]

> You claimed:

> >...and detailed enough that an expert in the domain can reproduce the invention from the description. I can assure you that in practice they are neither.

> I provided a counter-example. I'm going to take the the fact you're not responding to the counter-example but rather changing the argument as acceptable that you were wrong.

You ignored the fact that the "innovation" is really embodied in the claims not the rest, because that is what will be covered in the end.

Apart from the fact that even this somewhat better written example makes claims much broader than what was actually done, giving one example does not invalidate the fact that many (and I argue most by a large margin) patents are much more vague.

[pclmulqdq]

In my experience reading patents, you have this backwards. The spec (pictures, detailed description, etc.) is where the disclosure of what you actually did and how you are advancing knowledge shows up. The claims are the enforcement mechanism attached to the stuff disclosed in the spec.

If you eventually sue someone, the claims are used, but they will often be challenged if they go beyond the scope of the spec.

[pclmulqdq]

In my past experience, this is only true because many people's eyes glaze over when they try to read patent-ese. If you can penetrate the obtuse form of English used, "in embodiments, ... may be ... to name a few" for example (and the weird ordering of paragraphs, etc.), it's actually not that hard to understand patents. There are a lot of people whose job it is to read patents, too.