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.
V8 was already automatically creating virtual classes for Javascript objects like thirteen years ago.
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.