My read (and from what I know of ECS) is that it's basically claiming a system which automatically organizes the memory layouts of instances of different types of "entities" (i.e. "type" meaning which "components" it includes) in an efficient manner.

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.

Splitting up objects attributes into separate arrays is required if you plan to work with those data on the GPU. I did it when working with Java and OpenCL, and wanted to efficiently access the same data trough Java objects and also in OpenCL kernels. OpenCL does not know about objects, like Java, but it can access data in arrays, so practically every Java object holds an index into the arrays of the different attributes.

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.

Yeah I think it's a huge roadblock for Unreal. Though, I'm not sure that the patent would preclude a system which organizes memory layouts at build-time rather than runtime (though I could be wrong about that). Could be a good opening for Unreal, though to this point I think they've (disappointingly) shown little interest in any kind of ECS system.

It's basically describing using a slab allocator to arrange the entities. How is this new art?

I don't know the details of slab allocators. Though if you are describing an allocator that does not have knowledge of what the memory is being used for (e.g. the difference between asking the allocator for memory for a position component defined as three floats and also a color component also coincidentally defined as three floats, versus asking the allocator for two sets of three floats without regard to their intended usage), then it is not the same.

Some slab allocators are type aware, because some of them reset "freed" items into a type-specific initialised state ready for re-use

> it's basically claiming a system which automatically organizes the memory layouts of instances of different types of "entities" (i.e. "type" meaning which "components" it includes) in an efficient manner.

V8 was already automatically creating virtual classes for Javascript objects like thirteen years ago.

> and most of the rest of the document is generally irrelevant

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.

I should have been somewhat more precise with my wording. The document is generally irrelevant for the purposes of deciding whether or not your product potentially infringes the patent. It's not until after processing the claims, or perhaps during if you're unclear about terminology or meaning, that you start considering the rest of the document.

Seems I misinterpreted your comment.

> What the patent actually covers is governed by the claims at the very end of the patent, and most of the rest of the document is generally irrelevant, per my very limited understanding of how patents work.

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.

> So if you have a widget and it matches claim 1-8 but does not match claim 9, it does not match.

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 may have explained it incorrectly, I'm a bit rusty.

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.

Considering the doctrine of claim differentiation, your hypothetical could still be infringing Claim 1. You’d have to consider the spec, among other things, to persuasively argue one way or the other.

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.

The other disclosure establishes prior art for other people and sets you up for more patents in the future with the same prior art date (continuations).

The claims are the legally enforceable part.