Copyright and Patents [2]

1. Copyright
2. 27 September 2000 and build 384
3. 10 July 2001 and build 401
4. 13 December 2001 meaning and action
5. 3 February 2002 4D interface and 4D space

Patents

We have not sought patent protection for some aspects of the product and its delivery, as published here, which we deem to be obvious given the state of the art.

However, in order to protect ourselves against malicious, opportunist or hostile actions or even against the sheer bad luck of coincidence, we publish here some principles which are instantiated in our software and its delivery and which are implicit in our other publications. But are made more explicit here.

The following text is *not* a claim to patent or any other legal right. Rather its publication is to protect us from any 3rd party patent issued subsequent to our work which may claim monopoly rights in work similar to our own (were ours to remain unpublished). Such patents might in the least case cause us unwelcome inconvenience. And such patents might only achieve validity were we not to publish our work in sufficient detail or at an appropriate level of abstraction.

To repeat, we consider all of our work described below to be "state of the art" and "obvious".

The following text is abstract and is likely only to be meaningful if you read everything else we have published on ROOMS (i.e. which is traceable from this Web site).

Volumes
Volumes are classified as positive and negative. A positive volume is a solid in free space. A negative volume is a hollow space in a solid. A fluid or gaseous volume may be considered as positive or negative as is convenient to machine or operator.

On extruder:
Volumes can be defined by one or more cross-sections and a set of geometric transformations operated on one or more cross sections. A cross-section may be specified from vertices or a template or a user input device. A transformation may be specified from vertices or a template or a user input device. A template is any reference to one, some or all of the data elements needed to describe the cross-section or transformation or from which such a description can be generated. An extruder implements some or all of these operations to yield a volume or assist an operator yield a volume.

On room creation:
Volumes can be defined by one surface-segment (or by a hollow) plus a set of other surface-segments (or by hollows) which may have coincident edges and be closed, or may have one or more (or most) segments dropped (i.e. hollow) so that a volume is substantially open and only sparsely defined (and the apparent volume is indicated by other means, like adjoining volumes or independent individual artefacts) A surface segment may be defined from vertices or plane equations or enclosing surfaces or abutting surfaces or enclosing volumes or enclosed volumes or abutting volumes or a template or a segment type or a geometirc type or a user input device Room creation implements some or all or a combination of these operations to yield a volume or assist an operator yield a volume.

On group icon composition:
Volumes (or the entities, if any, which support them) may be associated with one another and the association be used to distribute data among volumes. The data may be instructive or metric or both. Distribution may be machine or operator initiated and under machine or operator control. The association may be data bearing and include the machine states of the volumes (like position, internal) or the appearance to the operator (like lighting, external). The association may be a conduit for data (instructive and/or metric). The association may be created or altered or deleted under machine control or by an operator using a user input device. Volumes may ignore or override or combine conduited data with other conduited data and with unconduited (e.g. direct) input under machine or operator control. Conduits may be arbitrarily opened without a pre-existing association.

On EVAC instructions:
Entities recognised by the product may have intructions associated with them. An instruction has a condition for operation and an operation to perform when the condition is met. Condition and operation may be given names, and may be defined under machine or operator control. Condition and operation may have associated data. Condition and operation may be be gathered as a set to be evaluated together. Condition and operation may store context between evaluations and use stored context as a further condition or operation or associated data. Condition or operation may represent or implement an event. Condition or operation may represent or implement an action. Condition or operation may refer to one another or to condition or operation in a distinct other entity. A means is provided to create, adjust and delete conditions and operations under machine or user or external control, and to run conditions and operatins under machine or user or external control.

On licence key:
A means is provided for restricting product usage according to criteria indicated in supplier-user licence agreement or elsewhere as communicated between parties. A token (e.g. a licence key) is issued which may activate the product. Successful activation may be conditional on the tokens being applied in the correct context. The correct context may include a time element. Contextual variables may be encapsulated in the token or in the product such that they may be varied from activation to activation without altering either the product or the activation mechanism. Activation may be restricted to certain product life cycle stages (like installation) Activation may be dependent on correct operator identification via a user input device. On deactivation a token may be issued to enable deactivation to be confirmed (e.g. to a supplier)

On business model:
Product may be shipped in different editions offering different functionality. Some functinality may have to be activated via a licence key or token. The licence key is purchased from the supplier. This may be an electronic transaction. Extra functionality may be available at no extra cost given a prerequisite level of licencing. Operators may also create their own extra functioanlity and may make a charge for or licence use of their creation (such as operator/user created addons). Addons may be sold or licenced widely or narrowly. Narrow licencing (e.g. to a single end-user) may attract a premium licence value, as a custom or bespoke enhancement, since the value of the licence is sustained so long as the enhancement is not proliferated, and that can be up to the end-user - should the licence so allow and this remains in the iterests of the end-user. (i.e. self sustaining value, an anti-piracy measure, through end-user self-interest) This adds value for supplier, addon creator and end user.