Copyright and Patents 
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
27 September 2000
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 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.
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
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
Activation may be restricted to certain product life cycle stages (like installation)
Activation may be dependent on correct operator identification via a user input
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
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.
27 September 2000
www.rooms3d.com (c) Copyright EiDoxis Limited 2000