Some relevant claim language is below. Of course a lot of this stuff has been known for a while, but you have to have everything together--or an evidenced argument that combining things in this way would have been obvious--before you can conclude anything about the validity of the patent. And on unpatentable subject matter (i.e., being an abstract idea), there is a pretty good argument that this improves the functionality of the computer, not just uses a computer to do something known, which recent cases have started using as the de facto dividing line.
1. A system comprising:
one or more computer processors;
one or more computer memories;
a set of instructions incorporated into the one or more computer memories, the set of instructions configuring the one or more computer processors to perform operations for automatically managing a set of memory chunks within the one or more computer memories at runtime for a computer application, the operations comprising:
receiving a set of entities from the computer application, each of the set of entities including a set of components, wherein each component of the set of components has one type of a set of types;
classifying the set of entities into a set of archetypes, each archetype representing a different count of the set of components or a different combination of types of the set of components relative to other archetypes of the set of archetypes;
based on a determination that one of the set of archetypes corresponds to a new archetype, building a new memory chunk, adding the new memory chunk to the set of memory chunks, and populating the new memory chunk, wherein the populating of the new memory chunk includes adding data from the set of components included in one or more entities of the set of entities that are classified under the new archetype, the adding of the data including contiguously adding the data to ends of a set of component data arrays included in the new memory chunk, each of the set of data arrays included in the new memory chunk corresponding to a respective component of the set of components included in the one or more entities that are classified under the new archetype.
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.
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
(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.
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.
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.
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:
I use a heavily updated version of this for my own projects
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.
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.
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.
Most big tech companies have a constant stream of patent applications, many of which are granted. But they rarely sue over 99% of them. Sure, Amazon had one-click for however many years and they cared about it. But the other tens of thousands of patents Amazon owns (a couple of which have my name on them as 'inventor') are never going to see a court room.
Why do they patent everything? So that patent trolls can't patent it first and then sue them for patent violations. It's a defensive patent.
Is ECS going to be Unity's "This is ours, no one else can use it without paying us" lawsuit-generating patent? I doubt it. They know they'd lose in court eventually, and along the way the entire industry would stop doing business with them. It would be a complete lose-lose move.
On the other hand, now that Unity owns this patent, no patent troll can go and patent ECS then start suing small-studio Unity customers, like parasites leaching off the success of Unity.
It’s a real killer for indies who are trying to collaborate who have not formed a company yet. This seems to apply to items you purchased before they changed the terms. They even promised they freelancers could use your assets in support forums days before the change
I stopped using unity after that. They don’t act in good faith towards their users
I think most Unity developers find the switch incredibly easy because most of the principles and many of the idioms are the same (and Godot is also more intuitive and has better documentation imo).
Godot 4 looks like it should remove most of the last few pain points too.
I'd say Godot is the superior prototyping/game jam tool, the superior 2d game engine, superior for building UI, and you don't have to deal with any licensing bullshit. It's also like 300 mb as a base install compared to Unity's 7 gb clusterfuck of spandrels.
I'd say the only situation where I'd recommend Unity over Godot is if you already have a ton of Unity experience and want to build something quickly without learning new stuff, or if there is something critical in the asset store you can't find in Godot's (definitely less content and tutorials because of the smaller userbase)
But the flip side is that this gives corporations a great tool to handicap competition.
If a competitor emerges, they can threaten legal action. And with a huge patent portfolio the big players can usually find a way to attack pretty much anyone.
Many companies will easily get scared and cave, and so either lose competitive advantage by dropping the technology, or feel forced into agreeing to an aqui-hire by the corporation . Which further cements the corporations dominating position.
This happens often enough, but rarely goes public.
Something with ECS development is clearly going haywire, and the silence from the Unity people is troubling.
Not just the nomenclature: ECS, DOTS, Burst Compiler, SRP/HDRP/LWRP/URP.... It's an endless list of confusing terms... But moreover those concepts are not so easy to grasp and to use in code by just looking at a few examples.
After doing lots of small 'experiments' in Unity (the old way without ECS) I started to realize, that more and more I was fighting the engine, trying to use or build upon features which were half-baked, buggy or simply not developer friendly. And instead of first fixing those things Unity decided to go all in on ECS.
There came Godot, a breath of fresh air without all the cruft and without all those confusing terms. I think Unity will have a hard time in the future: On one hand there's Unreal which caters the AAA market and there are smaller engines like Godot for the indie crowd. Unity is the odd one in between.
Don't know how decent it is. It is definitely full of features and has what seems to be a good editor.
ECS is really good for things that scale. Architecturally, it has both pros and cons to OOP. After working with ECS for a few years, I came to the conclusion that OOP is still the best for behavioral richness.
The current state of DOTS is just sad as it's affecting a lot of developments such as Tiny, unity.physics, dots audio, dots animation, etc...
Burst and Jobs are probably the best things that came out of Unity's initial push for DOTS.
Just my 2c.
I do concur with the above poster, though -- their ECS/DOTS has been basically ignored. At this point there's so, so, so much of the Unity ecosystem that just flat out fails to work beyond some very, very, very small scale that it's just mind-blowing. Want to use their physics, or nav-mesh agents, or even their sprite-rendering systems? Once you get 500-1k of any of those objects into a scene (ie, sprites!!), you've already blown way past your CPU/framerate budget. It's mind-boggling; especially when you can, for example with sprite rendering, run your own mesh with a bunch of quads and absolutely obliterate the performance you get from SpriteRenderers.
Very frustrating & somewhat mind boggling TBH. I'd personally guess the vast majority of indie devs that use Unity are simply using it as a [mesh] rendering pipeline & practicing a "roll our own" approach for almost everything else.
I completely agree. I've done compile-time code transformation/generation in C# using Reflection in the past, and while it's not really trivial, it's entirely feasible. I knew some people who did this independently because of things like INotifyPropertyChanged in WPF. They're already doing things that are way more advanced than that with the usage of the [BurstCompile] attribute.
If anything, they could just restrict the usage of fields that don't work with it.
> At this point there's so, so, so much of the Unity ecosystem that just flat out fails to work beyond some very, very, very small scale that it's just mind-blowing.
Someone in here said that everything in Unity is either unmaintained or unfinished. I share this sentiment. :(
If it is not claimed in the claims it is not subject to the patent. Any analysis of this patent (or any other patent) that doesn't focus on the claims is not a real analysis. Part of why companies spend so much money on patent lawyers is because good ones know how to write the claims in as broad a way as possible that won't get thrown out by a court. This way the patent applies to a maximal set of implementations. The claims are typically hard to read, the ones in this patent are no exception.
There are essentially 3 main claims this patent is making (numbers 1, 10, and 19). These are all separate claims. So if any one holds up in court then the defendant is violating the patent. I briefly read them, but it takes a lot of effort to understand them and my knowledge of ECS is shaky. However, none of them seem to be claiming anything all that novel, so I would be surprised if they held up in court.
But to use an expression I've heard somewhere, patents aren't read, they're counted. Lone inventors almost never successfully defend a patent. They were intended to spur innovation but in modern practice patents are used as legal weapons by large corporations. That's why most major companies incentivize having employees produce patents. The companies don't really care what's in the patents, they just want a lot of them so they can successfully threaten other corporations with lawsuits. This allows everyone to infringe on each others patents, since it would be too expensive to actually have a trial. So big corporations are largely protected from patent lawsuits since their competitors are probably infringing on at least some of their patents and vice-versa. The real losers under this system are small companies and individual inventors.
The commenters who mentioned "regulatory capture" and patent trolls are 100% right. But it's much worse than you think: the professional societies (ACM, IEEE) and tech industry management are solidly not in your corner, either. They've invested too much money in the current system.
Let's imagine that GitHub or StackOverflow or some other large developer forum ran a poll: "Are you in favor of abolishing software patents?" What do you think the results would be?
Why don't they ask the question? Unfortunately, they don't want to hear the answer. It might move Congress to actually do something, which they always prefer not to do.
However, the law is full of the phrase "practitioners in the art." A poll showing that a vast majority of practitioners of the art feel one way would have some effect. Whether it would be enough, or how long that would take, is an open question.
Claim language is obtuse because it's for lawyers, not laymen. An engineer can write the description, but only the lawyer can write the claims.
It's immensely complicated, but if Unity does someday assert this patent against someone else, then you all are helping the defendant when they have to defend themselves. At least, I hope the defendants find this discussion.
The defendant's standard tactic is usually to file for IPR, or PTAB reexamination of the patent, which is like a trial without a courtroom. The cost figure I recall is $500,000; maybe it's different now.
If the IPR succeeds, then Unity is SOL. There was a Supreme Court case recently where some plaintiffs tried to get the whole IPR system thrown out. They failed, as far as I know.
Lastly, the whole back-and-forth with the PTO is in the public record, if you know how to find it (and if you think reading claims is difficult, wait 'til you try reading a prosecution history!)
If anyone needs a one-sentence rationale why the entire concept of a software patent should be invalid, here it is.
> Lawyers are not very expensive compared to the consequences of trying to read it yourself (https://news.ycombinator.com/item?id=28451317)
That's the standard tactical defence fee? I would guess that kind of money is very far above the means of most open-source developer defendants.
And wouldn't a larger, closed-source business rationally choose to pay Unity (say) $400,000 extortion fee instead of taking it to court with the associated uncertainty?
As for defense strategy: you're right, but Unity might want a quick hit. They don't want a lengthy proceeding where they might lose.
What I'm getting at is: $500k is more than most people's entire assets, and more than the assets in many small businesses and organisations. With software patents like this one, most infringements are likely done by the "little guy", who can end up threatened when they publish code, or have to operate in fear of that happening, if they know about it. They simply cannot challenge the patent through any legal method that has a fee like $500k.
If the rational closed-source company will pay Unity's hypothetical fee because it's less than the IPR fee, and the open-source defendant doesn't have any choice because they can't afford any of the options... who is left that is both motivated and capable to use the IPR procedure?
In the case of this particular patent by Unity, the techniques are things people thought of decades ago, but like most "inventions" of this kind, it's only when you have a specific project (typically paid) where they'd come in useful that you typically get around to using it. Nobody has time to document and explain every little "invention of the day" every time they think of a new technique just to feed the prior art corpus. I tried that once. When you've come to see how low the threshold is for patentability in software (and to be honest, in some digital hardware too), it's seems literally impossible to write down every patentable insight as fast as they come once you're on a roll; you'd need a support team just to do the documenting.
It's upsetting to think up a technique, flesh it out, not have a use for it for 10 years (you're busy, right?), then find one day when you want to use the fruits of your own figuring out 10 years prior on a project, it cannot be used any more. Even more so when it follows naturally from techniques dev communities have been discussing for years in the field.
(A number of us also have stories of publishing a sketch of a technique on some forum, only to find it patented later. It happened to me with a texture-mapping graphics technique in the 90s, where I found a later patent actually cited my Usenet post; in practice that meant I couldn't develop it further because the obvious next steps were blocked.)
Developers have been writing screeds like this for almost 40 years, but nothing changes. That's because the people in power don't want them to change. Do you want to just keep complaining, or do you want to do something?
I wasn't assuming that, but I was assuming from the way you wrote it, that you think $500k is an ok price for people to continue practicing the software engineering they were already doing. It might just be a language interpretation thing from the way you wrote about that. And because of this:
>> That's not court; that's an IPR .
I consider almost all the interesting defendents to be people who will not be able to afford the IPR procedure, and the above seems a mere technicality from that perspective. For those people, it might as well be a court case in spirit. I.e. something they can't afford, that involves a panel judging something and corporate lawyers making arguments that determine someone's future.
So it seems only relevant to people who might be serious about doing the IPR. That's what gave me the impression you consider it feasible for typical defendants. But then:
>> As for defense strategy: you're right, but Unity might want a quick hit. They don't want a lengthy proceeding where they might lose.
You wrote "but", yet seem to agree with what I wrote on each point here, which amounts to nobody having the combination of motivation and capability to use the IPR procedure.
> Do you want to just keep complaining,
If you're assuming I'm complaining, you haven't been paying attention. I'm saying that when it appears to be suggested (possibly by way it's written) that it's an ordinary and reasonable $500k fee for a defendant to overturn a patent via IPR, that suggests to me (and probably others) that the author thinks of defendants as the kinds of companies or individuals with that level of funding capability.
I probably didn't state my case well, but the gist is two things: 1. I think the the vast majority of interesting defendents (infringers and potential infringers) don't have that kind of funding capability. 2. A genuine question (which hasn't been answered): Who would pay for the IPR, when neither the small-time defendant or the company who can pay the patent holder's fee has both motivation and capability to do the IPR?
> or do you want to do something?
You appear to be suggesting an alternative course of action than writing on HN, something to do with people in power, but I can't guess what "something" you have mind. Do you have something concrete in mind, or is that just a generic complaint on HN that there's too much complaining? :-)
As for what "something" is: I happen to be retired while you probably will be living with the patent system for a few years yet. So don't just say "someone should do something." Whatever that "something" is, you'll be more motivated if you think of it.
> The defendant's standard tactic is usually to file for IPR, or PTAB reexamination of the patent, which is like a trial without a courtroom.
For it to be the standard tactic, that implies a worldview in which defendants have that tactic as an option, and that's where the impression you think most defendants have access to that level of assets comes from.
But once you've explained the fees, it becomes clear that the typical defendant's standard tactic isn't to "file for IPR, or PTAB reexamination".
I'm not sure what the standard tactic is, but it isn't the one they can't afford.
When I've spoken with other patent lawyers, they've been skeptical that working engineers/devs regularly "reinvent" things covered in patents by accident. They have said they don't believe such people exist. Yet in my line of work, it's a near daily occurrence; it wouldn't even be possible to write them all down some days, and often it's things that were figured out years or decades prior. I know this with confidence because occasionally I look up techniques I've developed before that I want to use in some project that warrants it, and then I'm dismayed to find them recently patented, sometimes more recently than when I first developed the techniques.
So hopefully you can understand why I might have the impression patent lawyers (some at least) imagine that most "defendants" (people pursued for infringement or under threat of such) are the type of people they have as paying clients, and that other defendants (who I think are the majority) don't exist.
> So don't just say "someone should do something".
But I haven't said that. You came close, though, thus asking what you had in mind.
My argument here is not that someone should do something. It's that most defendants won't pursue IPR/PTAB reexamination because it's not an option for them, and companies with sufficient assets to pursue the reexamination are better off paying licence fees, so who is it that's both motivated and capable to pursue the IPR/PTAB reexamination? If there isn't anyone, it's not going to be overturned, is it, and most infringers (accidental or not) are just stuck with it even it would be overturned on reexamination, aren't they?
The answer to that is a missing piece in your explanation of the system, which without it seems to say that it's "standard" to end up reexamining these sorts of patents and overturning them if appropriate. I would be very surprised if that really is what happens, but also genuinely interested if that's the typical outcome.
This is Hacker News, not Patent Law 101. I'm not obligated to explain every aspect of the system in a comment.
I gather you think there's something new or unique in your comments about poor defendants. There is not. People have been saying it since the 90s. You are preaching to the already-converted.
Finally, if you read my paper on SSRN (which I've cited here many times), you'd see that "programmers' standard toolbox of techniques" is what I called out as something missing from the law.
That paper got cited in the Checkpoint amicus brief to SCOTUS in the CLS Bank case. That's an example of doing "something" but I will admit it's not much.
If you really wanted to do more, you'd start or join a political movement to "abolish software patents." There already are such organizations.
Like Figure 4B. It's a diagram that basically says, if something happens and we need a new entity we create one... Figure 4A is literally talking about adding to an array. Figure 1 is just a diagram of a computer?
The abstract is just garbage collection...
That said, I've reread claim 1 a couple of times and I have no clue what it is actually claiming.
Here, an "entity" is just an object identifier (integer, or whatever). A "component" is a specific set of data relevant to some function (e.g. position component would have x, y, z floats, while damage level component might be a single float to represent amount of damage).
ECS generally means laying out all memory for all instances of a given component contiguously, so in the example I gave you'd have one array for all position components in your game world, and one array for all damage level components. The "entities" are just collections of these components from these different arrays. So the "player" entity for example is logically composed of one particular element of the position array and one particular element of the damage array. This is more cache friendly when you have a "system" (say, the physics subsystem) which generally only operates on one or a limited set of types of components across many entities.
There is no way ECS in general is patentable but their system which intelligently and automatically performs the memory layouting for their form of ECS (which also includes the notion of chunking these arrays into finite sized blocks) very well might be.
Per my knowledge Unity ECS does not currently process data on the GPU, but uses ECS to split work to multiple threads on the CPU. If the threads work on data that only they need to touch, then there is no need to synchronise them. It is also more cache efficient to read and write data from a couple of arrays sequentially, than to pull objects and their attributes from all over the heap.
The idea of storing objects by attributes, instead of object instances is not new. Some clever allocator indeed might be new.
I suspect they want to make it harder for Unreal to make the same system. Unreal might have nice visuals, but scaling was not their strength before.
INAL but this is incorrect. The rest of the document is mostly the disclosure and - critically - claims cannot rely on anything not disclosed.
Importantly during the review process you can edit or amend your claims, but you can't update the disclosure without changing precedent date.
Correct. Only the contents of the Claims system matters to what is actually patented. Also, claims are subtractive/intersection, like all bullets have an AND function applied. So if you have a widget and it matches claim 1-8 but does not match claim 9, it does not match. That is, unless you specifically call out your "unions" - this usually looks like "the method of claim 8, but abc", "the method of claim 8, but def". That's how you do "unions." Kinda.
This is a gross simplification.
This is not correct. If you infringe claim 1 then you infringe claim 1. Whether or not you also infringe claim 9 doesn't matter.
Assuming Claim 9 is dependent on claim 1, claim 9 includes all the limitations of claim 1. So claim 1 is A+B+C.... Claim 9 is 1 + D = A+B+C+D. So if you infringe 9 because you have A+B+C+D then you also, by definition, infringe claim 1 because you have A+B+C.
Also, you can write a claim that has ORs applied. But the drafter has to be really careful with how it is done and it is not the norm.
I did a lot of work in pharmaceutical route development, where some patent does "ABCD123" and we'd do "ABCD456". My point is more that, patents are usually laid out like:
1. A method for crystallization of a pharmaceutical in an organic solvent with some counterion.
2. (1), where the solvent is ethanol, or methanol
3. (1), where the counterion is Cl, SO4, or NO3
4. (1), where the pharmaceutical is a COX2 inhibitor
So that patent doesn't allow you to claim any crystallization route with ethanol. If I crystalize from ethanol but use mesylate as the counterion, I'm not infringing.
The claims are the legally enforceable part.
Terrifying that went through.
Edit: Some examples, including the use of chunks, or what I call batches:
> It appears to describe a data-oriented component entity system in which all data types within a component are assigned to chunks (batches) in such a way that they can be optimally grouped with data from components of other entities for optimal memory access.
This is not new either. I and others have done this for years. The term "archetype" is something they made up to describe something that has been done many time before.
Edit: It appears that the term "archetype" was introduced somewhere in the last few years. Not sure then if it is specifically coming from Unity.
There might very well be prior art for that as well but any ECS system where the layout scheme has been defined in advance would not be relevant one way or the other. At least that is my read of all of this.
Either way, how the hell do you get a patent for some abstract diagrams that represent a design pattern.
Like can I patent the "novel" by submitting a diagram like:
| Character | Setting |
| Situation | Theme |
Patents are unfortunately very obtuse to read and hard to parse, and it's especially easy for a lay person to give up very quickly and as a result misinterpret the patent. This is especially true when you're pointed to the patent by a rando on the internet telling you what (they think) is patented, even if it's not accurate.
Another contributing factor is that, even when you read the claims, a lot of the actual description may be functionally irrelevant to the actual thing being claimed. Suppose, for a moment, that you were patenting a new kind of bike pedal. Then your actual claim would look like an overly verbose and vague description of a bike that includes your new kind of pedal. And since most of the paragraph is describing a bike, it's easy to assume that what is being patented is the bike and not the pedal of that bike.
Seminal talk btw IMHO
The version Unity's been building with DOTS was, I believe, being headed by Mike Acton, who's been advocating for years for everyone in the industry to abandon OOP and switch to data-oriented systems. I wonder what he thinks about this.
My take is that this patent is part of a defense-in-aggregate strategy which leverages a larger portfolio. I don't think a legal team would stand on this one alone in a AAA vs AAA studio fight.
I usually visualize large corporations pointing patent piles at each other as if they are locked in some sort of cold war. I have zero fears that this patent would be used against me or any of my work.
I didn't look close enough to see if what they're patenting is something specifically unique to Unity3d's implementation. It would have to be?
From the abstract it sounds like the equivalent of trying to patent Observer/Observable.
Maybe there is a history of patenting software architecture that I'm not aware of, I'm not an expert in patenting in software development.
Patenting such technology runs counter to the reality that this track of game engine innovation in particular has been one particularly notable for the open sharing of techniques and technology, in the interest of everyone benefitting from a better approach in core architecture that improves performance and reduces incidental complexity. At some point, it became a cultural norm that people were not going to hold their cards close to their chest on this core part of the game loop. There are a lot of areas where I'd be inclined to accept the idea of IP protections for game engine companies on an ethical basis: this isn't one of them.
With staff being quoted previously:
“We are far too often put in front of the dilemma of either working according to the European Patent Convention and respecting the examiner’s guidelines, or issuing ‘products’ as our hierarchy demands"
The wikipedia article on him is harrowing.
This is dumb