> 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
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").
> 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.
Where does the patentability filter fail? By "clearing the bar of novelty beyond prior art" I am referring to both novelty and non-obviousness.
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.
>> 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.
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.
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.