Presumably its a co-ordination language and data flows between stones down and to the right. Perhaps Black and white might just represent arity and what a stone actually did might not be denoted by color. You would have monadic stones (white?) and dyadic stones (black?) and the syntax would require that monadic stones have at most one stone above or to the left since they can only accept one input at a time.
Either that or the language would be weakly typed and data arriving from above or from the left would be processed separately.
The board would have a left and a top which would accept inputs from the environment but could extend infinitely to to bottom and right.
Is the "must be Apple branded" alsewhere in the EULA?
That would have been around 1984 or 5 I think. So yes, it was "usual" or at least published by way of a software product by around the mid 80s. So certainly by 1991 it was not new. I don't believe I invented the idea either - in any case, it was certainly an idea that would have occured to anybody "versed in the arts" back then. Back then the process was done by phone. You generated your unique id, called us and we have you a hashed key to unlock the functionality derived from your generated key.
Just for amusement, this was done in Australia too. Not that that means this earlier system should have been known to the patentee.
But surely to be a seizure implies loss of use.
Not arguing the judge should have allowed the practice. Just wondering about the use of terms.
Of course, the English drive on the right side of the road (which is to day, the left) so the passing lane is the right hand one.
In Australia I don't think there is a law but at least one person has been booked for "obstructing traffic" when failing to get past in a reasonable manner.
If you think about the inheritance tree (in C++ if you like) then all methods are inherited. There are no synthesized attributes. On a general tree, attributes can be both inherited (they flow away from the root) and synthesized (they flow towards the root). These terms were original introduced by Knuth, I think, a long time ago in a context far far away.
In a language like C++ you have to know what type has the synthesized attribute to do a dynamic cast, so you cannot write a routine that will work with any type that has a given (set of) method(s). So you end up forcing all the methods used by some set of classes down into a common ancestor (perhaps, in C++ as pure methods), which is a nightmare or even impossible if the common base class is not in a subsystem you own or can convince someone to change.
One way to handle this in a statically typed language is with interfaces. You define a parameter as supporting an interface. This can be (partially) checked at compile time at the call point and assuming your language allows checking at runtime, never converts a compile time fail into a runtime fail because you would otherwise have had to do a dynamic cast that would itself only fail at run-time.
It does have the advantages that more of them fit in the bedroom and people don't look at you funny.
Old programmers never die, they just hit account block limit.