My impression of everyone that I have ever heard from, or dealt with, involved with patents is that you all are so firmly in regulatory capture that your heads are captured up your collective asses, and the tech industry is being hampered by the resulting legal quagmires.

In a sane world, the entire description that you gave falls squarely under "generic computers doing generic computer things". And therefore by Alice v. CLS Bank as decided by the Supreme Court, it should not be patentable. Period.

Unfortunately the United States Court of Appeals for the Federal Circuit has gone rogue, and you're almost certainly correct that they will happily grant use of the patent to any patent troll lucky enough to get it. And the Patent Office is so firmly in the land of regulatory capture that bad patents like this have no trouble being issued.

And the result is that people whose work ACTUALLY achieves "Progress of Science and useful Arts" is hampered by this crazy system. And our patent system continues to undermine its stated Constitutional purpose.

I strongly believe that actual innovators are now left to 'innovate' within the boundaries set by the mega corporations with the help of their patent-pipeline and the patent trolls with the help of flawed legal systems.

See https://www.obwbip.com/newsletter/why-does-the-u-s-supreme-c... for some background on this.

That archetype stuff is so out of the norm that it took me a long time to grok how to work with it in Unity. It's most certainly not "generic computers doing generic computer things" and I've never seen it elsewhere, so I'd guess it would be quite defensible in court especially now that they have a patent.

Not sure what you're on about, but if it's a valid concern I'd pick a better example than this specific piece of tech (granted that one tiny snippet from the patent might not portray what the tech is or how it's unique).

Edit: seems like there is some confusion here about ECS and how archetypes are implemented in DOTS. ECS and archetypes are not synonymous, so I’m not sure what to tell you when you claim they are.

But I’m also not sure how downvoting me is helping here. I guess community consensus is that archetypes and ECS are the same thing, in which case Unity will have an uphill battle ahead.

Archetypes are a conceptually simple implementation optimization (group similarly-populated objects) not unique to ECSes - e.g. v8 organizes javascript objects based on their "shape" (again, grouping similarly-populated objects, based on their "properties" instead of their "components") (2017 article: https://v8.dev/blog/fast-properties .)

You can add all kinds of automagic parallelizing and filtering libraries (which I imagine have some overlap with database query optimization and scheduling in their fundamentals), but the basics are incredibly trivial - to the point where you might re-invent it by accident without knowing it has a name.

But I may just not be understanding what an archetype represents exactly. My only real experience with ECS, besides implementing a crude one around 2011 for fun, is EnTT, which specifically advertises itself as not being archetype-based as one of its key differentiators.

Its likely I just don't quite understand archetypes though.

What I could gather from it is that this is just an implementation of archetype-based ECS. Which just means that entities with the same set of components (that is, the same "archetype") are allocated together.

But I don't know whether they are patenting archetypes in general or just a narrow usage.

Now I have a question: is it possible that things published before the date of the patent (24 march 2020) are infringing on the patent? Or, on the contrary, things published before this date can actually be prior art?

Because, there are Rust ECS libraries that use archetypes, like for example legion https://crates.io/crates/legion/0.1.0 - that had its first release on 9 march 2019. And even at this date, the concept of using archetypes to optimize the memory layout of ECS applications is not novel. More about this here

https://csherratt.github.io/blog/posts/specs-and-legion/

I would say that the google v8's Javascript optimization, where they create a new struct layout for each possible combination of object fields, might as well count as prior art. It doesn't use ECS though: but I don't think that prior art needs to check all technology boxes. I argue that, in light of v8's trick to turn objects with dynamic fields (traditionally stored as a hash table) into objects with statically known fields, then ECS archetypes are not novel enough for a patent.

(And I don't even know if the v8 optimization is itself novel)

You have to look at the date of filing, not date of publication. The date of filing is June 12, 2018 (patents take a few years to issue these days). So March 9, 2019 cannot be prior art.

You don't need to have working code to take on a patent. If someone posted a medium article, or even some kind of proof of concept or cobbled together POC that'd be enough.

(I think really any kind of proof that you had the idea before that date is good enough -- a personal diary would work in principle, but you'd need to somehow prove that you wrote your thoughts down on the date and didn't forge it after the fact)

Patent agent here, not patent lawyer. (that means I passed the patent bar exam and could write your patent, but could not sue anyone over it.)

Wrong, wrong, wrong. Prior art has to be "published" (and there is a whole body of case law about what that means). Maybe you are thinking of the old "first to invent" rule?

The real problem is that the patent examiners are not in general required to look at the whole breadth of what is published, just what is in the patent databases.

As a result there can be clear prior art, but unless it gets fed in during the review process, the practical way to resolve that is likely to end up in court, and likely to be expensive.

Of course often "clear prior art" isn't too. Hence the process to sort it out.

I was told that a proposal to require the examiners to use Google was rejected by the union: if you're going to require us to do more work, then you have to pay us more.

This was back in 2012 or so. I have no idea if now they have to use Google, but they only get about a day and a half on each patent (again, this is old data).

Sure, but usually superficially (and not, I think, required); which is fair - you can't practically require the patent examiners to have the kind of breadth and depth necessary to have a good feel for this.

Getting a librarian to say "yes, we cataloged it and made it available on May 5" would be pretty strong. Or a Wayback Machine archive from May 2.

Still I think I've been deposed (I got grilled by an actual hostile patent lawyer) before over an old Usenet post I made in the late-90s (that was really more of a "showerthought" in the middle of an flamewar) that was being used to attack a patent.

I remember reading about them in my CS studies, and that was pre 2011.

I'd never seen or heard of archetype based ECS before I first saw Legion and I was very impressed with it. I don't know where they got the idea but it's very worrying if Unity legit came up with this first. I'm not super up to date on what's happening inside AAA studios, but what I've seen in production is that game studios usually manually group components to optimise performance. The automatic grouping in archetypes is definitely not mentioned in any tutorial or game engine architecture I've ever seen before Legion.

Edit: creator of bevy has a great initial reaction to this on Reddit: https://www.reddit.com/r/rust/comments/pjtpkj/comment/hbzaz6...

How about 2013:

https://www.gamedev.net/tutorials/programming/general-and-ga...

I use a heavily updated version of this for my own projects

http://t-machine.org/index.php/2007/09/03/entity-systems-are...

IIRC this one was the one to really popularise the idea of not storing any component data in the entities. If you loosen that requirement, there were earlier ones still (eg the one from the Dungeon Siege team).

But as others have mentioned, ECS is really a special case of a relational model, so its entirely possible that Unitity's techniques have been done there already.

Also, I found it pretty difficult to understand the claims, they didn't exactly make it easy to read, so I can't quite figure out exactly what is patented. It also doesn't help that they don't clearly define their terms, eg what exactly do they mean by archetype? Maybe they describe it in the description before the claims, but I didn't find it at a cursory glance and it was too painful to try read it all. I wonder what their definition exactly entails, versus what I imagine they mean from what I know of archetype-based ECS's. For example, if they mean "a conceptual grouping of entities that have the same components" then non-archetype ECS could fit that, but if they mean their specific implementation then I don't know. EnTT, a popular non-archetype-based ECS, has had "views", which are ways to efficiently access components, since its first public commit in 2017: https://github.com/skypjack/entt/commit/b0b8ee7aea3d9f5cfe6f...).

Whether any of that is relevant to the patents validity, I have no idea. Probably not.

So they've patented a database server, basically.

The idea that there's anything patent-worthy in automatically storing like combinations of data with like combinations of data for efficiency is... patently absurd.

But that's where the patent system is, now, I suppose. It's now mostly just a tool to help incumbents raise the barrier to entry so they can fend new entrants off with lawyers rather than merit.

You didn't patent that did you?

I'm most familiar with relational databases and the way in which their data is stored is generally dictated by the schema.

At a minimum, to be consistent with this patent we'd be talking about a database that accepts arbitrary groupings of predefined sets of fields, which then on-the-fly determines how best to pack these individual sets together with other sets belonging to other groupings. The fact that we are talking about two types of collections (one nested in the other) is key -- that is, the nesting of fields within the sets ("components" in ECS terminology), and the nesting of these sets within the groupings ("entities" in ECS terminology).

One of the major features of relational databases (and the improvement over their predecessors) was precisely the disconnect between logical and physical model. If the logical schema dictates how something is stored physically, then it's not a terribly good system. At the very least the intention with relational databases was to provide for this extra flexibility that previous models didn't have. Sure you don't have to exercise that flexibility but it's always been there.

> we'd be talking about a database that accepts arbitrary groupings of predefined sets of fields, which then on-the-fly determines how best to pack these individual sets together with other sets belonging to other groupings

So basically columnar storage with table inheritance would be enough to do the trick. I know there's databases for either of those features, and it's absolutely not a huge leap to put the two together. Fact is I wanted to implement something like this for CLOS but didn't have the time yet, sadly.

I’ve seen engines that do that and updated my own code to do so. Unfortunately git says that was added after they filed.

Their employees could have easily pulled this from community discourse.

What’s probably needed is community backlash; no more unity games. It worked with Apple.

"In this 2017 GDC session, Blizzard's Timothy Ford explains how Overwatch uses the Entity Component System (ECS) architecture to create a rich variety of layered gameplay."

(My favorite resource to explain ECS + NetCode)

Legalese is a discovered language. Various phrases are reused because their meaning has been found in previous court cases. Using novel language to express an idea with an existing, court-tested alternative is begging for trouble.

Lawyers are not very expensive compared to the consequences of trying to read it yourself. This would still be true even with a less-legal-ly legalease.

From the top of my head, here’s a great tech talk about overwatch. https://youtu.be/W3aieHjyNvw

Here’s a tech talk by Bob Nystrom (the game programming patterns guy) that mentions ecs from years ago https://youtu.be/JxI3Eu5DPwE

Edit: letsInvalid in another thread above linked to an article from 2013: https://www.gamedev.net/tutorials/programming/general-and-ga...

EDIT: yes, yes they did. What you see above is in fact clam 1, in it's entirety.

This is worse than usual. Usually "X patents (common thing)" headlines actually mean "X patents (common thing with weird twist)," which is a great deal less severe. This really looks like Unity got an actual patent on the actual ECS design pattern, the one that every game has used for the past 40 years.

They will be able to extort an awful lot of money with this patent before it gets overturned.

I guess this will be a major roadblock to Unreal Engine offering such an automated ECS system, which is a real shame. There are certain types of games which do need ECS to make viable use of computing resources (simulations, etc). You don't see many of those on Unreal now and I guess you won't for the foreseeable future if this patent holds.

(not a lawyer, co-inventor on three patents so I've been through this, unfortunately as I didn't want to participate in that system, consult a lawyer before doing anything rash).

The claim matters, not their detailed description. The most harmful patents work that way: describe in detail a specific implementation, but write the claims to cover every alternative implementation you can think of.

https://jobs.funcom.com/jobs/975839-gameplay-programmer

Edit: the video https://youtu.be/QlKXPBFh5BM

From looking at the claims, it seems they are patenting archetype-based based ECS. In other words, not just vanilla "array of components" but "array of sets of components".

Patents do nothing to advance science or technology, and everything to prevent new invention.

Because "group entities together in memory by which components they have" isn't patent worthy.

(not that I'm advocating for the patentability of software in general, I just think that if software should be patentable, this sure seems like something that could be)

That's not really what is getting folks riled up with respect to patentability. The techniques mentioned (as interpreted by some) are considered not at all novel, being widely known in the prior art.

That's my take. I haven't dug too deep.

Update after briefly reading the patent. I like to read claims backwards, because they almost always build upon each other, with Claim 1 basically claiming the broad domain, and each subsequent claim narrowing the scope. Claims are "subtractive" - each has to match, unless you specifically call out sub-claims (e.g. "8. claim 7, but also ABC; 9. claim 7, but also DEF").

Here's a plaintext link for those following along: https://patents.justia.com/patent/10599560

Claims 17 and 20 are the real kickers.

> The method of claim 10, the operations further comprising:

> determining that an entity of the set of entities within a first archetype has been modified;

> based on a determination that the modified entity corresponds to an additional new archetype, adding the additional new archetype to the set of archetypes, building an additional new memory chunk for the additional new archetype, populating the additional new memory chunk with data from the set of components included in the modified entity, and deleting data corresponding to the modified entity from the first archetype;

> based on a determination that the modified entity corresponds to an existing second archetype in an existing memory chunk, populating the existing memory chunk with data from the set of components included in the modified entity, and deleting data corresponding to the modified entity from the first archetype.

Woof. That's really dense, but it sounds like it's basically describing inheritance based on composition. To update an archetype and all entities of that archetype, create a new archetype in memory, move some pointers, and you're done. No reallocation beyond that updated archetype node.

> 20.20. The non-transitory machine-readable medium of claim 19, wherein each component data array of the set of component data arrays is contiguous with a next component data array of the set of component data arrays.

So this isn't just about ECS, this isn't about archetype ECS, or even OOP-based archetype ECS. This is specifically about an OOP-based archetype ECS using some fancy memory layout method, which lays out contiguous chunks in such a way that modifying archetypes doesn't result in large reallocations. I think. It's super dense.

Even with all that added specificity, I still think it falls short of clearing the bar of novelty beyond prior art. This is such a performance-relevant part of game engines that leverage ECS, that somebody out there has to have already thought of ways to improve the memory management of entities.

We don't care about the "prior art" filter, because the patentability filter already failed.

You seem to be implying, by referencing what I can only assume is the Alice Corp case, is that the patent is too abstract. I don't think that's the case. The patent describes a very specific technique for memory management and archetype based inheritance.

I think the technique would be patentable were it an inventive step above the prior art, but it's not novel enough, IMHO, IANAL, BBQ.

https://en.wikipedia.org/wiki/Alice_Corp._v._CLS_Bank_Intern...

I think it's more specific than a combination of ECS and memory allocation strategy. Since ECS allows dynamic building of "types" or "classes" of objects, this seems to be automatically detecting new types and allocating memory for them separately. Maybe? So go ahead and ECS all you want, and go ahead and use spiffy memory management all you want, but don't tie type inference into your memory allocator. IANAL but that seems to be the ostensibly unique part.