Note: Descriptions are shown in the official language in which they were submitted.
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
0 Any-To-Any Component Computing System
REFERENCE TO RELATED APPLICATION
This application claims the benefit of US Provisional Application No.
60/164,884, filed
November 12, 1999.
5
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to the field of computing systems.
Particularly,
the present invention relates to computing systems that can mimic human data
manipulation.
0 More particularly, the present invention relates to an Any-to-Any computing
system that can
simulate human-type information processing and enables natural language
communication
with the computing system.
2. Description of the Prior Art
Acceptance and use of computer systems could be significantly increased by
making
the systems easier to use. The process of easing the use of computers,
however, appears to
have reached a roadblock because conventional computer systems process
information in a
limited and hierarchical manner that is fundamentally incompatible with the ~
non-limited,
nonhierarchical manner in which humans process information.
0 In the state of the. art, both software and data construction and storage
comply with
the requirements of a One-To-Many machine. A One-To-Many machine is defined as
"a
machine in which one assembled structure has a fixed relationship to one or
more assembled
structures, in a manner that is intrinsically hierarchical and is
intrinsically limited." In software
today, this fixed relationship is normally a programmer-created relationship
that the user
5 cannot change. The situation throughout the prior art is analogous to a
factory in which a
1
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
particular component, such as a particular screw, was only delivered to the
factory pre-
assembled into an engine, where it was only found in one place in the interior
of the engine.
In order to use that particular screw elsewhere - for example, to use it in
assembling a car
door - the only possible solution would be to use mechanisms (screwdrivers or
wrenches for
instance) to get into the interior of the engine, and disassemble the required
component
screw so that it could be used in the assembly of the door. In the state of
the art, the
analogous mechanisms to screwdrivers and wrenches referred to above are
mechanisms
such as OLE, or data importJexport software tools, that enable components to
be extracted
from the assemblies in which they have been stored.
Rather than becoming easier to use, conventional computer systems inevitably
become increasingly difficult to use as the functionality of the systems
increases. There have
been attempts to alleviate this problem by the industry. For example, attempts
have been
made to make user interfaces more user friendly by making applications more
intuitive.
Some have even combined language processing with their applications.
Nevertheless, in
virtually all conventional computer systems, humans are taught to use their
computer systems
more efficiently by learning to "think" more like their computer systems. That
is, humans
become more efficient at interacting with their computers as they gain
experience in working
with them. Although the familiarization process can be accelerated through
training and
effective documentation, there is always a learning curve to climb when
(earning to use a new
20, computer system. In effect, the more functionality is added, the greater
is the user's difficulty
in learning how to control it (many users do not use more than 10% of the
functionality in
office-type software), and the software becomes self-limiting. Try as they
might, the
designers of conventional software systems appear to have reached their limit
in these
efforts. Further, as functionality has been added, complexity has increased
dramatically, and
many such high-functionality programs, frequently break when stressed, with
the result that
current software becomes self-limiting by reason of its complexity, and the
state of the art
leaves much to be desired.
Conventional software systems are also notoriously difficult to troubleshoot,
maintain,
and upgrade. As the software systems become more powerful and complex, the
ability of the
systems to do what should be the simple things, such as maintain compatibility
with previous
versions and other systems, becomes increasingly difficult. This is so because
all state of the
art software is essentially built as a one-to-many system. For this reason, a
single piece of
software, such as a word processor, is fixedly related to its document format,
its screen
display, the documents created by it, and the output methods it knows, and so
forth. From
the moment that these fixed relationships are created when writing the
program, any other
use for the data manipulated by the program, other than the single use that it
was originally
2
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
programmed for, becomes difficult without programmer or user intervention, and
even so,
user intervention is not possible unless the programmer has provided a tool
with which the
user can intervene. In addition, millions of man-hours have been spent simply
trying to
maintain compatibility between software systems that were originally intended
to be
compatible, but item upon item somehow went wrong in the implementation
process. This'
now appears to be an inherent characteristic of evolutionary software systems,
and software
developers have accepted the need to staff and budget to deal with, ongoing
upgrade and
compatibility issues.
Conventional software systems are also tremendously redundant. This results
from
the "self-contained" character of virtually all-conventional application
programs. For example,
different programs, constructed on the One-to-Many programs keep their own
separate
address lists (accounting software and email software for example) and
consequently, two
different sets of code are present on a computer with such software loaded,
each of which
achieves the same or a similar result. Several different address lists on the
same computer
are not uncommon, with each one belonging to a different One-to-Many program.
Although
the advent of "object-oriented" software has eased this problem at a
relatively high level of
functionality, the problem remains unabated at a lower level. In other words,
even object
oriented programs repeat instructions for relatively low level tasks, such as
retrieving data
from memory, outputting data to a display device, perform mathematical and
logical
operations, and so forth. Hence, the core problem in the state of the art is a
fundamental
system mismatch between software and human data manipulation.
Thus, there is a need in the art for computer systems that are easier to use,
troubleshoot, maintain, and upgrade. There is a further need for computer
systems that avoid
unnecessary redundancy. There is still a further need for a computihg system
that is capable
of manipulating data on an unlimited and non-hierarchical basis.
SUMMARY OF THE INVENTION
The present invention meets the needs described above in an Any-to-Any
computing
machine that can be configured to simulate human-type information processing.
An Any-to
Any machine is defined as "a machine in which any component or assembly of
components
can be related to any number of any component or assembly of components in a
manner that
is not intrinsically hierarchical and is intrinsically unlimited." More
particularly in relation to a
computing machine, it is defined as "a computing machine in which any number
of any
component or assembly of components, can be related to any number of any
component or
assembly of components, in a manner that is not intrinsically hierarchical and
is intrinsically
unlimited." The Any-to-Any machine is described in relation to data, which is
defined to
3
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
include user data, machine data, and software. Hence, the definition of the
machine can be
further refined and stated as "a computing machine in which any number of any
data
component or assembly of data components, can be related to any number of any
data
component or assembly of components, in a manner that is not intrinsically
hierarchical and is
intrinsically unlimited." However, it should be understand that the principles
and underlying
methods of the Any-to-Any machine can be extended to apply equally well to the
construction
of hardware. If so applied, the machine can produce considerable additional
benefits due to
the fact that the hardware, and the software, and the human are then all
operating on the
same basic Any-to-Any machine principles.
The ease of use and power and hence usefulness of the Any-to-Any computing
machine derive from the fact that the human user handles data (often as
represented by
words) on Any-to-Any principles. Conversely, the difficulty of use of state of
the art software
derives from the fact that it is built on one-to-many machine principles,
which are in deep and
fundamental conflict with human Any-to-Any data handling methods.
Unlike conventional computing systems, the Any-to-Any computing machine breaks
all
data and software entries down into indivisible, re-useable components,
including data
concerning the structure in which the machine itself is constructed (such as a
database), and
stores each component in a separate record and then, through various
mechanisms, relates
the components to one another by type. That is, each data component has an
unambiguous
meaning that cannot be further broken down without losing the entirety of its
meaning. In
addition, each software component performs a single function that cannot be
further broken
down without losing the entirety of its useful functionality. This
decomposition then allows any
type of data component type or any type of data assembly to be "paralleled" or
specifically
associated with one or more software components or software component
assemblies
configured to handle its associated data component type or assembly type. This
also allows
any data or software component to be correlated with any other data or
software component
without necessarily involving a third component in the correlation. As a
result, a single
instance of each data and software component or component assembly may be
independently and directly accessed for use in ar by multiple software modules
and this
access can occur in either a hierarchical or a non-hierarchical manner. This
avoids
redundancy in the computing system and simplifies troubleshooting,
maintenance, and
upgrades. It also enables a single software component or component assembly to
operate
on different instances of similar data types, or on completely different data
types by changing
externally stored conditions and other externally stored data that control
that component's
operation.
4
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Any-to-Any computing machine typically stores data and software code in a
Data
Relation Table that includes a Data Classification structure that serves as a
universal
interface for all data and software components stored in the database. The
Data Relation
Table mechanism, which is essentially an assembly plan for the assembly of
data
components and the further assembly of previously assembled structures, is
analogous to the
assembly plan for a car or airplane. Such vehicles are built from single-
function individual
components such as screws and bolts and nuts. In the case of a factory
assembling cars or
airplanes, these single-function components are stored in bins and then
assembled; resulting
eventually in a complete car or airplane.
In the case of the Any-to-Any machine, that data is usually received from the
user in
the form of assemblies, not in the form of components. For example, any one
word is at
minimum an assembly of the word itself, and the (invisible) concepts) or
meanings) that go
along with it. In the case of a word such as "fax," this word, when
transmitted, is essentially
an assembly consisting of a single word (fax) plus more than a dozen
components of the
individual meanings of the word. Without applying the Component Principle, it
is typically not
possible to easily, fluidly, and flexibly access individual components for
further use, in the
manner to which a human is accustomed, simply because there is no simple
manner in which
to address or reference them individually.
If this "Component Principle" is applied to this problem, and the individual
components
are stored individually, then of course, any component can be referenced
individually, and
consequently, can be used with any other component. In the absence of this
disassembly
process, the assembly is itself a One-to-Many assembly (one word, several
meanings for
example) and consequently, it is not possible to use any one individual
component without
using all the other components at the same time, and this is the underlying
problem in the
prior art practices.
Hence, the data assemblies received from the user or elsewhere first need to
be
disassembled, and then stored in component form, sorting each component in
such a manner
as to indicate its type (for example in Data Class record types which are
analogous to
physical component bins, with the difference that they store types of
components). In the
case of data - such as words and their meanings, this typing, uniquely to this
invention, is not
done based on classically-used mechanisms such as grammar, syntax or
probabilities, but
based on meaning or function. Because words are then related by their meaning -
as
opposed to their grammatical classification - differences, similarities and
identities of meaning
can be found and used, regardless of the grammatical classification of
particular words. For
example, in an Any-to-Any machine, the words "invite', 'invitation',
'invitingly' are all related by
a common stem meaning - as are all the 14,500 other comprehensible variants of
'invite' that
5
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
experimentation shows it is possible to create using different combinations of
prefixes and
suffixes
Once disassembled and stored, the components are then available for use and
are
then assembled in any useful combination with each assembly being recorded in
one or more
Data Relation Table records. One desirable principle in constructing an Any-to-
Any machine,
in accordance with the Component Principle, is the absence of as many as
possible
programmer-created fixed relationships (such as are current in the state of
the art) between
any one data component or component assembly and another. Ideally, this should
be as
near complete as possible and preferable for the application concerned.
For example, in conventional databases, a programmer often ascribes a field
name (a
label) to a given field in the database, another name to that field in the
user interface using
that database, and then that name or label may be displayed on the screen and
another
name cannot be displayed on~ the screen without also changing the first name.
The result is
that the programmer has created a fixed relationship between a given field and
the (only)
i 5 label that particular field can cause to be displayed. In an Any to Any
machine, such
database field names are disassembled from the database itself, by treating
them as though
they do not exist as far as the user is concerned. Instead, any number of
different Label
Records are stored in the Data relation table in a fashion that is Field
Parallel with the
particular type of data they label are used. The output mechanisms of the Any-
to-Any
interface enable the contents in each field of any Label Record (or any other
record for that
matter) to be used so as to label (or re-label) any field or combination of
fields when they are
being output in some manner. Consequently, any field can be given any label,
and individual
users can label a given type of data in any manner that happens to suit them,
or data can be
re=labeled in other languages simply by selecting a different language of
record to use for a
given output. One importance of this is that users are individuals, and terms
and displays that
are convenient to one person are incomprehensible to another, yet existing One-
to-Many
software construction methods make it extremely difficult to change these,
difficult to change
them on the fly and difficult to change the manner and labeling of the output
depending on the
person who is looking at the data.
An element of ease of use that is enabled by the invention, is the ability to
show any
data in any fashion, with the consequence that the input and the output of any
data can adapt
(if suitable mechanisms exist) or be adapted to each individual user.
Additionally, the application of the Component Principle to separating the
displayed
field name from the database field name, and further, to completely separating
the software
mechanisms that manipulate data from the mechanisms that output the results of
the
manipulation has the effect of enabling any database field to be re-labeled as
often as
6
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
required for different purposes, different types of data as well as for
different users. Enabling
this field re-labeling in a database field has the additional benefit of
turning a single-use
database into a potentially universal database that is intrinsically capable
of recording any
data - and this facilitates the acceptance of data from a human. Additionally,
the ability to
record any data enables all data to be recorded in a single standard format.
This further
enables all data to be recorded in a single structure, or in structures that
are functionally
similar (and which therefore, can accept data transferred between one another
without
requiring major transformation). Relationships between data items consist, at
their most
fundamental level, in commonality (or lack of commonality) between single
components, and
the fact that any given component only exists in one place - for example in
one field - makes
the discovery of relationships (or their absence) far easier, and enables the
relationships that
actually exist between different data assemblies to be found in a manner that
is not
excessively complex, and once found, displayed or otherwise used. Further,
since
similarities, differences, identities and approximations between data items
can only be made
reliably on the basis of the presence or absence of individual components
andlor component
assemblies 'in given data items, the Component Principle of storage, combined
with the ability
to store components in a single or inter-communicable structures, effectively
enables an Any-
to-Any machine to compute similarities, differences, identities and
approximations reliably and
in a human-like manner.
Similarly, and as a further example, conventional, programmer-created
relations
between tables are usually avoided, as these too are contrary to the Component
Principle.
Creating a single and fixed programmer-created relationship between data in
one table and
another (for example, by embedding a record number from one table into another
table)
effectively requires still further (programmer generated) mechanisms in order
to create the
potentially trillions of other relationships that are potentially possible.
Hence, the software
construction in an Any-to-Any machine is directed to enabling the human to
create whatever
relationships between data that he wishes. In contrast, typically in the state
of the art it is
programmers that create the actual relationships between data, and this is a
process that is
far too slow to track with a human and the speed with which he can, by
manipulating words,
create hitherto non-existent relationships between data. Most humans are not
programmers
and so cannot adequately create relationships using current software methods,
yet, in reality,
a!I verbal inter-human data transmissions consist of transmitting specific
relationships
between data, using the mechanisms of symbols (words) representing the data to
do this.
The Component Principle (in which parts of any data are disassembled into
types of
parts to the extent that further disassembly loses the entirety of the
original meaning or
function, and then stored for subsequent re-use) is the enabling method that
enables an Any
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
to-Any machine to be built. In any Any-to-Any machine, the Component Principle
is also
applied to software. Hence, software which is conventionally constructed as a
large lump, is
disassembled (or written as) fields and records that either contain the actual
software itself, or
Numbers Concept Language (described below) references to it, or references to
other
records, or references to disk files, as the requirement may be and as the
limitations of the
medium in which the Data Relation Table may permit.
In an Any-to-Any machine, the Component Principle is equally applied to the
construction of the different types of things that are usually collectively
named software:
Hence, 'software' in an Any-to-Any machine is applied by applying the
Component Principle
and disassembling it into its various types of thing, each of which is
recorded in its own Data
Relation Table record type. Examples of such software record types are
Execution records -
the only types of record that contain actual code (or references to code) in
their fields - Label
records containing records, Condition records containing conditions upon which
the code is to
act, Prompt records for in prompting the user, Help records containing help,
and so on.
When acting together, such different records types are referred to as a
module, and
generally, the code in a single field, as well as the values for the same
field in a Label or
Prompt record, all apply to the same field, a method that is referred to as
'field parallel'
construction.
A unique and powerful benefit of this method is derived by using a specific
sub-type of
Condition Record referred to as an 'If Not Found' condition record. Such a
record contains, in
its data field, a specific condition and in the Administration Field termed a
'Director Field' can
contain, or point to one or more records that state what to do if the
conditions contained in
the If Not Found Condition record are matched. Equally, instead of using the
Director Field, a
Field Parallel Director record type can be used as a matched pair with an If
Not Found
Condition record, in which the fields of the Director Record either contain
logic or instructions
or point to records that do. This mechanism has the unique benefit of having
the effect of
welding any number of machines built on Any-to-Any similarly implanted, to act
as a
transparent whole, both in terms of the data they contain, and in terms of the
abilities of their
software modules.
Applying the Component Principle method to both data and to software, produces
the
unique and novel benefit that where any particular type of data (i.e.
component or component
assembly) exists, it can be precisely and exactly paralleled by a software
component or
components, or by a software component assembly or software component
assemblies of
different types, that are hence able to perform a precise transformation on
any data type, i.e.,
where a particular type of data assembly exists, a particular software
assembly can be built to
handle that data assembly. Since data types can, from the component level
upwards, be
8
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
associated through the Data Relation Table with the specific software
components or
assemblies needed to perform a given data transformation or display, the act
of a user
specifying a hitherto unknown assembly of data components, can be made to
cause the
assembly of the software components preferable to perform the transforrriation
or display or
output that the user has ordered. This results in the unique and novel benefit
that the data
specified by the user can now drive the on-the-fly assembly of the software
components
needed to handle it, and this uniquely the reverse of the state of the art,
where the
construction of the software. itself drives the data and the data
relationships that are
acceptable. The further benefit of this, is that now that the Any-to-Any
machine can receive
and manipulate any data (provided adequate software components are provided to
manipulate types of data components), it is no longer preferable for the user
to learn the Any-
to-Any machine's restrictions and limits and rules, as the Any-to-Any machine
can
accommodate whatever the user wants and this materially increases ease of use.
A further teaching of the Any-to-Any machine construction is that software
Components are almost entirely built to handle types of data and almost never
to handle
specific instances of data. For example, a single piece of logic in a field
that is able to split an
email address into its component parts (of user name and domain name) is not
written to split
an email address (an instance) but is written to split any value into its
component parts. What
that logic is to split, and what it is to use as a basis for the split, and
where it is to put the
results, are ail specified by additional records (or field values in specific
record types).
Consequently, only one piece of actual code is now required to split anything.
A further and
uniquely beneficial consequence is that a great deal of manipulation can be
handled by
generic logic of this type. For example, in a typical implementation, only one
module is
required to prepare (create) any and ever data type, such as a fax an emaif a
letter or an
account. The generic module behaves differently based on the various specific
records and
instructions with which it is supplied by a 'boss module'. There is only one
type of Boss
Module - a module that 'runs' other modules, as it only performs a single
function. Thus in an
Any-to-Any machine the only real difference between the software required to
create an email
and a letter, are the Condition and other non-code records that are associated
with the
particular Boss Module required to create that item, which is itself a generic
module with a
specific name. For this reason, once the preferable modules have been built to
create an
email (for example) no change whatsoever is required to the code of those
modules, in order
to make them create another type of data item such as a fax. The only changes
required are
to the Condition and Prompt and other records that external to the logic
itself, contained in an
Execution Record containing code (Field Logics) in each, or most fields. Thus
a unique
9
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
benefit results of a major reduction of the size of the code base, reduced
likelihood of error
and increased construction speed.
The Data Classification structure also includes _ and helps to define a
Numbers
Concept Language that uniquely identifies specific components for specific
meanings of
language (or other) terms that might otherwise be ambiguous, or contain more
than one
component meaning or use. The Numbers Concept Language also uniquely
identifies
specific components for all software components and component assemblies.
Further, the
Data Classification structure can cooperate with a language processing system
that translates
natural language (or other languages, if desired) into Numbers Concept
Language records for
entry into the Data Relation Table. This provides the Any-to-Any computing
machine with the
ability to use natural language to communicate with a user, and to understand
and execute
natural language commands. In other words, the Any-to-Any computing machine
can be
made to communicate in a human-like natural language discourse, and (*because
all
languages are handled on the basis of Components) can also communicate in
machine
languages and can also be made to translate accurately between human
languages, between
machine languages and between human and machine languages.
The Data Relation Table structure of the Any-to-Any computing machine fends
itself to
a "field parallel" method of creating relationships between table records
and/or between field
values or combinations of field values. In the Data Relation Table, the same
field in multip4e
records can correspond to the same Data Class of the Data Classification
structure. This
allows a software Numbers Concept Language identifier to be entered into a
particular field
for the purpose of identifying software code for operating on a data entry
located in the same
field on a corresponding data record. For example, each data component is
typically related
to one or more first software components for manipulating that data component,
and to one or
more second software components for inputting and/or outputting that data
record. In
addition, multiple software-type records may be used to define a software
module. This basic
structure allows the Any-to-Any machine to be implemented in any combination
of hardware
and software, and can be configured control and operate hardware and software
that is not
built using the Any-to-Any design concepts.
Different to the state of the art in which most processing is sequential, the
field parallel
principle enables the data in the fields of a record or records to be
processed individually, to
be processed in any order, and to be processed either individually, or on a
massively parallel
basis with all fields being processed simultaneously. If the field parallel
construction of the
Data Relation Table is further reflected by constructing hardware also in a
field parallel
manner, for example, within data busses, memory chips, disk systems, and in
the form of an
individual processor or processor pipe per Data Relation Table field, then a
considerable
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
speed increase in processing is possible without the added complication and
expense this
normally entails. For example, 120 processors each of 1000 MHz processing 120
fields
simultaneously in parallel, can theoretically achieve a speed ~of 120 x 1000
MHz, i.e. 120
GHz, without requiring a 120GHz processor, data buss or chip memory to do so
and this
enables the overall system to surpass the theoretical physics limits of
conventional sequential
processing methods. Finally if the field parallel principle is carried through
further to
peripheral systems such as modems, and video controller cards, not only can
these be
controlled with infinite precision, but they can also operate more rapidly. If
this principle is
further carried through to inter-machine transmission lines, where each Data
Relation Table
field is allocated its own channel, parallel transmission lines could be taken
advantage of.
An desirable operating principle of the software of an Any-to-Any machine, is
that a
human who has caused something to be done (for example by ordering the ,Any-to-
Any
machine to perform an order) cannot refer to the order itself, or the result
of the execution of
the order, other than by using terms contained in the original order, or by
using terms that, via
a Concept Hierarchy, refer to some of the terms contained in the original
order, or, to the
circumstances surrounding the performance of the order itself, such as the
time of day at
which the order was given. The Data Relation Table permits both the order
itself and the
circumstances surrounding the creation of that order, to be recorded in one or
more Data
Relation Table records.
The human manner of referring to a previous order, or to the results of the
execution
of an order, is implemented in an Any-to-Any machine in terms of certain
specific operating
principles, as follows (but can equally be implemented in conventional
software with beneficial
results). One of these principles is that each and every human order is always
recorded, and
recorded in as much detail as is available. Another principle is that the Data
Relation Table
records containing previously given orders and the results of the execution of
the order, are
preferably never over-written, but only copied and then changed after copying,
because over-
writing (or erasing) a previous record renders that item unrecoverable in the
state in which it
previously existed and in which it may be required to be specified as part of
specifying a
further activity. For example, if the following order is given "send an Email
to the guy to whom
1 sent the letter I printed last week on the ABC printer" cannot be executed
if it was not
recorded that the letter concerned was printed on the printer the user
specified.
Still another operating principle is that if excessive records result from the
practice of
not over-writing or erasing records, then such excessive records are firstly
archived and later
removed using a 'detail deterioration algorithm' following a principle termed
the 'unlimited
principle.' The Unlimited Principle is stated as "the software may not limit
the human in any
manner in which he does not limit himself." For example, while a human may
remember what
11
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
he ate for lunch the previous day, he wilt not normally either remember what
he had for lunch
14167 days ago, nor will he have the slightest interest in recovering that
data. Since past
events are of different importance, the "Importance" Administration field, and
the "importance"
record type enable types of data to be graded, a grading that the
deterioration algorithm can
eventually use to remove records of no further interest. Yet, a further
principle is that the
previous principle, in which records are not normally erased or over-written,
means that the
resulting Data Relation Table forms a time track - a continuous record of past
events in time
order, from latest backwards.
Hence, the operation of the searches conducted on the Data Relation Table,
different
to state of the art practice, do not generally require a search of the entire
table. It requires
only searches starting from present time and working backwards to find the
required
matches, with relatively few searches requiring the whole table to be
searched. Even when
the entire table theoretically needs to be searched, for example to find "all
emails from Joe"
the use of Administration fields and their fields such as User Number (for
Joe) record type,
record sub-type and record sub-sub-type themselves permit the search to be
limited to only
those record types that are emails, as well as being for Joe's user number.
Hence, a search
is not required, only recovery of all records that contain the appropriate
Numbers Concept
Language numbers in the appropriate fields.
In an Any-to-Any machine, each Data Relation Table record can contain one or
more
fields for Life, Time, Space, Energy and Matter. Using different values in
these five
categories, it proves possible, with various methods to record any data
whatsoever.
Additionally, in any Any-to-Any machine, a field can either contain a value
for a concept or
combination of concepts, or, point to another record and consequently, the
value of each
particular field can actually be specified by a further record, and the value
of each field of that
further record can, themselves be specified in a further record. Further, any
given concept
can either be specified as a field, or by a record of that type, or both, and
one can point to the
other. Combining these two mechanisms produces the unique benefits by 1 )
enabling one
thing to specified in terms of another - for example, a particular time can be
specified as the
time when a particular event did, or will occur 2) enabling any one particular
Data Relation
Table to be transformed automatically into another and 3) enabling the data
relation storage
mechanism to be infinitely scaleable.
A further desirable principle of the Any-to-Any machine, and a principle that
is
applicable to the construction of the storage medium and the Find Modules
using it, and one
that also dramatically improves the speed and accuracy of searching in
conventional
computing machines is the Co-reducing Concept Principle. This principle is
also a key
element in enabling an Any-to-Any machine to function at all.
12
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Co-Reducing Concept Principle may be stated as "a human specifies
something
by continuing to add concepts each of which excludes all other concepts, until
such time as
the concepts now specified are unique (i.e. are the one thing or group of
things he wishes to
specify) and explicitly exclude all other concepts." Note that the order in
which the concepts
are supplied is immaterial to the resulting concept that is specified, (but
may not be
immaterial to the further concepts that are supplied afterwards). A further
principle of key
importance to enable an Any-to-Any machine to function usefully, is that when,
in human
interaction, a specification given to another human is thought to be unique
but is not, the
listener continues to prompt the speaker for further concepts until such time
as the resulting
specification is unique. For example, a boss may say to a secretary "call New
York" and the
secretary might reply 'Who in New York - there are only x million people in
New York?" The
boss might clarify "clients" and the secretary might prompt "Which ones? We
have about
1,000." The boss might add another concept: "Mine (i.e. my clients)" and the
secretary might
further prompt "ALL of them?" and receive the further concept "No, only the
ones that are my
friends." This interaction of the Co-Reducing Concept Principle with another
is termed the
'Co-Reducing Concept Prompt', and is triggered by a mismatch between the Co-
Reducing
Principle specification and the results produced by it. This mechanism may be
implemented
between the Any-to-Any machine and its users, and can also be implemented
between Any-
to-Any machines themselves, enabling them to interact constructively.
The above concepts and principles may be achieved through a universal database
structure. This structure implements a semantic network and an optional
Concept Hierarchy
wherein each concept is uniquely identified by a number or numbers i.e., each
concept is
assigned a number in a Numbers Concept Language.
Each concept or concept assembly (representing a data item) in the database
may
have semantic network links to all other data items that reference or are
related to that data
item or are referenced by the data item, where the links represent a type of
relationship that is
identified by a concept.
Note that the Numbers Concept Language may be used throughout the Any-to-Any
machine, with the exception of the fields used to record actual wards and
phrases in a
particular language. Nevertheless, a simpler and more limited but Stiff
extremely useful Any
to-Any machine has been built successfully using words themselves, without
translating them
into Numbers Concept Language, an Any-to-Any machine has been built that uses
both
methods simultaneously. In simpler~applications, a full Numbers Concept
Language
implementation can be overkill.)
Generally described, the present invention includes a computing system that
may be
stored on any type of computer storage medium, and may be expressed in
software;
13
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
hardware, or a combination of software and hardware. That is, the invention
includes a
computer-executable method defined by instructions that may be stored as
software or
implemented through computing hardware, or a combination of software or
hardware
computer storage media. The computer executable instructions expressed within
the
software and/or hardware define a computing system that stores data having an
original
meaning by disassembling the data into data components, the further
disassembly of which
would cause the loss of substantially all of the original meaning. The
computing system then
stores each data component independently. Similarly, software having a
required function
may be stored by creating the software as a number of software components, the
further
disassembly of which would cause the loss of substantially all of the required
function. The
computing system then stores each software component independently.
The computing system typically classifies the data components into data
component
types, and creates one or more software components or assemblies of software
components
that are configured to perform an operation on an associated data component
type. Likewise,
the computing system may also classify assemblies of the data components into
data
component assembly types, and create one or more software components that are
configured
to perform an operation on an associated data component assembly type.
To facilitate storing the data and software components in an any-to-any
configuration,
the computing system defines a data classification interface including a set
of semantic data
classes for categorizing data items. The computing system also defines a set
of records
including fields configured for containing numerical indicators corresponding
to the data
items. These numerical indicators are defined within a numbers concept
language dictionary
in which each numerical indicator is uniquely associated with a base data
item. This allows
the computing system to correlate the semantic data classes with the fields of
the records to
associate a particular numerical indicator located in a particular field of a
record with an
associated data class. The computing system then stores the data components as
records
expressed in the data structure, and the software components may also be
stored as records
expressed in the data relation structure. In particular, one or more data
components
containing numerical identifiers in a particular field, and one or more
software components
containing numerical identifiers in the same field, identify software
components that are
configured to operate the data components.
The computing system may also be configured to receive a natural language
block
and convert the natural language block into one or more records expressed in
the data
relation structure. These records are then stored in the data relation
structure. The
computing system may then identify one or more fields of these records
containing numerical
identifiers, identify one or more software components configured to operate on
data
14
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
components having numerical identifiers in those fields, and call those
software components
to operate on the data components.
The computing system may be configured to include an order execution system
that is
operable for receiving data inputs and performing operations in response to
the data inputs.
This order execution system defines a data relation structure that includes a
data
classification interface that defiries a set of semantic data classes for
categorizing data and
software items. This set of data classes is said to be "semantic" because each
data class
connotes a particular meaning for a data item assigned to the class. For
example, the term
"Bob" assigned to the data class "first name" indicates that the term "Bob" is
a first name,
whereas the term "bob" assigned to the data class "action" indicates that the
term "bob" is the
verb form of "bobbing up and down." This allows the data class structure to
assist in
identifying an unambiguous meaning for a base term that, by itself, may have
several different
candidate meanings.
The order execution system also includes a set of records defining fields
configured
for containing numerical indicators corresponding to the data items. These
numerical
indicators are typically defined within a numbers concept language dictionary
in which each
numerical indicator is uniquely associated with a base data item. The data
relation structure
correlates the semantic data classes of the data classification interface with
the fields of the
records to accommodate the association of a particular numerical indicator in
a particular field
of a record to connote a data component that identifies an unambiguous meaning
for the data
item.
The order execution system typically contains many data blocks, such as
commands,
queries, or other data inputs received from a user or other computing system.
Each data
block has an original meaning and is disassembled into data components, the
further
disassembly of which would cause the loss of substantially all of the original
meaning. Each
data component is then stored independently as a record expressed in the data
relation
structure. Similarly, software having a required function may be constructed
from a number
of software components, the further disassembly of which would cause the loss
of
substantially all of the required function. And each software component may be
stored
independently as a record expressed in the data relation structure.
The data relation structure may be functionally configured as a data relation
table or
as a semantic network. The data classes of the data classification interface
are typically
grouped into a set of semantic data categories selected from the group of
categories
including administration, life, time, space, action, and matter. In addition,
the records
expressed in the data relation structure are typically selected from a group
of record types
including data records, condition records, code records, prompt records, label
records, help
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
records, and other types of records. In some portions of the data relation
structure, a group
of contiguous code records expressed in the data relation structure define a
software module
for performing a multi-step operation: In other portions, data records
containing numerical
identifiers in a particular field, and one or more code records containing
numerical identifiers
in that same field, may identify software that is configured to operate on the
data records.
The computing system may also include an interface control system operable for
receiving a natural language block, and a language processing system that
typically receives
the natural language block from the interface control system. The language-
processing
system then converts the natural language block into one or more records
expressed in the
data relation structure and connoting a unique meaning ascribed to the natural
language
block, and passes the records to the order execution system.
In this case, the order execution system may be configured to receive the
corresponding records from the language processing system, and determine
whether the
corresponding records define an unambiguous command. The order execution
system may
then execute the command if the corresponding records defines an unambiguous
command.
Alternatively, the order execution system may cause the interface control
system to prompt
the user for additional information if the corresponding records does not
define an
unambiguous command.
That the invention improves over the drawbacks of prior computing systems and
accomplishes the advantages described above will become apparent from the
following
detailed description of the embodiments of the invention and the appended
drawings and
claims.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a functional block diagram of an Any-to-Any computing machine
including an
interface control system and an order execution system.
FIG. 2 is a functional block diagram of an Any-to-Any computing machine
including an
interface control system, a language processing system, and an order execution
system.
FIG. 3 is a functional block diagram of items contained in an order execution
system
for use in an Any-to-Any computing machine, which items may be stored in the
form of a Data
Relation Table.
FIG. 4 is a functional block diagram of items contained in a language
processing
system for use in an Any-to-Any computing machine.
FIG. 5 is a diagram illustrating a Numbers Concept Language dictionary for use
in an
Any-to-Any computing machine.
16
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
FIG. 6 is a diagram illustrating. a logics table for use in an Any-to-Any
computing
machine.
FIG. 7 is a diagram illustrating the use of data/software parallel n-tuplet in
a Data
Relation Table for use in an Any-to-Any computing machine.
FIG. 8 is a diagram illustrating the structure of a Data Relation Table for
use in an
Any-to-Any computing machine.
FIG. 9 is a logic flow diagram illustrating a process for responding to
natural language
commands in an Any-to-Any computing system that includes a language processing
system.
FIG..10 is a logic flow diagram for a language processing system in an Any-to-
Any
computing system.
FIG. 11 is a logic flow diagram illustrating a process for responding to
natural
language commands in an Any-to-Any computing system that does not include a
language
processing system.
FiG: 12 is a diagram illustrating an implantation of the Numbers Concept
Language
table for defining concepts and Data Class Table physical storage.
FIG. 13 is a diagram illustrating a translation table containing forward
references to
string values in a string table illustrated in FIG. 16.
FIG. 14 is a diagram illustrating the Data Relation Table Label, Prompt, Query
and
Help record sub-types.
FIG. 15 is a diagram illustrating the Data Class Table Records-DATA containing
the
Numbers Concept Language of the data values.
FIG. 16 is a diagram illustrating a portion of a Data Class String Table
containing
string values in English Concept Language with associated converted Numbers
Concept
Language values.
FIG. 17 is a diagram illustrating a portion of a Java Class Table containing a
reference
to the byte codes for the associated concepts.
FIG. 18 is a diagram illustrating the Co-Reducing Concept principle.
FIGS. 19A-19H are diagrams listing the generic field names and data categories
used
in one embodiment of the present invention.
DETAILED DESCRIPTION OF THE EMBODIMENTS
The present invention may be embodied in an Any-to-Any computing machine that
can
be used to effectiveiy simulate human-type information processing. Turning to
the figures, in
which like elements refer to the same elements throughout the several figures,
FIG. 1 is a
functional block diagram of an Any-to-Any computing machine 10 that may be
accessed by a
user 12 (The user can be an actual person, or the same or another Any-to-Any
machine
17
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
acting as a user). The Any-to-Any computing machine 10 includes an interface
control
system 14 and an order execution system 16. For this particular embodiment,
the Any-to-Any
computing machine 10 does not include a language processing system capable of
interpreting natural language text. Instead, the interface control system 14
is configured to
receive structured data inputs that are, by their structured nature,
unambiguous. For
example, structured inputs typically include buttons, selection fists, check
boxes, text boxes
and similar items and can include structured data of any type. An example of
the interface
control system 14 is described in the commonly-owned co-pending United States
Patent
Application No. entitled, "Graphical User Interface" and filed on November 13,
2000, and which is incorporated by reference into this specification.
The order execution system 16 receives these structured inputs and determines
whether a complete instruction has been communicated. If not, the order
execution system
16 returns a prompt for additional information to the interface control system
14, which
presents the prompt to the user. This prompt may be presented to the user
either visually, on
a screen, or by any other method such as text-to-speech, or to another Any-to-
Any machine
by an inter-machine communication channel. This process repeats as preferable
until the
order execution system 16 has received a complete instruction, which it then
implements. An
desirable feature of this system lies in the structure and operation of the
order execution
system 16, which implements the Any-to-Any computing structure in the form of
one or more
Date Relation Tables. This type of table is described is greater detail below
with reference to
FIGS. 7 and 8.
FIG. 2 is a functional block diagram of an Any-to-Any any computing machine
10' that
includes a language processing system 18 in addition to the interface control
system 14 and
an order execution system 16 described above. The language processing system
18 allows
the user 12 to communicate with the system 10 using unstructured, natural
language input.
In other words, the language processing system 18 converts ordinary natural
language text
into Numbers Concept Language that the order execution system 16 can
understand and
respond to in an appropriate manner.
FIG. 3 is a functional block diagram of items contained in the order execution
system
16. These items include software components 20 that are expressed as records
in a Data
Relation Table 17. Each software component performs a single function on a
single data
component or component assembly, and cannot be further broken down without
losing its
functionality. In other words, each different type of thing that is normally
collectively referred
to as "software" is broken down into constituent components, such as the code
itself, external
conditions, prompts, labels, help, field names and so forth and the code
itself is broken down
18
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
to the extent that it is capable of performing a single action on a single
type of data
component. Each .software component is then stored separately, which -
together with
communication methods between software components - aNows each software
component to
be accessed and used independently of the other software components. This
allows any data
or software component or component assembly to be correlated with any data
component or
component assembly or software component or component assembly without
necessarily
involving a third component in the correlation.
In the Any-to-Any machine, the Component Principle applied to software results
in the
separation of code required to manipulate data - make a change to data - and
the code
required to output that data. A first consequential benefit of this is that
any one software
component or component assembly can output its results to any combination of
other
manipulation modules (with no visual or other output at all) and/or to any of
many alternative
output component assemblies. Secondly, in an Any-to-Any machine, any output to
a
peripheral device - such as a screen or printer is treated wholly as being an
output-time
spatial assembly of data. For example 'a letter' in an Any to Any machine is
recorded as
component assemblies, which are simply arranged with specific spatial
relationships on the
screen, a spatial relationship of data that the user recognizes as being 'a
letter'. This Any-to-
Any interface methodology results in an ability to create relationships wholly
through spatial
relationships as output time. For example, if the individual components 'Mr.',
'John' and
'Brown' are each displayed in their own borderless field on the screen (termed
an 'Active
Element') and if these fields are arranged consecutively so that they are seen
as "Mr. John
Brown", the user will understand this is the name of a person. However, if
these data
components are differently displayed in different parts of the screen - for
example 'Brown' is
displayed next to fields that state 'is a good person', the user will
understand 'Brown is a good
person.' However, only one recording of 'Brown' is required to do this. The
data to be
displayed, and the position of that data in the display or output are
controlled by Data
Specification records and View Specification records respectively. A further
advantage of this
Any-to-Any output method that is enabled by the Component Principle of
software storage, is
that if it is required to 'put' a photograph (for example) 'into' a letter, no
complex linking
method is required to do so, and instead, the field of the record containing
the photograph is
simply displayed with a specific spatial relationship to the remainder of the
data that is the
letter. A further advantage of this methodology is that no change is required
to either the
underlying data manipulation logic, or to the code controlling the display of
an item in order to
cause the visual display (or any output) to behave in totally different
manners. For example,
an Interface Behavior record (for one user) can cause a particular display
module to output
needed prompts to a user one at a time ('spoon-feed interface') in a manner
suitable for a
19
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
novice, while, another Behavior record (related to another and skilled user,
causes the very
same display module to display all needed prompts and known values
simultaneously. In
both cases, no new manipulation logic, or output Iogics is required - the only
change required
is to change a single Interface behavior record that in effects, gives the
display module
different instructions, on a field by field basis, as to what to do.
The Data Relation Table 17 also includes data components 22. Each data
component
has an unambiguous meaning that cannot be further broken down without losing
the entirety
of its meaning: These two types of components 20 and 22 form the building
blocks from
which matching and parallel data and software assemblies of higher complexity
may be
assembled.
As a result of this rigorous component-level data and software storage
approach, any
data or software component or component assembly may be correlated with any
other data or
software component or component assembly without necessarily involving a third
component
in the correlation. This is the basic concept underlying the Any-to-Any
computing machine.
Another characteristic resulting from the component-level data and software
storage
approach is that a single instance of each data and software component or
component
assembly may be independently and directly accessed or referenced in a non-
hierarchical
manner for use independently of any other, for example in creating multiple
software
modules. This avoids redundancy in the computing system and simplifies
troubleshooting,
maintenance, and upgrades. The component principle of data and software
storage and
manipulation also enables any data component or assembly to be accessed and
manipulated
independently of any other data component or assembly. This Component
Principle also
enables data components and assemblies to be manipulated by software
components and
assemblies in a parallel datalsoftware structure, in which particular data
component or
assemblies are associated with particular software components or assemblies
that are
configured to manipulate their associated data components or assemblies.
Further, the
Component Principle of storage is also the key principle that enables an Any-
to-Any machine
to be unlimited (other than physical limits that may. be imposed upon it) For
example, if each
telephone number is recorded in a separate record, and if the display
Interface is also
constructed on Any-to-Any machine principles; and if software modules are
suitably
constructed, then, is it possible for a user to have no phone numbers recorded
or displaying,
or a thousand phone numbers recorded for him, each of which (using remaining
Data
Relation Table fields and if preferable other record pointed to from those
fields) can state the
times and locations and conditions under which it is operative. Similarly,
when a single
software component is recorded in a Data Relation Table Record, it is possible
to use the
record itself, or other records pointed to from the base record, to specify an
infinity of data
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
about that component, and to control its operation - or non-operation -
infinitely finely. This
has considerable practical application for example in the field of
Confidentiality, where the
Any-to-Any machine methods enable the Confidentiality of any data to be
controlled with
infinite precision, down to the level of individual characters. This control
extends fa_r beyond
simply who can see data, down to exactly what they can, or cannot do with it,
while
simultaneously specifying other users who should see it or do something with
it.
The Data Relation Table 17 may also include a Concept Hierarchy table 24,
which is
typically stored as an assembly of Data Relation Table records. The Concept
Hierarchy table
24 contains a listing of known relationships between or among data components
and/or
i 0 assemblies in the system's library and is a table to which users can add
in an unlimited
manner. For example, the Concept Hierarchy table 24 indicates that an "apple"
is a member
of the class known as "fruit," and a "dog" is a member of the class known as
"animal," and so
forth. The Concept Hierarchy mechanism is also used for many forms of grouping
in the Any-
to-Any machine, such as for grouping any one document or item into an
unlimited number of
groups. Additionally, other record types enable the user to state anything he
should wish
about any ane or more junior- senior relationships. 1n contrast to many state
of the art data
recording systems, the construction of the all hierarchy mechanisms is such
the membership
of an item in any hierarchy does not preclude that same item (as opposed to a
copy of the
that item) being included in any other hierarchy and further, allows any
hierarchy to be
accessed directly at any level without going through the entirety of the
hierarchy.
Membership in multiple hierarchies does not require multiple copies and also
allows reciprocal
hierarchies - if A is accessed B can be seen as (one of) its juniors while if
B is accessed, A
can be seen as its junior, again without requiring any copies of the items
concerned, with the
result that items viewed are always up to date.
Recording these relationships allows. the machine 10 to identify these
relationships
when they occur in natural language constructs. For example, in a sentence
such as "John
brought over his dog and the wretched animal bit me," the Concept Hierarchy
table 24 assists
the machine 10 in determining that the terms "dog" and "animal" both refer to
the same thing.
The Concept Hierarchy table also enables the Any-to-Any machine 70 to perform
a function
known as "return nearest truth." For example, the machine may respond to the
question, "did
Joe go to New York by train?" with "no, but he did go Chicago by plane."
Similarly, the
machine may respond to the subsequent question, "did he go yesterday?" with
"no, but he is
going tomorrow."
The Data Relation Table 17 also includes a Data Classification interface 26,
which is
used to differentiate between different meanings for the same term, and also
to define a
21
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Numbers Concept Language for uniquely identifying each component meaning for a
language construct having multiple possible meanings. The Data Classification
interface 26
serves as a universal yet variable interface for all of the records stored in
the Data Relation
Table 17 and hence, relates data to the software that manipulates that data
type. That is, a
particular interface typically operates with all Data Relation Table tables or
records containing
data of a particular type, and could include a particular application or span
many applications,
yet may be specifically assembled for a particular application. The records in
the Data
Relation Table 17, in turn, can be correlated into higher-level software and
data structures to
create software modules, databases, spreadsheets, and any previously-unknown
type of data
item. Thus, the Data Classification interface 26 effectively serves as a
universal interface for
all of the software modules and data structures implemented within the Data
Relation Table
17. The Data Classification interface 26 also contains and communicates both
with the visual
or other output interfaces and with the language processing system 18, which
converts
natui~al language input into Numbers Concept Language records that can be
entered into the
Data Relation Table 17 by way of the classification interface. As a result,
software modules
and data structures implemented within the Data Relation Table 17 can have the
ability to
receive and process natural language input, as well as machine languages and
virtually any
other type of input.
The Data Relation Table 17 also includes a logics table 28, which correlates
software
components with number concepts language identifiers, i.e., numbers that
correspond to
predefined components. This can be used to allow the Numbers Concept Language
identifiers, rather than the softv~rare code itself, to be entered into the
Data Relation Table 17.
It should be noted that the same holds true for the specific meanings of
words. That is, each
specific meaning of a word is stored as one or more Numbers Concept Language
identifiers
in the Data Relation Table 17.
The Data Relation Table 17 also includes record correlations 30, which are
implemented through several features. First, multiple components may be stored
in different
Data Classes of the same record in the Data Relation Table 17 to indicate that
these
components have a combined meaning (in the case of non-software data) or a
combined
function (in the case of software-type records) in that record. For example,
the term "faxed"
can be said to be comprised of four different components, one of which is the
word itself, one
that means "an action," another that means "to send by facsimile,", and third
that means "in
past time." All four of these components stored in the same record connotes
the meaning of
the term "faxed." However, the part of the meaning of "faxed" that is "an
action is typically
22
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
defined by storing the Numbers Concept Language identifier for the term "to
send by
facsimile" in a Data Relation Table field dedicated to storing types of
actions.
According to the concept of a 'Data Class' - concepts entered into a given
field of
Data relation Table records being used for a specific tape of data - all items
in the given Data
Class are instances of the type of data in that is in that Data Class, and are
members of it,
because they are more similar to one another than they are similar to any
.other data
whatsoever. This is termed the Similarity Principle, and in applying ii, it is
preferable to
beware the fact that when a word appears to apply to more than one Data Class,
this is
always due to the fact that the word has different meanings, each of which do
indeed belong
to different data Classes. In addition, at feast in the English Language -
there always is a
meaning or construction of every word that makes it apply to at least two
different Life Data
Classes, and at least one (and often more) of the remaining Data Categories of
Time, Space,
Energy or Action and Matter.
A further type of record correlation is known as "field parallelism," in which
multiple
components are stared in the same field of different records. For example,
when a data
record has a particular component entry in a particular field, a software
record rriay have an
entry in the same field. The fact that a particular software assembly applies
to particular type
of data assembly and vice versa can be stated by a wide variety of mechanisms,
including
Administration fields used in a particular manner, and records of specific
types that state this,
but when field parallelism in use, the Software modules concerned are so
constructed that
the Field Logic in a given field is able to handle and in nearly ail cases
only handles data
components or component assemblies in its same-number field. A third major
type of record
correlation may be implemented through administration fields defined within
the Data
Classification interface 26. These Administration Fields are used to control
the data and to
enable specific relationships between records and record types and also
between data andlor
software users to be recorded and used. In addition, any other type of
parallelism can be
configured into the Data Relation Table structure, in which data and
associated software
parallel each other through the presence of their Numbers Concept Language
indicators in
the same field (e.g., column) of the Data Relation Table 17. An desirable
benefit of the use of
field parallelism is that it provides an orderly framework in which a
programmer can work and
enable him to track and follow relationships that can become potentially
extremely complex.
However, while field parallelism is used in the construction of the Any-to-Any
machine, the
database need not store empty fields and thereby improves search space and
reduces
storage space.
23
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
FIG. 4 is a functional block diagram of items contained in the language
processing
system 18. These items include a grammar stripping module 32, a grammar
formatting
module 34, a language rule base 36, and a Numbers Concept Language (NCL)
dictionary 38.
These elements work together to process natural language communication into
NCL records
for entry into the Data Relation Table 17, and vice versa. In particular, the
grammar stripping
module 32 removes the application of grammatical features to effectively
decompress the
natural language communication. For example, the term "faxed" can be
decompressed into
"action, fax in past time," the term "Joe's" can be decompressed to "belonging
to first name,
Joe," and so forth. The grammar stripping module 32 also decompresses the
effect of
operator words (words that have both a meaning and perform an operation on
their own or
other words or groups of words) such as "and", "on", "of", as welt as the
pronouns, and other
pointing, linking words, suffixes, and prefixes. The resulting decompressed
language can
then be processed by the language rule base 36. The grammar formatting module
34, on the
other hand, uses a different rule base to perform compression on NCL records
and turn them
~ 5 into grammatically correct readable language. Since all languages can be
decompressed into
components, and then stored as Number Concept Language, and because one
component
always has a corresponding component or component assembly in another
language, it is
possible to enter data once in one language, and then read it in all other
languages for which
Numbers Concept Language translations exist in the data relation table.
The language rule base 36 includes a set of rules that are used to identify
and remove
higher-level compressions, and also to identify which of the candidate
meanings for a
particular term is indicated in a particular natural language construction.
For example, the
term "fax" can mean the "act of sending by fax," the "fax machine," the
"document sent by
fax," or the "document received by fax. For each candidate meaning, the rule
base 36
identifies other elements in the language construction that should be present
to justify that
particular meaning and such a rule is termed a Requirement Rule . The rule
base 36 does
this for each term in a block of natural language, and then identifies a set
of meanings that
simultaneously satisfies the requirements for all the meanings. This method of
determining
meanings has the benefit of finding when a given thought - as transmitted by
words - is in
fact complete and stands on its own, and can therefore be processed.
Typically, the rule
base 36 can be optimized by ordering the meanings in a priority order based on
frequency of
occurrence in the language of interest (as determined in advance and typically
stated in the
record encountered), and then goes through the permutations and combinations
of meanings
in decreasing priority order until it finds a set of meanings that
simultaneously satisfies the
35. requirements for a1f the meanings. Once an unambiguous meaning has been
selected for
24
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
each term in the block of language that has been previously decompressed by
the higher
level decompression rules, the NCL dictionary 38 converts the block into an
NCL record for
entry into the Data Relation Table 17.
FIG. 5 is a diagram illustrating the structure of the NCL dictionary 38 in
greater detail.
The single term 42 "fax" in the language construct 40 "fax Joe about bananas"
will be used to
illustrate the operation and structure of the NCL dictionary 38. All terms are
translated into
NCL format for entry into the Data Relation Table 17 in a similar manner. The
NCL dictionary
38 includes a number of columns that define a Data Classification interface
26, each of which
is a Data Class. It should be noted that this is the same Data Classification
interface used by
i 0 the Data Relation Table 17, so that NCL records created for the NCL
dictionary 38 can be
readily entered into the Data Relation Table 17, and data records in the Data
Relation Table
can likewise. be translated back into words using the NCL dictionary 38.
The Data Classification interface 26 includes five data categories 44: fife,
time, space,
action, and matter. It should be noted that the Data Relation Table 17
includes a sixth data
category, administration, which is used for record manipulation and, by using
different
combinations of numbers in various fields, can also act to define higher level
data and
software assemblies. Each data category, in turn, is broken down into dozens
of Data
Classes, each containing types of meanings, that can be used to distinguish
between the
candidate meanings of various terms. In one embodiment of the present
invention, a set of
80 or so Data Classes for the English language had been shown to provide an
acceptable
performance for the system 10 in prototype embodiments used for typical office
administrative
tasks. It should be understood an appropriate set of Data Classes may vary
from system to
system depending on the functionality of the system and the vocabulary of the
users. For
exai~nple, an Any-to-Any computing machine is used for scientific research and
a children's
entertainment system will have significantly different sets of Data Classes.
Each Data Class forms a column in the NCL dictionary 38, and each data
component
in the dictionary forms a row, which is referred to as a "record." To enable a
numbers-based
identification convention, each Data Class is assigned a number. For example,
the classes
could be numbered left to right from one to 80. In the example shown in FIG.
5, only a very
small subset of the Data Classes have been shown. Specifically, no Data
Classes are shown
for the category "life," one Data Class numbered "30" and entitled "end time"
is shown for the
category 'Time," one Data Class numbered "31" and entitled "direction" is
shown for the
category "Space," one Data Class numbered "32" and entitled "type of action"
is shown for the
category "Action," and two Data Classes numbered "33" and "43" and entitled
"type of
machine" and "type of document" are shown for the category "Matter." I should
be noted that
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
data records from any two or more different Data Relation Tables are
effectively
interchangeable because a Data Glass can be represented by a field of its own
type in a Data
Relation Table, or by a record of its own type in the Data Relation Table, or
by both. Those
skilled in the art will therefore appreciate that one type of record in a
first Data Relation Table
can be conveniently converted into a different corresponding type of record in
a second Data
Relation Table. When converting simple data, such as a book or a Newspaper
into NCL, it
can be more efficient to convert and store the resulting NCL text not in the
form of Data
Relation Table records at all, but as a Continuous NCL string, in which each
NCL component
has a second number denoting the number of its Data Class and in which the
needed
Administration fields are similarly recorded. This method is efficient
provided that the storage
medium such as the database described herein, stores both Data Relation
Records and
Continuous-NCL in the same format, so that relationships of components can be
found.
The particular Data Classes shown in the NCL dictionary 38 have beeri included
to
illustrate the application of the NCL formulation to the term "fax" from the
language construct
""fax Joe about bananas." The Base Meaning of each term in the NCL dictionary
38 is
assigned a unique number. For the purpose of this example, the term "fax" is
assigned the
number "24," the term "in" is assigned the number "25," and the term "past
(time)" is assigned
the number "26." The Base Meaning of a term, to which the number of "24" is
assigned in the
case of the word "fax" is that Component part of the meaning of the word that
is common to
all the different individual meanings of the word. Although each term is
assigned a unique
NCL Base Number, this does not yet connote that a given spelling of word has
an
unambiguous meaning because the same term can often have several different
meanings in
different language contexts. Each different meaning, therefore, is defined by
its own
assembly of NCL data Components, and a separate NCL record is used to
represent each
meaning of a given word, and the Base meaning is a common factor in each such
record.
Returning to the "fax" example, this term can have four different meanings -
all of
which contain the Base meaning of "fax" - fax (the received document), fax
(the original
document), fax (the machine), and fax (the act of sending). These meanings are
each
defined by a separate Component assembly that is represented by a different
record in the
NCL dictionary 38. Specifically, the Component for fax (the act of sending) is
defined by
entering the NCL Base Number "24" for the term "fax" into the data field "32"
for "type of
action." This indicates that the term "fax" for this particular Component
assembly is a "type of
action," i.e., fax (the act of sending). This can also be stated as an NCL
expression of "32.24"
for this particular Component. That is, the first entry "32" indicates the
field number - thereby
stating the Data Class concerned - and the second entry "24" indicates the NCL
base
26
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
number, hence representing the two Components of the meaning "action" and
(type) fax by
the two NCL numbers 32 and 24.
Continuing with the "fax" example, the component for fax (the machine) is
defined by
entering the same NCL base number "24" for the term "fax" into the data field
"33" for "type of
machine." This indicates that the term "fax" for this component is a "type of
machine," i.e., fax
(the machine). This produces an NCL expression of "33.24" for this particular
component -
the first entry "33" indicates the field number, and the second entry "24"
indicates the NCL
base number. _
Similarly, the components for fax (the original document) are defined by
entering the
NCL base concept number "24" for the term "fax" into the Data Class field "43"
for "type of
machine." This indicates that the term "fax" in this case is a "type of
document," i.e., fax (the
document). This produces an NCL expression of "43.24" for this particular
Component
assembly.
1n actual use, in order to distinguish the original document from the received
document, the Component assembly for fax (the received document) it is
preferable to utilize
two Components in a single record. Namely, the NCL base number "25" for the
term "in"
entered in field "31" for "direction of action," and the NCL base number "24"
for the term "fax"
entered in field "43" for "type of document." This results in the NCL
expression "31.25 &
43.24" for this particular meaning of the terms " received fax/es." (Note that
the quantity of
received faxes) is not specified by the record of this example and a further
NCL term in a
Quantity field is required to state the number of fax documents received, and
that number can
of course be zero.
The derivation of the NCL expression for the term fax (the received document)
illustrates the use of multiple Components in a singie record to connote a
relationship
between the Components: The same approach can be used to encode other complex
terms.
For example, the term "faxed" may be defined by the NCL base number "26" for
the term
"past" entered in field "30" for "time of action," and the NCL base number
"24" for the term
"fax" entered in field "43" for "type of document." This results in the NCL
expression "30.25 &
43.24" for the term "faxed." In a similar manner, Components may be combined
in an NCL
record to define mufti-work constructs, such as phrases, sentences or other
blocks of
language. Furthermore, the same principle may be used to represent and store
non-
language data constructs in component form, such as numbers, software, parts
of sound,
parts or images, and so forth.
FIG. 6 is a diagram illustrating the logics table 28 for use in the Any-to-Any
computing
machine 10
27
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The logics table performs the function of correlating specific chunks of
software code
with NCL numbers, . so that the chunks of code can be conveniently indicated
in an NCL
record. The unique benefit of recording the code in this fashion, is that,
should the code have
an error, it is only preferable to change the single and sole instance of the
code itself, and no
update is required to the (potentially) thousands of modules in which that
code may be used.
The second advantage is that when a programmer wishes to add functionality,
most of the
functionality he needs will already be present in the form of existing Logics
that he can specify
in his Modules, and he only needs to write the specific Logics needed to
perform the data
transformation that he wishes to perform, but which do not already exist. This
substantially
reduces construction time.
Thus, the logics table 28 includes a first column for the record number -
which also
doubles as the NCL number assigned to the chunks of code, a second column for
the name
of the corresponding chunk of code (which is optimally record in the form of
an NCL
reference, thereby enabling a programmer to view the Logic name in his own
language, if
other languages are installed) and a third column either containing the code
itself or a pointer
to a memory location where the code may be found. The Logic Table can equally
contained
compiled code. Alternatively, a particular Data Relation Table type record may
be used to
store the logic (or a pointer to a memory location where the actual logic is
stored), in which
case one field may store the logic (or pointer), and the other fields of that
record type may be
used to store data associated with the logic, such operands, conditions under
which the logic
should be operational, and so forth. (Note that, in all cases, it is possible
to record a single
Component such as a Field Logic (a piece of code that performs one
transformation on a
data in its own field) either in a dedicated table (as in this example), or in
an entire Data
Relation Table record devoted to that type of data - iri this case, the Field
Logic Data type.
Any table other than a Data Relation Table is simply a table consisting of
truncated Data
Relation Table records, and is an optimization that may cause problems in the
future, as the
remaining Data Relation Table fields are not available if required - as for
example, to
describe the logic, or for example, to state the conditions under which it is
to act. Hence, a
table other than a Data relation table and a data relation table are simply
different forms of
one another, with the table being considered and treated as a version of the
data relation
table that has been optimized for a specific purpose).
FIG. 7 is a diagram illustrating the use of data/software parallel triplets in
the Data
Relation Table 17. In the Any-to-Any computing system 10, it is often
desirable to effectively
link a data item with code for manipulating the data item through the use of
field parallel
records. Data/software parallel triplet 52a is such an example. (Note that
while a triplet is
28
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
described in this example, the number of associated field parallel records is
not limited, and
white this method is illustrated as a triplet, it is in fact an n-tuplet, with
no specific limit on the
number of records concerned). A data record 1 may be entered for a first name
in Data
Classification Interface 26, and a field parallel code record 1 A for
manipulating - the data
record may follow. Records containing code are termed Execution Records to
distinguish
their content from 'code' as the word is normally used, where actual code,
plus labels,
prompts etc are all assembled in one lump and collectively termed 'code'. Each
field of an
Execution Record only contains the actual.lines of code needed to perform the
transformation, and does not contain the Labels, Prompts, Error messages etc
that are
commonly included in normal code.
An entry of the NCL number 123 for the software code in the same field as the
NCL
number 57 in the data record indicates that the code is intended to operate on
the data in the
corresponding field of the previous record. The next record may then be
another code
record, such as an input/output record, for operating on the same data item.
Again, the entry
of the NCL number 341 for the second software code in the same field as the
NCL number 57
in the data record indicates that the code is intended to operate on or with
the data in the
corresponding field of the other records in triplet. This process may be
continued for any
number of correlated records, such as one defining the font for the data
output, another
defining a display location, another defining a color, another defining a
condition for the field,
another defining labels for the field, another defining a "help" display for
the field, and so
forth. A single code record may use multiple sets of such correlated records,
depending on
the particular user performing the action invoking the code record. For
example, if labels and
other display items are stored directly, (i.e., as text rather than in NCL
format), then different
records may be used to store similar display items in different spoken
languages. A group of
records that together, perform an operation on a particular type of user data
records are
termed a "module".
The "field parallel" technique described above can have powerful results
because it
provides a method for the programmer to maintain order in potentially
extremely complex
relationships and makes data items "extractable" for display in any given user
ihterface. It is
also an desirable part of the non-intrinsically hierarchical nature of the Any-
to-Any machine,
as, together with the data relation table structure itself, it enables groups
of dissimilar items to
be accessed non-hierarchically, down to the single field level. This is
because a particular
data item is automatically correlated in the Data Relation Table 17 with the
software records
for manipulating and displaying that data item type. Thus, a user on a remote -
computer
system can simply link to the appropriate field of the desired data record in
the Data Relation
29
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Table 17, and the data can be easily displayed in its intended format by
simply applying the
corresponding software code records.
FIG. 8 is a diagram illustrating the structure of the Data Relation Table 17
for use in
the Any-to-Any computing machine 10. The Data Relation Table 17 uses the same
Data
Classification interface 26 described previously with reference to the NCL
dictionary 38,
except that the Data Relation Table includes an additional "administration"
data category.
This provides the Data Relation Table 17 with a fixedwumber of columns that
also define an
interface for communicating with the language processing system 18, which,
like the interface
output logic, is also stored in the Data Relation Table itself. The Data
Relation Table 17 may
also contain a virtually unlimited number of records 50a-n. Each record
contains one or more
Components 56, which include a specific NCL base number in a specific field
corresponding
to a' specific Data Class. There may be many different types of records, such
as data
records, condition records, code records, prompt records, label records, help
records, and so
forth. These records may be correlated using the field parallel technique, as
illustrated by the
components 56a-c, which are located in the same field of consecutive records.
In general,
the data and instructions for any type of software module 58 do not need to be
assembled in
a set of contiguous records. (Note that, while the field parallel record type
has been
described, there is also another basic record type, termed a "Series Record"
in which the
fields of the record function as a simple list, while the remaining principles
of record
functioning remain applicable. One use of Series Record is to list the records
that are part of
a complex assembly such as a Letter or an Address. Another use is to point to
a Series
record from a specific data relation table field, thereby creating a list of
multiple values of the
same type that form the actual contents of the field doing the pointing).
F1G. 9 is a logic flow diagram 100 illustrating a process for responding to
natural
language commands in the Any-to-Any computing machine i0. In step 102, the
startup
modules cause the interface control system 14, which is also assembled in the
Data Relation
Table, to initiate a display. Step 102 is followed by step 104, in which the
interface control
system 14 identifies the user of the system, typically by receiving an entry
in a text box or by
receiving input from a biometric identification device controlled by the Any-
to-Any machine 10.
Step 104, is followed by step 106, in which the user entry is checked against
an authorized
user table to determine whether the current user is a new user. If a match is
not found,
indicating that the current user is a new user, the "YES" branch is followed
to step 108, in
which the interface control system 14 activates new user registration modules
that request
various information of the new user, such as the user's experience level, view
preferences,
and the like.
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Step 108 and the "NO" branch from step 106 are followed by step 110, in which
the
interface control system 14 identifies the user for the purpose of selecting
and invoking a user
interface type that is appropriate for the current user and for the
circumstances (depending on
whether the user is communicating through a keyboard and screen, via telephone
or email, or
whether the user is in fact another similar Any-to-Any machine).. Step 110 is
followed by step
112, in which the interface control system 14 selects and invokes a user
interface type. for the
current user. Upon displaying the user interface type, the interface control
system 14 is ready
to receive a natural language block from the user at step 116. Thus, step 112
is followed by
step 114, in which the interface control system i4 receives a natural language
block from the
user.
Step 112 is followed by routine 114, in which the language block parses the
command
received from the user and converts the command to Numbers Concept Language
(NCL).
This language conversion, which is the domain of language processing system
18, is more
fully explained below with reference to FIG. 10. Routine 116 is followed by
step 118, in which
the NCL records representing the converted command are passed to step 118 and
the order
execution system 16. At step 118, the command is matched to a software module
and the
corresponding module is activated. Step 118 is followed by step 120, in which
the order
execution system 16 analyzes the command to determine whether the user's
command
defines a complete and executable statement. if the user's command does not
define a
complete and executable statement, the "NO" is followed to step 122, in which
the order
execution system 16 causes the interface control system 14 to prompt the user
for additional
information. Step 122 is followed by step 114, in which the interface control
system 14 again
receives a natural language block (this time in response to the prompt) and
passes the block
on to the language processing system 18 at routine 116. (1n practice, commands
can be
received from either natural language entry or from entries made into specific
fields on the
screen directly). Again, the command is checked to determine if the user's
command is a
complete and executable statement. This process continues through this loop
until the user
command is a complete and executable, statement. Once the command is
determined to be a
complete and executable statement, step 120 is followed by step 124, in which
the order
execution system 16 executes the command. Step 124 is followed by step 126, in
which the
order execution system 16 causes the interface control system 14 to display
the result of the
order execution. Step 126 is followed by the "CONTINUE" step, at which point
the Any-to-Any
machine 10 may receive another command or perform any other function for which
it is
configured. With suitable Modules, the Any-to-Any machine can process
simultaneous
commands from different users and sources.
31
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Turning now to FIG. 10, this logic flow diagram corresponds to step 116 shown
in FIG.
9, and illustrates a language processing system in an Any-to-Any computing
system 10. FIG.
begins following step 114 shown in FIG. 9. In step 202, the language
processing system
18 receives a natural language order from interface control system 14. Step
202 is followed
5 by step 204, in which the language block is decompressed. This includes the
process of
"grammar stripping" to interpret and remove certain language constructs and
conventions, all
of which act as successive compressions, embedded within the block. Step 204
is followed
by step 206, in which the language processing system 18 obtains a first
language term from
the block. Step 206 is followed by step 208, in which the language processing
system 18
10 retrieves all candidate records (i.e., all records corresponding to
possible meanings for the
term) for the current term. Step 208 is followed by step 210, in which the
language
processing system 18 checks the language block to determine whether another
term remains
in the block. If another term remains in the block, the "YES" branch loops
back to step 206,
and the language processing system 18 obtains the next term and then retrieves
its candidate
records. This process continues to loop through steps 206, 208 and 210 until
no additional
language terms remain in the language block.
Once the candidate records for all of the terms in the block so far have been
retrieved,
the "NO" branch is followed from step 210 to step 212, in which language
processing system
18 applies the language rule base 36 to select the candidate record that
corresponds to the
correct meaning for each term in the block. Typically, the rule base 36 orders
the candidate
records for each term in the block in a priority order based on frequency of
occurrence in the
4anguage of interest (as determined in advance and typically stated in the
record
encountered), and then goes through the permutations and combinations of
meanings for the
terms in the block in decreasing priority order until it finds a set of
meanings that
simultaneously satisfies the meaning requirements for all the terms in the
block. If it does so,
then the terms in the block constitute a complete order, and if they do not,
then the order is
incomplete and the user is prompted for further information. Step 112 is
followed by step
214, in which all of the selected records for the block are combined into a
unitary database
record for the block. Step 214 is followed by step 216, in which the language
processing
system 18 passes the unitary database record for the block to the order
execution system 16.
Step 216 is followed by the "CONTINUE step; which returns to step i18 shown in
FIG. 9.
FIG. 11 is a logic flow diagram 250 illustrating a process for responding to
natural
language commands in an Any-to-Any computing system 10 that does not include a
language
processing system 18. This type of system includes, as previously described,
initializing the
display, identifying the user and displaying a particular view, i.e. interface
type, for the
32
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
specified user. Unlike a computing system 10 using a language processing
system 18, this
system, which is illustrated in FIG. 1, receives a structured command from the
interface
control system 14 at step 252. This structured command is usually in the form
of an interface
Active Element that is labeled with the name of a Module (such as 'E-Mail' and
activates the
module concerned. The module uses its Condition records to determine whether
the received
command defines a complete and executable statement. If the user's command
does not
define a complete and executable statement, the "NO" is followed to step 258,
in which the
interface control system 14 prompts the user for additional information.
Following step 258,
routine 250 loops back to step 252, in which the interface control system i4
again receives a
structured command from the user and passes command. This process continues
through
this loop until the user command is a complete and executable statement. Once
the
command is determined to be a complete and executable statement, the "YES"
branch is
followed from step 256 to step 260, in which the order execution system 16
executes the
command. Step 260 is followed by the "CONTINUE" step, at which point the Any-
to-Any
machine 10 may receive another command or perform any other function for which
it is
configured.
Although a broad description of the structure and operation of the Any-to-Any
computing system has been provided above, it should be understood that
specific
embodiments designed for specific applications may have remarkably different
structures that
nonetheless follow the teachings and methods of the Any-to-Any machine, a
machine type
which is made possible by the application of the Component Principle to the
subject of
computing. For example, a typical database structure for use in a Any-to-Any
system
configured to perform typical office functions, such as storing and retrieving
documents,
sending faxes, and so forth, is described below. The preferred structural
setup of the
database for this particular application is that of a modified semantic
network. Although the
database need not be implemented as a modified semantic network, it may be
advantageous
to structure it as such because the modified semantic network structure
provides data
representation flexibility, eliminates the wastage and bloat of flat tables,
efficiently supports
the Co-Reducing Concepts Search mechanism, and is fairly economical in terms
of space
and speed. Figures 12-18 illustrate examples of representative portions of the
database
structures of this embodiment of the present invention because each of these
structures
could contain potentially trillions of records.
FIG. 12 is a diagram illustrating a portion of a NCL (Numbers Concept
Language)
Table 300 containing some of the various Concepts of the database. This table
is labeled
Table #1 and simply lists all Data Relation Table Concepts 302 that are known
to the
33
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
database. The Data Relation Table (DRT) Concepts (i.e. NCL Table records) as
presented
above and further described later should be taken not so much as a physical
table layout, but
more as a specification of the kinds of Concept-level relationship types that
are known to the
database. In other words, the DRT Concepts comprise the NCL Table for the
database
system, where the NCL Table defines the Concepts that may possibly be used as
Fields
(including record types) by Tables, and not the physical layout of a
particular Table. The key
difference in the present invention is that the Concepts are defined as part
of the database
and may be used as Fields. _ In fact, any single concept in the database may
be considered as
a specific Field type. Since every Concept may be considered as a logical type
with its own
logical instances (records), any data item represented by such values may be
considered to
be a multi-dimensional coordinate location in a multi-dimensional 'space' of
interrelated
concepts. Since the number of Concepts is intrinsically unlimited, and the
number of
instances (records) is intrinsically unlimited, the conceptual space is
infinite. Thus, the
meaning of a data item is captured by this conceptual mapping. Each Concept is
a separate
record. Each of these Concepts may be used in the construction of a Data
Relation Table
Record, but not ali Concepts are necessarily used in each record. The Concepts
normally
used by (expected to be in a record of) each record type is designated by a
Data Relation
Record Type, which is itself just another Concept in the NCL Table, but a
record type is not
restricted to any particular set of Concepts. Each Concept is numbered and is
referred to in
all other tables by its Concept number (logical table number) and its record
number.
The NCL Table 300 has six fields, a record number/logical table number field
304, a
physical table number field 306, a table format number field 308, a table name
field 310, a
forward reference sequence field 312, and a backward reference sequence field
314. The
record number/logicai table number field 304 serves as the unique Concept
Number of a
specific Concept in Numbers Concept Language. The physical table number field
306 points
to the table where data for this concept is found. The table format number
field 308 is a
reference to the structure of the physical table referenced in the physical
table number field
306. Note that the table format number 308 could be stored as part of the
physical table
itself, but may be stored in the NCL Table as an optimization. Table name
field 310 is a
forward reference to the physical-storage data-type for the particular Concept
represented.
Note that this forward reference may be used to a record in the String table
designating a
Java class name for primitive values, and an "empty reference" (all zeros) for
non-primitive
values. Forward poiriter sequence 312 references the Concepts used in the
definition of the
Concept for this record, and backward pointer sequence 314 references the
Concepts which
use this Concept in their definition. Both the forward pointers and backward
pointers serve as
34
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the links in the semantic network. Note that these links include the Concept
designating the
relationship type covering the link, and as such carry semantic value. In this
embodiment, the
pointers are a 3-part number such as '6.1.23" where the first number is the
concept number in
NCL Table 300, the second number is the type identification number (type id
number, i.e., the
logical table number, which is also a Concept number in NCL Table 300), and
the third
number is the record number in the physical table used by the Concept that the
type id
number references. The three-part references embody a representation for the
most basic of
structural relationships, as "uses/is-used-by" link in the semantic network.
So, in relation to
the forward and backward pointer sequences of NCL Table 300, the forward
pointer
sequence indicates that the concept is the junior concept, i.e. the 'child,'
of a more senior
concept, i.e. the 'parent.' In this sense, the 'parent' is said to "use" the
'child'. The backward
pointer sequence indicates that the concept is a senior concept, i.e. the
'parent;' of a more
junior concept, i.e. the 'child.' In this sense, the 'child' is said to be
"used by" the 'parent'.
Since each three-part pointer carries conceptual relationship type
information, this
representation may be applied to any kind of relationship, including but not
limited to:
definitions (as in the NCL Table 300), containment or composition,
similarity/difference,
inheritance, taxonomic relationships, etc. For example, "furniture" is a
higher level (more
senior) concept to "chair" while "Louis 1V chair" is a lower level (more
junior) concept to
"chair." The highest level concepts in the Concept Hierarchy are divided into
five major
categories, Life, Time, Space, Energy, and Matter, with a sixth category,
Administration. To
better understand the meaning of the forward pointer sequence field 312 and
backward
pointer sequence field 314, it is useful to refer to FIG. 13 to get the names
of the concepts in
that particular language.
FIG. 13 is an illustration of a Translation Table 330 of the present
invention. This table
is labeled Table #2. Translation Table 330 contains the NCL translation of the
concepts into
the Natural Language word by referring to the Strings Table for the name of
the concept. The
English equivalent of the concept is given in parenthesis and is only provided
for clarity and
for ease of understanding the various concepts of the present invention.
Translation Table
330 has four fields, a record number field 332, a concept number field 334
where concept
number field 334 tracks its equivalent in the record number/logical table
number field 304 of
the NCL Table 300 of FIG. 1, a language number field 336, and a forward
reference field 338.
Turning back to FIG. 12 to illustrate the forward pointer reference in the NCL
Table
300, record #22 indicates that it is a 'Matter' concept. It is in the
uppermost level in the
'Matter' Category (See record #22 in FIG. 2) because it does not contain a
forward reference
pointer in the forward reference sequence field 312. Record #23 is the 'Time'
concept and it
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
is also in the uppermost level in the 'Time' Category. Record #24 represents
the 'Present
Time' concept and has a forward pointer sequence value of '6.1.23.' The '6'
refers to record
#6 in NCL Table 300. The matching record in the Translation Table indicates
that this field
type is a concept. The second number, number '1,' refers to the record number
in the NCL
Table 300. The second number indicates it is a NCL type and that the physical
table number
in the physical table number field 306 used to locate the record number (the
third number in
the 3-part forward reference sequence) is Table #1 (NCL Table 300). The third
number
identifies the record number in the referenced physical table determined by
the second
number: In this case, number '23' points to record #23 in Table #1 (NCL Table
300).
According to Translation Table 330 in FIG. 13, record #23 is the 'Time'
Category. In other
words, record #24 ('Present Time') in NCL Table 300 is a junior concept, i:e.
a 'child,' of the
'Time' concept. The backward pointer sequence field 314 is similar to forward
pointer
sequence field 312, except that the backward pointers in this case point to
the junior
concepts, i.e. the 'children,' to which the current field is a senior concept,
i.e. a 'parent.' Note
that in this example the notion of 'senior' or 'parent' simply means the
concept that uses
another concept in its definition, while the notion of 'junior' or 'child'
simply means the concept
that is used by another concept's definition.
It should be understood that the present invention was previously described as
based
on a Numbers Concept Language; thus, any descriptions within parentheses or
other syi~nbols
used in the various records in FIGS. 12-17 are there only for ease of
understanding. The
actual Tables in use contain only the numeric references to the various
tables, record
numbers and concepts, except for the Field Values field in the primitive Data
Class Value
tables such as the String Table.
Data Types are also included in NCL Table 300. Illustrative examples of such
type
concepts are record numbers 3-17, etc. A Data Relation Table Record's data
record may be
associated with a Java Class via the Translation Table 330, using language
number zero (0),
which denotes the internal language of the system.
At a fundamentallatomic level, the database should 'know' how to store,
search, and
retrieve primitive data values such as Strings, Integers, Dates, et al. For
this purpose, a few
Java Classes are known to the database as primitive Data Class Tables, and are
used for the
storing of values of the corresponding type. Additionally, the database should
be able to
store and retrieve executable code for Logics, which may be implemented as
Java Classes.
if a Java Class represents a native data structure, then the Java class should
provide (or
inherit) two functions, one to read an object's data from a Data Relation
Record, and another
to write an object's data to a Data Relation Record. In this manner, the
details of the
36
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
structure and implementation of the database are completely . hidden from the
Logics and
other Java code. . To represent a Data Relation Table Record in Java, a DRT
Record class
which has a type# + record# Reference is defined as a persistent identifier
for the DRT
Record, and which stores a sparse map of key + value pairs of the fields and
values actually
used, Where the key for the map is a NCL Concept Number denoting the
conceptual Field for
the value, and where the value may be any Java object, including primitive
types, data
structure classes, References to DRT Records, and also DRT Record objects.
This way, if
the database structure ever needs to be changed, the impact on the existing
Java code is
minimal. To the Java programmer, the database appears to read and write native
Java
objects, including DRT Record objects. When a DRT Record is read from the
database by
Java, the type# from the DRT Record's Reference is used to retrieve the Java
class name by
asking the database for the name of the concept denoted by the type# in the
internal
language (language zero, representing NCL itself). Similarly, the concept
number used as a
field label is exchanged for the name of the concept in the internal language
(language zero,
representing NCL itself) to get the Java object field name. This information
is sufficient for
Java to reconstruct retrieved native Java objects. Note that the database
remains unaware of
any specific Java classes beyond the aforementioned few primitive data types.
There may be several other record subtypes associated with a particular record
or
Concept, including Label, Prompt, Default 1/iew, Query, Help, and so on. In
this particular
embodiment, these record subtypes are provided in their own table called Data
Relation
Table-LPQH as Table #3 350, illustrated in FIG. 14. Data Relation Table-LPQH
350 has a
record number field 352, a DRT forward reference field 354, a sub-type field
356, a language
number field 358, and Fields forward reference sequence field 360. The Data
Relation Table-
LPQH 350 may also have a backward reference sequence field (not shown), which
works in
the normal manner. Because DRT forward reference field 354 is a forward
pointer, it has the
3-part reference sequence discussed above. Following the same pattern as
previously
discussed, the first digit references the concept number in NCL Table 300, the
second
number references the type number (in this case it is a sub-type), and the
third number
references the record number in Table #4. The language number field number
indicates the
language being used. In this case, the number '1' means it is the English
language. The
Fields forward reference sequence field 360 references the fields in the
String Table as the
labels that are associated with ,the particular data record. For convenience,
the Data Relation
Table-LPQH 350 may also have a User Number forward reference field (not shown)
to 'mark'
it as preferred by a specific User, as weft as other administrative fields, as
desired.
37
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Since a Refererice in this database system includes the Table or Type of item
referenced (plus the Record number), a DRT Record can be used to create
Assemblies of
any number of fields. The same mechanism can also be used to create assemblies
of any
number of Record Types, thus eliminating the need for a separate Assembly
Table
mechanism described later and in the priority document.
If new Concept Fields are added to a Record Type later, they may go at the end
of the
Field sequence in the Data Relation Table Records-DATA; in fact, if updating
of existing
records were allowed, any field could be added to any record at any time. .
This provides a
way to augment existing types and add new Concept Fields to NCL Table 300
without ever
having to restructure existing records or tables.
Because of the flexibility of this Reference mechanism, a Data Relation Record
can
specify other Record Types in the NCL Table Concept Fields in its reference
sequence,
effectively creating an assembly of other record types. In addition, a Data
Relation Record
can specify individual Data Records instead of NCL Table Concept Fields in its
forward
reference sequence, thus creating an assembly of individual records (also
called a 'singleton
object' or 'singleton class'). This kind of assembly is not much use as a
template for
specifying multiple data records, as all such data records would contain
exactly the same
data, but it is useful for modeling complex constructions and assemblies of
data which
comprise a higher-order data item, such as a letter, spreadsheet, or other
complex document.
The same facility allows for a mixture of Types and values in the fields used,
allowing
support for 'templates' - which may also reference executable items such as
Modules and
Logics - allowing a great deal of flexibility in specifying templates. For
example, a Data
Record might specify a Date field, a specific User's address record (which is
an assembly as
usual), a specific Greeting data record (such as "Dear Sir"), another Data
Record Type
(concept) for a text assembly (described below), a specific Signature record
(also a text
assembly), and a data record for a digitized signature. This would effectively
define a
template type for a Form Letter. The Data Record Type for the text assembly
may combine
pre-existing text data records with Name Field references to affect a
'boilerplate' for the body
of the Form Letter. Instances of this new template or type would then ask the
user (or other
~ input source) to fill in the Name Field values) in order to complete the
data-value mapping for
the new data record, thus easily creating form letters that differ only in the
name listed in the
body text.
In general, every NCL Table Concept Field may have its own Data Class Value
Table
370 illustrated in FIG. 15 as the Data Relation Table Records-DATA. Each
Concept that may
have multiple values may have a Data Class Value Tabfe, but such a table need
not contain
only values of one concept. In practice, the tendency is to store Data Class
Values with
38
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
similar structure and size in the same physical table in order to speed access
and reduce
storage overhead, but from a logical-model viewpoint every Data Class Value
Table is
independent. In fact, all Data Class Values could be stored in a single table
(such as the
DRT Records-DATA Table 370); in which primitive data values types such as
String and Date
are separated into separate tables for more optimal indexing and searching.
For each Reference used as the value of a field, the data item referenced also
stores
a 'back-pointer' directed typed relationship in the References back reference
sequence field
376. In other words, all referenced values "know" what records and fields
reference them. To
maintain these dependency relationships, every record in the database can have
a
'dependency trailer' that is merely a sequence or list of the Concept number,
type ID number
and record number of the record number field in the table for which it is
referenced as a
value. Such 'dependency trailers' are referred to as back reference sequences;
the two terms
are interchangeable. Similarly, the Fields forward reference sequence field
374 stores the
fonniard pointers to all values referenced by the data item. The collection of
dependency
relationships comprises the semantic network for the database, and provides
direct access
paths precisely equivalent to indexing every field in every record
The primitive/atomic data values. used in the database are stored once and
only once
and referenced by all records that need them. This reduces the storage
required and
simplifies the Co-Reducing Concepts Search mechanism, at the cost of
additional access
time. For example, FIG. 16 illustrates a portion of a Data Class String Table
380 for String
values where each unique string value is stored only once, and all field
values set to a certain
string value simply reference the string table number and the record number of
the string
desired. Table 380 simply holds primitive String values for use by other DRT
Records. Table
380 has a record number field 382, a Field Value field 384 and a back
reference sequence
field 386. The back reference sequence points to all the records which use
this particular
String as a value in some field, regardless of what kind of record it is, or
which field it is used
in. Each back reference is a series of three numbers previously mentioned. The
first points
to the logical table number 302 in NCL Table 300, which designates the
concept. The second
number points to the record number in NCL Table 300, which indicates how the
particular
data value is used, i.e. the type id, and also designates the physical table
used by that
particular logical table number. The third number represents the record number
in the
physical table used by the logical table number (type id) designated by the
second number
reference. Note that the Data Class String Table 380 may have a forward
reference
sequence (not shown) if desired.
39
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
An explanation of an illustrative example of the back reference sequence
pointer for a
given data item should help clarify how this "indexing" works. For example,
the back
reference sequence pointers for record number 112 (meC~home.net) in String
Table 350 are
31.29.4 and 31.29.12. The first number "31" in each sequence number refers to
the logical
table number/record number in the NCL Table 300 in FIG. 12 and the related
record number
in Translation Table 330 in F1G. 13. Referring to logical table number "31"
indicates that this
data item is the concept 'email address.' The second number "29" indicates
that this data
item is an eb.EmaiLEmail Address type. This indicates that the string is an
email address
type of data. This data type references physical table #4, the Data Relation
Table Records-
DATA 370 in FIG. 15. Turning now to FIG. 15 and Table 370 (DRT Records-DATA),
the third
numbers of the back reference sequence pointers are "4" and "12." These refer
to the
corresponding record numbers in Table 370. The Fields forward reference
sequence 374 for
records #4 and #12 point forward to the same data item that references these
data records,
i.e. the "meC~?home.net" string value in String Table 380 in FIG. 16. The
References
backward reference sequence 376 for records #4 and #12 point back to two
different
concepts, 33.32.3 and 34.32.9. Carrying through with the same procedure to
determine the
concepts and types that these data items represent, one finds that 33.32.3 is
a 'From'
concept and 34.32.9 is a 'To' concept. In other words, this string value is
used as a 'To'
address or a 'From' address for an Email type as indicated by the string value
forward pointer
in the Translation Table 330 for these concepts. In this case, the forward and
backward
pointers disclose that the data string "meC~home.net" is an email address, and
that it is used
as a "From" email address and as a "To" email address.
Turning now to FIG. 18 for an illustration of a simplified version of the Co-
Reducing
Concept, ellipses 410, 420, 430, and 440 represent the concepts that are
themselves
represented (and transmitted between humans) by the words 'MY' 412, 'New York'
422,
'Client' 432 and 'Friends' 442. When a person says to ahother, the word 'MY'
422, the listener
will understand that this word refers to all things that belong in some manner
to the speaker -
his car, his house, his wife, etc., and, excludes all and every other concept
to which 'my' does
not apply. In other words, the transmission of each word is a continuing
exclusion process,
diametrically opposite to the inclusion or amplification or elaboration
process that is often
taught in the state of the art and in various linguistic disciplines.
Similarly, if the speaker says
the word 'FRIENDS' 442, the concept transmitted 440, encompasses anyone and
everyone in
the world to which the word 'friend can be applied and excludes all other
concepts. Since
there are 6 billion people in the world, and most of them may be supposed to
know more than
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
one person to whom the word 'FRIENDS' 442 could be applied, the concept 440
transmitted
by uttering the word 'FRIENDS' 442 on its own is enormous.
However, as soon as the words 'MY' 412 and 'FRIENDS' 442, are said together -
i.e.
one after the other - it is clear that what is actually now being referred to
is that part of the
concept 410 of "MY', which also contains the concept of "FRIENDS", and
equally, what is
being referred to is that part of the concept 440 of 'FRIENDS', which also
contains the
concept of "MY". In other words, uttering the two words together has the
effect of reducing
the concept of both the associated concepts 410 and '440 to the part of each
one that
contains the other. This is the part that is illustrated by viewing the parts
of the two ellipses
410 and 440 where they overlap one another. Uttering further words "NEW YORK"
422 and
"CLIENT" 432, and thereby transmitting their related concepts 420 and 430,
further continues
the reduction process, always in fact specifying the part of each concept
where all concepts
overlap 450. Note that the order in which the concepts are supplied is
immaterial to the
resulting concept that is specified, (but may not be immaterial to the meaning
of further words
that are supplied afterwards). Thus "My New York Client friends" specifies
exactly the same
thing as "my client friends in New York, or "friends, New York, client, my" -
which is the
reverse order of the original phrase.
When a user wishes to specify something on which an action is to be performed,
for
example send an email to 'my New York Client,' the specification 'My New York
Client' will be
supplied as a query to the Data Relation Table in the form of a Data Relation
Table record
with each of the data components in its correct Data Class. Part of the NCL
entries in the
record or records being matched will contain an NCL entry stating that the
quantity is to be
one. The term 'client' contains the concept of a quantity of 1 and this will
appear in the NCL
translation for the term 'client.' When the Find is run, if more than one
person exists meeting
~ the specification supplied, then the result will be a mismatch between the
quantity - which
should be one - and is actually several. This mismatch triggers the searching
module to issue
a Prompt derived from an associated Prompt record such as "which ones?"
thereby applying
the Co-reducing Concept Principle. The principle can be further applied by
displaying the
resulting matches as well as prompting for further concepts. This enables
interactive
searching to occur.
A simple case helps illustrate how this works with dependency trailers.
Suppose, for
example, that a user asks an Any-to-Any computing machine a question
equivalent to the Co-
Reducing Concepts Search "Big & Hairy & Carnivorous & Brown". This query is
satisfied by
finding the corresponding data values for the concepts 'big', 'hairy',
'carnivorous', and 'brown',
treat their dependency trailers as sets of references, and intersect the sets
of references.
41
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The result set concisely identifies all qualifying data records, which can
then be read out.
This mechanism satisfies such queries using any number of conceptual terms
without having
to read any records except the initial conceptual value records and the
records referenced by
the result set. Also, this kind of query can easily propagate to more abstract
concepts by way
of the optional Concept Hierarchy to cover more conceptual ground such as
'large', 'furry',
and 'omnivorous.' This mechanism enables a computer to Return Nearest Truth, a
term
applied to the mechanisms that emulate the human practice that, when a given
query is not
true, the human .may usefully return the nearest information that is true.
Hence, one human
may query another "did Joe go to New York by plane?" and receive the reply
"No, he went to
San Francisco by train." The terms "New York" and "San Francisco" are both
related to one
another as they are both juniors of one of the Space Data Category Concept
Hierarchies -
they are both 'within' the concept of USA. Equally, 'plane" and "train" are
both members of an
Action Data Category Concept Hierarchy in which 'travel" is a senior member.
Note that this
search automatically propagates through containers such as sequence records.
Little programming effort is required (using existing Boolean operators) to
apply the
Co-Reducing Concept principle to any existing Internet search engine with
dramatic results.
When excessive matches to a user's search are obtained, the Co-Reducing
Concept Principle
is applied by continuing to clearly prompt the user for further concepts and
then existing
search engine logics uses these to eliminate those records that do not match
all the concepts
now being supplied. The process can be continued indefinitely, and thereby, a
user can
narrow down hundreds of thousands of hits to the two or three he requires, and
without
requiring any knowledge of understanding of Boolean operators, or of how to
construct
complex advanced searches.
Similarly, further improvement to existing Internet Search Engines can be
obtained by
classifying whatever data their databases already contain (as per the Any-to-
Any machine
principles previously described) into as many Data Classes as possible. Then
presenting to
the user an interface that presents all Data Classes simultaneously, and that
allows him to
enter whatever data he has available into as many of them as he can. Thus, the
first search
will then produce a considerably reduced set of records compared to state of
the art practice.
This practice further produces the additional benefit that if a visually
identical, but data-entry
version of the interface is now presented to a webmaster who wishes to be
fisted, the
webmaster can list his site - and instantly thereafter find it again - without
waiting for the
search engine to 'crawl' his site and hope to be listed. This method from the
Any-to-Any
machine can solve the considerable problem in the state of the art, that 70%
of websites are
not listed on any search engines at afl.
42
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Finally, this query mechanism not only supports incremental searching, i.e.
"dynamic
searching," by simply intersecting the dependency trailer sets one at a time
and displaying the
intermediate results, but the dependency trailer sets can also be pre-filtered
using the
relationship types. Further, the sets may be combined using any valid set
operators such as
union or difference, and not just intersection.
Though the physical structure of this embodiment differs significantly from
that
described in FIGS. 5, 7 and 8, it is logically equivalent to the original
intent. its capabilities
and features are precisely those defined as requirements in the following
description and in
the priority patent document, plus it has the advantage of being a more
efficient and more
flexible storage mechanism for real-world data. Its basis in semantic networks
provides a
well-studied formal grounding in state-of-the-art technology, easily extended
for a hyper-
object-oriented programming model. Future extensions to the types of
relationships defined
in the Concept Hierarchy make it capable of supporting more complex knowledge
representation such as that commonly required by expert systems.
Turning now to FIGS. 19A-H, these figures illustrate the various generic field
names
and data categories described in the present invention. FIG. 19A illustrates a
DRT Data
Class list 500 having a data category field 502, a field number field 504, a
generic field name
field 506, an information field 508, and examples field 510. Data category
field 502 contains
the various indications of the six major categories previously described, i.e.
Life, Time,
Space, Action (Energy), Matter, and Administration. Field number field 504
contains the
assigned field numbers for each generic field name. Generic field name field
506 references
the name of the particular field associated with a particular record number in
the record
number field 504. Information field 508 contains a brief description of the
particular fields
represented by the field names in the field name field 506. Examples field 510
contains short
examples of the type of data that is associated with the field number 504. A
majority of these
field names and modules are more clearly described in the remainder of this
detailed
description.
In view of the foregoing, a further general and detailed description of the
various
tables, software logics and methods that enable a computer to act as an Any-to-
Any
computing system will now be described.
Part 1 - Language Processor
In order for a computer to execute a command, a one-for-one correspondence or
relationship should be established between a given unique execution and a
given unique
input. Concept Language enables this to occur, by translating ambiguous spoken
language
43
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
into unambiguous Concept Language. Because the input from a user is in the
form of multi-
meaning words, it is difficult or difficult for a computer to process this
command, since the
command, as given in the user's language, consists of multi-meaning words. If
the particular
meaning in use in each case is not identified far the computer, then, the
command can
potentially mean several completely commands. If each word in a command has
four
different meanings, and there are ten words in the order, then the potential
number of orders
that can be transmitted by those ten words is 4 to the power of ten and such a
command in
unexecutable.
Human language can be turned into a Concept Language if the original language
is
considered to be, and is treated as a lossy compression data transmission
system.
Programmers in general are very familiar with compression as a subject.
Compression
methods and processes serve to reduce the physical bulk of data to be
transmitted
Both data compression and data decompression in general are rule-based
systems,
having for their object, the reduction of the quantity of material requiring
to be transmitted and
its subsequent re-expansion to make it intelligible. .
Outline of a Concept Language
In order to make a human language usable for computer control, therefore, the
first
step is to transform - in any convenient fashion - any words in the language
that do not have
unique meanings, into symbols (such as words or numbers), or combinations of
symbols each
of which do have unique meanings. The set of symbols needed to do this are
termed a
"Concept Language" The main requirements for a Concept Language are
essentially (but not
wholly) a language for use in a computer where:
1) Each symbol in the language symbol should be unique, and
2) Each unique symbol the Concept language should have only one meaning and
may never have two or more meanings.
3) When being used as a translation for a human language, a Concept Language
needs to have a unique symbol or combination of symbols adequate to
unambiguously designate each part of each meaning of each word from the
language that is to be used by the computer.
A CONCEPT LANGUAGE is an invented term and is further defined as: 'A language
in which each individual unique and whole concept or whole meaning is
represented by its
own unique Concept Symbol, or by its own unique combination of Concept
Symbols.'
A single CONCEPT SYMBOL is defined as 'a single and unique symbol, different
from
any other symbol, which represents a single, and whole, and unique thought or
idea.
To explain a Concept Symbol in more detail, in the English Language, some
words
meet the requirement for a Concept Symbol. For example, the concept that is
conveyed by
44
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the symbol '1' is unique. The symbol '1' has only one, unique concept or
meaning attached to
it. The concept of '1' is not identical to the concept of '1.1', and it is not
identical to the
concept of 'almost 1', and it is not identical to the concept of a 'car'. '1'
is not identical to any
other symbol, and the concept associated with it is not identical to any other
concept. Hence,
the symbol '1' qualifies as a single Concept Symbol. The word "banana" does
not qualify as a
Concept Symbol because it has several meanings: 1 ) 'this is a banana', (a
fruit). 2) 'He is a
banana' (type of person). 3) 'The shoots of the young banana are eaten as a
delicate
vegetable (a plant) 4) shades of banana and cream (a color).
However, the word "banana" can be used in a Concept Language if each unique
meaning is identified "by a unique symbol or combination of symbols". This can
be done by
designating the respective meanings as 'bananal" banana2" banana3" and
"banana4" for
example.
A Concept Language formed in this manner, using words from a language such as
English is referred to as an "X Language Concept Language" - for example, as
in this case -
'ENGLISH CONCEPT LANGUAGE.'
However, in many cases it may be desirable to translate a human language into
a
Concept Language consisting wholly of numbers, and such a language is referred
to as a
Number Concept Language.
A CONCEPT STATEMENT is defined as a series of Concept Symbols together, with
or without spaces between them that are joined in some recognizable manner.
Thus, the methods that de-compress a language, have as their output an
invented
language that is termed "CONCEPT LANGUAGE". Since the symbols in the Concept
Language and their meanings are unique, Concept Language output in the form of
Concept
Statements - each with a unique meaning. Concept Statements can be manipulated
with
state of the art software technology, simply because they are the unique
output that software
demands and requires in order to execute an action. Effectively, a Concept
Language can be
'understood' by a computer, simply and only because all symbols and symbol
combinations
all have unique meanings
Many (but not all) of the processes of the method for translating Normal
language - containing
words with two or more meanings - into a Concept Language are a single type of
process that
are the processes of de-compressing Normal Language.
1 ) A Note on Grammar
Classically in the state of the art, language is considered to obey the rules
of
Grammar, but attempts to use the rules of grammar to solve the problems of
computer
understanding have so far not produced results. Investigation actually shows
that in terms of
understanding the meaning of the words, grammar is not helpful, and sometimes
is actively
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
misleading. In essence, Grammar is an attempt to classify word into types
based on function
in the sentence. However, the process of creating a one-to-one relationship
meanings and
executions requires classification of meanings, not a classification of
functions of words in the
sentence and hence, grammar is not useful, except in formatting Concept
Language output
back into spoken language.
2) Compression in Language
In the case of language, it is not actually possible to receive the full
original data, since
this lies in the user's head in some form and is not accessible to a computer.
Hence, only
compressed text may be available, consisting of normal spoken words or written
words
arranged according to the rules of Grammar. This situation is similar to a
community of
modems that are actively communicating with one another with great ease, using
their
compressions and protocols. A programmer comes along and attempts to output
the raw
transmissions passing between the modems to control a computer. In effect,
some of what
he is feeding into the computer is not meanings at all, but protocols and
compression
symbols. In this analogy, people are like the modems talking to one another,
using protocols
and compressions to convey large quantities of data rapidly in a compressed
form. The
programmer can be successful - provided he de-compresses the transmission
first. Carrying
the analogy further, the world of modems consists of not just one modem
language - one set
of protocols and compression methods, but of several hundred sets
corresponding to the
several hundred languages in the world. In this analogy, one community of
modems can not
talk directly to any other group of modems but needs translation routines that
translate, not
the original data, but can only access the compressed data. This Any-to-Any
machine then,
is a set of methods to take any such human compressed transmission - a spoken
language -
and convert it to a Concept Language, which is a computer manipulable form of
its original
meaning.
Different languages uses different compression methods, and hence, the Any-to-
Any
machine is described as a series of methods by which a particular form of
compression in use
in a particular language can be detected and eliminated, in the process of
translating the
human language into any convenient Concept Language
Once a language is viewed as a compressed transmission medium, any language
can
be translated into Concept Language.
Many different types of compression can be found to exist in a given language.
Frequently, multiple compression levels exist - one compression on top of one
or more
previous compressions. The following examples illustrate some of the
compressions in
Normal English Language:
3) De-Compression method 1 relate new data to previous data .
46
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
If one person asks another 'Tell me everything you know about bananas' the
resulting
reply may occupy a minute of talking, or several hours of talking if the
person is an expert on
bananas. Clearly, in that person's mind, the single word 'bananas' has a
concrete
relationship to a very considerable body of knowledge. The situation is
similar to looking up
the word "banana' in an encyclopedia, and there, directly related to the word
'banana' by
physical position on the page, are many lines of description concerning
'banana'. Simply
saying to someone the one word 'banana' and then asking that person, 'when I
said 'banana'
what did you think of?' will also demonstrate the existence of this
relationship.
In effect, the word 'banana' can be viewed as an extremely compressed form of
the
person's banana-knowledge package, exactly as the title of a book is a
compressed
reference to the book itself. Saying only the words 'The Bible' to someone,
and asking them
what came to their mind shows the relationship that exists in their mind
between the book title
and the body of knowledge that is the book itself.
Hence, the single ~rvord 'banana' is a symbol that actually refers to, and is
a
compressed form of all memorized knowledge of banana. "Cat' is a compressed
form, and
refers to all memorized knowledge about cat. 'John Brown' is a compressed form
of, and
refers to all memorized knowledge about John Brown - as this conversational
example shows:
Person 1: 'John Brown went on holiday.'
Person 2 'Not surprised. He hasn't had a holiday for ten years. Where did he
go?"
Person 1 'Jamaica.'
This conversation shows the following recorded (remembered) relationships
exist in the minds
of the participants (the '&' sign is used to indicate the existence of a
relationship):
Person 1: John Brown & holiday
John Brown & Holiday & Jamaica
Person 2 John Brown & holiday & time
Holiday & Holiday location
In the course of the conversation, Person 2 added some new relationships to
memory:
John Brown & Holiday & Time now.
John Brown & Holiday & Jamaica
If Person 2 is later asked by Person 3 'Where is John Brown?'
Person 2 will reply 'In Jamaica.'
Person 2 could only give the reply 'in Jamaica' if the new relationships had
been
established in his mind - in memory - by the previous conversation. In effect,
the
compression that is the words 'John Brown' was added to, to include Jamaica.
47
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
By viewing and treating single Concept Symbols as compressions of all
knowledge
related to the symbol itself, it becomes apparent that for software to be able
to 'understand'
and hence to execute a user's instructions, it should be built in such a
fashion that each
distinct concept 1 ) is recorded and 2) is decompressed by relating it to all
knowledge
recorded .in the computer concerning that concept.
It is not difficult to imagine that a computer that had obeyed the requirement
to record
the new relationships could also reply correctly to the question 'Where is
John now?' just as a
human would. Treating language transmission as compressed data that should be
de-
compressing the data - in this case by recording the relationship of the
symbol to the data -
enables the computer to copy one of the human data handling methods.
The Data Relation Table as previously escribed, enables the relationships of
new and
old knowledge to be related togetyher and to be found as required, and once
found, to be
used as needed. The fact that records conctaining new and old knowledge
automatically will
be related by commonality of Numbers Concept Language components, does this. A
query
phrased as "tell me everything you know about George Brown" will elicit eve
.rything known
about that individual.
4) De-Compression Method 2 - relate each meaning of a word to its definition:
Consider now a further applied to single word compression:
Person 1 to Person 2: 'Oh1'
Person 3 to Person 2: 'So you spoke to Person 1. What happened?'
Person 2 to Person 3: "He was surprised.'
Person 3 to Person 2: "How do you know that?"
Person 2 to Person 3:"He said, 'Oh!"'
Clearly, there is a concrete relationship in the mind of Person 2, between
'Oh!' and the
word 'surprise'. If one asks 'why does such a relationship exist?' and refers
to a dictionary,
the definition given is "Oh' is an exclamation.' Referring to the definition
of exclamation finds
'the loud articulate expression of pain, anger, surprise etc.'. In other
words, a relationship
exists between
Oh & surprise.
And that other relationship occurs in the definition of the word 'Oh'.
Person 2 could only give the answer he did, because he knows (remembers) this
relationship. Hence, a single word is also a compression of its own definition
and the above
demonstrates the second method of Language de-compression:
Each word in a Concept Languageshould befurther de-compressed by relating it
to
its own definition as part of the body of data to which that word is related
and that
definition should be available for use in processing.
48
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
When a word such as "Oh' is related to-its definition, then all instances of
surprise can
be found, no matter whether they were expressed as 'Oh!' or as "I am
surprised.' A Computer
is then able to answer questions such as: "was Person 1 surprised?' and reply
with 'Yes'
which is the right answer. But in the absence of treating "Oh" as compression,
a computer -
as in the state of the art - treats 'Oh' as 'Oh' and 'surprise' as 'surprise.'
If it is then asked
'Was Person 1 surprised?' - i.e. a database is searched for the word
'surprise' - it will answer
'Not found' i.e. 'No', which is the wrong answer.
The "Definition" field OR record type, in a Data Relation Table (if used)
provides a
method for doing this. The record that contains the Concept Language statement
for a
particular meaning of a single word can either point to, or be treated as
paried with, a record
or series of records that is the definition of that word. Consequently, when
necessary, the
recorded definition of a word can be used to
5) De-Compression Method 3 - Concept Heirarchies.
Consider the following pair of conversations:
Person 1 to Person 2: Joe is flying to New York tomorrow.
Person 2: OK.
Person 3 to Person 2: Did Joe train to New York?
Person 2 to Person 3: No, he flew.
For Person 2 to answer a question about trains with a response about flying,
there
should be a relationship in that person's mind between:
train & fly
That relationship between the word 'train' and the word 'fly' is not stated
anywhere in
the above conversation. A review of the definitions of the word 'fly' shows
they do not usually
contain 'train' or any variants of the word 'train'. Yet a relationship should
exist or otherwise
Person 2 would not have replied 'He flew' but would have replied 'What do you
mean by 'train'
to New York?.' Further, there is no reference text that can be referred to
that says: " 'train'
and 'fly' are related". However, if a data relationship that exists for people
is not also enabled
for a computer, that computer will.not 'understand'.
This relationship may be reali2ed by treating the above as the result of a
type
compression that is termed Concept Heirarchies
Amethod for detecting Concept Heirarchies in a language concerning actions, is
as
follows:
A) A question is asked of the word concerned: 'is this MEANING of this word a
type of
something, a way of doing something, or a member of some group of similar
things?'
Asking this question in relation to the word 'fly': 'Is 'fly' a way of doing
something?'
shows the answer could be: 'Yes, it is a way of travelling.'
49
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Now asking the same question of the word 'train': 'ls train a way of doing
something?'
could yield the answer 'yes, it is a way of travelling' - the question can
produce the same
answer in both cases. Effectively, then, both 'fly' and 'train' are related in
that they are both
ways of travelling and can be considered as compressed, with their
uncompressed versions
being:
'train' _ travel & train
'fly' - travel & fly
(Note that practically each meaning of each word usually has at least one form
in
EACH Data Category. For example, "travel" has a meanings as follows:
Life Data Category tabler (quality of one who tables something)
Time Data Category Table time
Space Data Category Table (when used as the space the table occupies "go to
the table")
Energy Data Category Tablize ("Put something on the table for later
consideration")
Matter Data Category Table
When looking for concept heirarchies, it is useful to ralize that each data
Category has
its own type of Concept Hierarchy. Space Data Heirarchies are within one
another - New
York is within USA. Matter data categories are types of things. A Chair is a
type of furniture.
When the meaning of "New York" is a thing, it is in the Concept Heirarchy of
types of things -
it is a member of the type of thing which is a city. When it is being used
with a meaning of a
Space, it is within a Space Concept Heirarchy, where one thing space is
physically within
another.)
Returning to the example of a an Erergy Data Category Conce[pt Heirarchy,
while the
actual concept is 'travel & fly', only 'fly' is transmitted, i.e. it is a
compressed transmission that
relies for understanding on the fact that 'everybody knows' that 'you can
travel from one place
to another by taking a plane.' And everybody knows that: "you can travel in a
train from one
place to another.' But while every person knows that, and can use that
knowledge to
understand what is said and answer questions on what was said, a computer can
not 'know'
that unless it is has been specifically 'told' that. Once the computer has
been told, it should
record that information in a suitable, usable form, that can be and is related
to received data
when necessary. Concept Heirarchies; expressed either in Senior Junior tables
or as
Relationship Record pairs in, type Concept Heirarchy, in the Data Relation
Table, are
methods for doing this.
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
When two or more members of a Concept Hierarchy are found - as in the above
example - other members can be located by asking a question similar to the
following (when
dealking with an Energy data Category Concept Hierarchy):
B) Are there other ways of doing that type of activity?
Asking this question of the word 'travel' yields answer such as 'car' 'bus'
'sailing' and
so on and reveals other memebers of the same Concept Heirarchy.
In fact, the lossy compression in the above example extends further. Consider
this
extension of the previous conversation:
Person 4 to Person 2:What did Joe do?
Person 2 to Person 4: He flew to New York.
Asking the 'Concept Hierarchy Locator Questions' on the word 'travel' gives
the
answer 'travel is a way of moving'. Asking the same question of 'move' yields
that 'move' is a
way of doing something, or one of the things that can be done.
Thus,, in fact, 'fly' (when used as an action) is even more of a lossy
compression than
it appeared to be in the above explanation and fully expanded is actually:
'fly' - do & move & travel & fly
Hence the question 'what did Joe do?' can be treated - in software terms - as
a query
for any values found whose uncompressed versions contain 'do.'
This type of lossy compression is termed a 'Concept Hierarchy Compression.'
The de-
compressed meanings are termed a 'Concept Hierarchy.'
The word 'do' is the word most commonly used to query for the concept of any
action
of any kind: "what does a fax actually do?" 'What is the weather doing?' 'When
are you going
to do that?'
The word 'do' effectively covers every single type of Action that can exist.
However,
the word 'move' covers only a portion of ali the actions covered by 'do'.
Other categories of
'do' exist besides the 'move' category - for example, the 'think' category,
containing words
such as 'think' 'suppose' 'wish' and so on.
'The word 'travel' takes in only a small portion of the 'move' category and
itself
includes within it ways of travelling such as 'fly'. But 'fly' is only one way
of the ways
travelling. Others are 'helicoptering' 'training' 'jetting', 'driving' and so
on.
This type of hierarchy is given the invented name of a 'CONCEPT HIRARCHY,'
which
is a practical and useful tool enabling the relationships between word
meanings to be
determined and expressed. It is a tool that can be used to locate and
establish relationships
between the concepts expressed as lossy compression words, and express the
relationships
in a format that can be manipulated by software.
51
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
In more detail now, the general method that may be used to establish a Concept
Hierarchy is as follows:
A Concept Hierarchy is established by checking if there are other similar
concepts to
the concept in question, and if so, checking if those similar concepts are
covered by a
word that expresses the concept of the group to which they may both belong. If
such
a word does exist, that word is the concept of the senior group in their
hierarchy and
the concepts of the words in question belong to that group. The type of
questions that
can assist with this are A) 'is this word a type of something? And B) Are
there other
types of this?
6) Each Meaning has its own Concept Hierarchy
The word 'banana' has at least four meaning as previously described. Each
meaning
has its own Concept Hierarchy.
'Banana' as yellow color, includes 'color' and 'yellow' in its Concept
Hierarchy. For
example: 'Is it yellow?' 'Yes, it's a kind of banana color.'
'Banana' as a fruit includes 'fruit' in its Concept Hierarchy. For example:
'Do you have
any fruit?' "Yes I've got some bananas.'
The Concept Hierarchies are separate. The question 'Do you have any fruit?'
should
not get the kind of response 'would yellow be OK?'
Nothing prevents a single word having different meanings in more than one
Concept
Hierarchy. But if a single Concept Symbol appears to belong to more than one
hierarchy, this
is usually because the Concept S6ymbol is not really a Concept Symbol at all,
but still
contains two or more meanings.
The examples given earlier in this section are in fact working examples of how
this
method is applied.
Returning now to the example given earlier of the word 'fly'. The Concept
Language
expression of 'fly' when used in the sense of flying in a plane becomes, as
stated earlier, 'do
& move & travel & fly.
This is a unique assembly of Concept Symbols and demonstrates the point that
no
two Concept Hierarchy statements are identical.
However, 'fly' as used in this example: 'I've got to fly or I'll be late for
the appointment'
decompresses to 'do & move & (quality) fast'.
A fly - the insect - decompresses to 'Lifeform & insect & fly'.
This gives an example of how, in Concept Language, using decompression
techniques, three different meanings of the word 'fly' receive three
different, and unique sets
of Concept Symbols.
52
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
7) Devising Questions to Detect Lossy Compression arid heap create Concept
Hierarchies
Once the teaching is understood, it is does not require specialist knowledge
to devise
questions that show up examples of the Concept Hierarchy type of lossy
compression. As an
example of how to apply this method, consider the word 'chair' and apply the
questions of the
above method to it:
'Are there other similar concepts to 'chair'?
'Yes. 'Table' for example.'
'Are both of these covered by a word that expresses the concept of the group
to which they both belong?'
'Yes. The word 'furniture'.
Accordingly, a Functional Word hierarchy is established as follows:
'chair' = matter & manmade & furniture 8' chair
'table' = Matter & Manmade & furniture ~ table
When such a relationship has been recorded, one can imagine that it is not
difficult to
query a computer that has a record of office inventory, and ask "what
furniture is in room 43?'
and get back the answer 'Three Tables, two chairs, and a painting". if the
value was
recorded in the inventory, it can be imagined that software could be included
to provide the
answer to the question 'what did it all cost?'
8) De-Compression Method a - Word Coding Compressions.
Two final examples will now be given to demonstrate that language can be
treated as
a compressed transmission medium. The first of these examples describes
another single
word compression of a type termed: "Compression Coding'. These examples also
serve as
examples that relaying on grammar to obtain meaning is not a workable
solution.
The word 'printed' has a meaning: 'printed in the past'. In fact, the word
'printed
contains three entirely separate concepts.
'printed' _ 'Action (Energy)' & 'print' ~ 'past time' or 'completed'
This gives an example of double compression, or compression on compression.
The
first compression is the lossy compression:
Print - 'Action'& 'print'
The second compression, a coding compression, is the end-coding '-ed'. '-ed'
actually
codes a second concept into the word, a concept that can expressed as
'completed' or 'time
past'. This is itself a Compression, being properly tralsated into Concept
Language as "Time
& past time'
53
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
(Time Concept Heirarchies are withing' one another. Wednesday is 'within' 'a
week'.
Time is also a continuous stream - and this is represented in the Data
Relation Table, as a
Data Relation Table is a continuous record of all events).
The concept of 'print' is always 'print' and does not change, whether 'print'
is done in
the past, now or in the future or on the planet Mars. The concept of 'print'
does not change,
but the time of printing does change and this coded by the compression code
ending of the
word:
'printing' - 'do' & 'print' & in progress or 'time now'.
The three concepts in the one word are completely different concepts - one is
a
concept of any action, one is concept of a particular type of machine action,
and the last is a
concept of time.
ff the word 'printed' is treated as compressed, then it is clear that each of
concepts in
the word should be recorded individually. When recorded individually, they are
accessible
individually.
The usefulness of this can be seen in the following example of a conversation
between a person and a computer that understands, which shows that by treating
'print' as
compressed, it becomes relatively easy to make a computer react in a human way
using
nothing more complicated than normal database technology:
Person to Computer: 'Print this letter'
Computer Marks a database record with the order decompressed and expressed
in Concept Language 'do & print & schedule & letter"
The unique combination of 'do & print & schedule & letter'
matches a software condition that is also stated in the Data
Relation Table as 'do & print & schedule & printable item'. The
fact of the match causes execution of the matched software
module to occur - which, for example, sends the file to a print
module. The computer prints the fetter.
Changes the record from 'do & print & scheduled & letter' to 'do
& print & completed. & letter'.
Person to Computer: 'What have you done?
Computer: decompresses the query word 'done' to 'do & completed.'
Searches the database for 'do & x & completed'
Finds 'print & letter'
Looks up the human language compression for 'print 8'
completed' and finds 'printed'
Computer to person 'printed the letter.'
54
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
If the words 'print' and 'printed' compression are not treated as compressed,
then the
human query"what have you done?" will fail - the computer will not
'understand.'
Decompressing a word into individual concepts that are stated in a Concept
Language
in the Data Relation Table, is one method used to enable a computer to answer
questions
such as those in the above example.
9) De-Compression Method 5 - Base Concepts.
Consider the following 30 variations of a single word:
Invitation, invitingly, invitational, invitationally, invitee, inviter,
invite, invited, inviting,
invitationable, invitationableness, uninvite, uninviting, uninvitingly,
uninvitable,
0 univitableness, de-invite, de-invitational, re-invite, re-inviter, re-
invitee, re-invited, re-
inviting, dis-invited, de-inviting, non-invitingly, non-invitable, non-
invitableness, non-
invitably, unre-invitable, and so on.
The list is by no means complete; just adding plurals almost doubles it, and
using
combinations of suffixes and prefixes it is possible to make some 14,000+
variants of a single
word.. Some of these versions do not occur in even the most comprehensive
dictionary, but
can still be understood when used in conversation, where words are often used
that do not
occur in dictionaries.
The following example of an order to a secretary demonstrates the persistence
of the
Base Concept as used by people
Boss to secretary: 'send Joe an invitation to our party'
Boss to secretary at a later date: 'who have we invited to the party?'
Secretary to Boss: 'Joe, George....'
Hence, the words: 'invitation' and 'invited' are related in the mind of the
secretary. The
Base Concept, the basic idea conveyed by the word 'invite' is constant and
does not change
in any of the above examples. The 'invite' concept is always there, and no
matter what form
the word takes, all forms contain a Base Concept that is common to them all.
This fact of life
may be represented by giving the Base Concept a specific and invidiual Numbers
Concept
Language Number, as previously described. Consequently, the meaning that is
Base
Concept can be found, no matter in what word form it occurred.
Base Concepts can be related through their own Base Concept, Concept
Heirarchies,
stated in Data Relation Table records. Supposing the Base Concept of 'invite'
is symbolized
by the symbols 'Inuit'. The word "come" when used with a meaning as in the
following "please
come here" is similar to, but not the same as 'invite"
Hence, the word 'come' as an action, and 'invit' as an action, are both
actions, that are
requests to someone to change the space they are in, with 'invit' being more
formal than
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
'come'. Tus the Base Concepts can be related through a Base Concept Concept
Heirarchy,
stated in suitable Data Relation Table records, as follows:
Request & Action & Change Space & formal & invit
Request & Action & Change Spave & Informal & come
10) De-Compression Method 5 - Compression Codes.
The word beginnings such as 'un', 're', 'non', endings such as 'able'
'ableness' and so on are
considered by the to be compression codes of different types. Some codes are
function
codes such as 'able' as in 'invitable', which can be decompressed to:
'do & invite & possible
'invitingly' can be decompressed to 'do & invite & time now & quality'. '-ly'
is a
function code, coding the word as the quality of
an Action.
re-invited can be decompressed to 'do & invite & time past & repeat' 're-' is
a
function code, coding for the concept of word for
'repeat action'
re-invitedly can be decompressed to 'do & invite & time past & repeat &
quality'
Some compression codes for existence, for example the 'less' in
'invitationless' (as in
'Joe is invitationless.') is an existence code. The word decompresses to: 'do
& invite & not
exist.'
Thus a query 'has Joe been invited' decompresses to 'Joe & do & invite &
timepast?' If
this query is run against the recorded data of 'do & invite & not exist', the
true answer 'no' is
returned. But if keyword technology is used, querying for 'invit.' For
example, the wrong
answer of 'EXISTS = true' would be returned.
Compression Codes are used in the Languasge Processing code in the form of
rules.
In the case of '-ly' suffix, the rule is:
Word to which "ly" is added is a quality and applies to the nearest word of
action to be found.
Consider the following two examples:
"He looked invitingly at Jill" .
"invitingly, this last summer, over the green grass and brown bushes, he
looked at Jill."
Appplying the rule, as given above, will, in each case detect the work
'invitingly'
as being a the quality of the action of looking and enable the Concept to be
correctly recorded
as a Quality (rather than as a thing or as an action) in the Data Relation
Table.
56
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Due to the presence of the Number Concept Language number for the Base
Concept of 'invite', in both the above examples, a computer query " Did he
invite Jill? Will
return the answer of "true" or 'yes".
Since the Base Concept of 'Inuit' contains the concept of Action, (see
description of Base Concept Concept Heirarchy given above), a query "what did
he do?" will
return "invited Jill". If further queries "how do you know that?" the answer
will be returned "he
looked at her invitingly."
11 ) De-Compression Method 5 - Word Position Coding.
In some types of compression, the coding is not or attached to the word itself
- i.e.
the word is coded by different types of codes that are found elsewhere in the
text that in the
word itself.
The simplest of these is Position Compression Coding. Consider these two
sentences.
Stop I like this
I like this stop.
In the first sentence, the word 'stop' is an order. In the second, the word
'stop' is a
location. All other words in these two examples are the same, and in the same
order. The
meaning of 'stop' to be used is coded by the position of the word itself.
If the first of the two examples was written down, it would probably appear
as: 'Stop, 1
like this.' or 'Stop. t like this.' But when spoken, there is no comma or
period - the words 'stop
1 like this' can be run into one another and spoken as stream without pause
between words
and yet, none of the meaning is lost. Hence, the meaning of the word 'stop' is
not at all
conveyed by the punctuation. In this instance, it is conveyed by the position
of the word and
this can be expressed as a Position De-compression rule applying to that word:
Every word
has a variety of de-compression rules that it obeys, and the meaning of the
word can be
determined by the de-compression rules applying to that particular word. The
de-
compression rules that need to be applied to a word are detected by empirical
observation
and testing of the use of the word by humans.
As an example of the application of this method to the above two examples,
shows
that two de-compression rules exist (and they are not the only ones) applying
to the word
'stop' (the following are simplified forms of the rule, just to show the
general principle:
Rule 1; If 1 ) 'stop' is the first, or 2) 'stop' is the only word and 3) if it
is part of an order
addressed to the computer, then (it is an order to stop the current action) de-
compress to:
Computer & do & stop & time = now & current action. (The omission of the
name of the person addressed - or in this example, the name of the computer
57
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
addressed is a lossy compression contined in the word "stop' when used as a
first word)
Rufe 2: If 1 ) 'stop' is the last word in a Statement, but 2) not the only
word, and if 3) it
is part of an order addressed to the computer, theri (the word is a location
reference) de-compress to:
Current location & Statement, begin new Statement.
The rules used to determine which meaning of a word applies are named"Concept
De-compression Rules may a used to enable a computer to determine which
meaning to
apply and hence, which Concept Symbol to assign to a given word.
The effect of this method is that it enables software to translate a word with
more than
one meaning, into a Concept language expression that has only one meaning
Almost every word has a variety of de-compression rules that it obeys. These
rules
are not just Position Compression Rules. Other types of rules also exist such
as Associated
Concept Compression Rules. In the examples 'can you stop this?' while 'stop'
is an action,
the person has not ordered something to be stopped. The query is a query for
the ability to
stop the current action, and should returns a 'yes' or 'no.' Concept De-
compression Rules
interact with one another as shown by the following example using some of the
Concept De-
compression Rules for the words 'Can you stop this?':
Pseudocode examples of rules:
can. if: this word is addressed to the computer and 2) if it is the first word
Then: the concept s that follow are a query.' Decompress to
Set Statement to 'query', word to 'do & able & next action concept that
follows'
you If: This word is addressed to the computer
Then: the Statement addressee = this computer.
Stop If Statement contains reference to computer, and 2) if package is query
Then: Activate 'Stopcheck' software Module.
This If: Statement is an order to the computer
Then = current or most recent matter item
In effect, when meanings are analyzed in this manner, many more meanings exist
than are found in even the largest dictionary, and when stated as an order to
a computer,
meanings exist that are not in any dictionary. In general, dictionaries give
types of meanings,
but do not include typical precision variations. It is clear that state of the
art dictionaries and
dictionary technology are helpful in creating a Concept Language, but are
inadequate as a
source for all meanings with adequate precision to create a Concept Language
that can be
used to control a computer.
58
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Hence one method to find all relevant meanings of a word is to obtain many
samples
of the use of the word, and analyze these following the methods being
described.
As the above example shows, the meaning of a word in Concept Language does not
necessarily have to be represented ONLY by a Concept Symbol, but can be
represented by
the action performed by a rule, or by a Concept Symbol or Symbols, or a
combination of any
of these.
When a rule is present, for a meaning of a Oword, then, that rule is
represented in the
computer as code to implement the rule.
Notes:
1. Note that the fact that the Statement in the above example is a query -
which
is coded by the position of the word 'can' - changes the meaning of 'stop'
that
is to be used. In this case the fact that the Statement is a query results in
the
word 'stop' following a third rule in addition to the previous two rules that
were
listed. It also results in 'stop' having a completely different meaning to the
previously mentioned meanings.
2. Note that, out of the many ways that one could address a computer - for
example by name - all of them will appear in the Concept Language translation
as a Concept Symbol that represents the one meaning: 'this computer'
3. Note that for a computer to be able to do any action whatsoever, a software
module should exist that is able to actually do that action and that single
action
only. In one fo the above examples, a software module called 'Stopcheck' is
called, whose function would be to check if 'item X' can be stopped. The fact
that a user does not ever go through any complex chain of events to order
what he wants to do, dictates the underlying software construction. Moduies to
perform specific actions such as the 'Stopcheck' example, can not require
opening a mufti-megabyte software package, but should be instantly and
quickly accessible, execute, and terminate. (The non-hierarchical manner in
which Software Modules are record in the Data Relation Table allows this).
12) De-Compression Method 6 - Relative Proximity Compression Coding - Enabling
a
Computer to Determine from the Context which Meaning of a word to applies.
Relative Proximity Compression Coding decompression enables a computer to
determine the meaning of a word to be used based on contexts. Where a great
distance in
terms of number of words separates the word in question and the words that
code its
meaning requires creating the rule in a suitable fashion to account for this.
Where a word
meaning can be changed by context - the word 'roam' for example - suitable
Encironment
Concept Coding Decompression Rules determine whether the subject under
discussion is
59
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
telephone or people and hence which meaning is in use, and hence, which
Concept Symbol
to assign.
Remembering that it is human data handling that is being copied, the method
that
enables a computer to determine from the context which meaning to use is:
Determine from examples of actual use of the word, the factors in the context
that a
human uses to determine the choice of meaning to be used for the word in
question,
and express these factors as rules that a computer can process.
Taking the example of the word 'roam', this is a word that has essentially one
meaning
- a default meaning in computer terms of : 'do & move & roam' (roam is a
manner of moving).
This default meaning applies under all circumstances except when telephones
are
concerned, where it has a special meaning that can be paraphrased as 'a mobile
phone
connected to a network outside its normal service area'. For clarity, the
second, telephone
definition will be referred to with the symbol 'roam-t' in the following.
To illustrate this method the following quote from a popular magazine text is
used as
an example: 'Last year the company shocked the wireless world when it
announced its so
called Digital One Rate plan - a cellular phone offering that eliminated long
distance and
roaming charges'.
Applying the above method and asking the question: 'what facts in the context
determine the choice of meaning?' gives the answer that the meaning to use is
determined by
the presence or absence of the concept of 'cellular phone' closer to the word
'roam' than any
other concept that could take the word 'roam.'
Supposing that the above example was re-written 'a cellular phone offering
that
eliminated tong distance and dog roaming charges'. It would then be clear that
'roaming'
applies to dogs, not telephones and that, for some reason, dogs are being
charged for
roaming around the countryside as part of a cellular phone charging scheme.
This
demonstrates that it one of the factors that can decide the meaning of a word
to be used is
the relative proximity of the word in question to other words can determine
the meaning to
use. This type of Compression is termed 'Relative Proximity Compression"
Now following the remaining step of the method above, and expressing the
Relative
Proximity Compression as a rule, gives rise to the following Concept
Decompression Rule:
If The Concept 'telephone & mobile' is closer to 'roam' than Concept symbol
for
any other thing that has the capacity to move,
Then roam = 'Action & Move & Roam & (type of roam) Taelephone '
Else 'roam' _ 'do & move & roam'.
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Other examples would show that this is not the only Concept Decompression Rule
that
governs the meaning of the word 'roam' to be used - in fact there are several
such rules for
this word alone.
13) De-Compression Method 6 Enabling a Computer to Detect the Meaning of
groups of
words. Compression Operator Words.
Words exist in groups such as phrases arid sentences. Some words do not
require to
be recorded as their meanings - ore more accurately, their effect on
surrounding words is
that of a word that operates on other words to select the meaning in use.
Hence the Concept
De-compression Rules of Concept Language use such words to determine which
meaning to
select. Words of this type are termed 'Compression Operator Words'
'Compression Operator Words' are defined as 'words that, while they may also
have
a meaning, are also code words that carry information selecting or affecting
the meaning of
other words or groups of words.
As an example of a Compression Operator, consider the following statement:
'I wanted to go to town'
'I wanted to go to town' is a not necessarily a complete Statement in itself.
It may be
complete, but it is not necessarily complete. While it can make sense just by
itself, the
person who hears it spoken does not know it is complete, unless something else
happens.
For example, the speaker could have continued 'I want to go to town with Joe.'
Or 'I want to
go to town quickly.'
Supposing the speaker had continued 'I want to go to town, and buy a banana'
the
word 'and' can be considered a compression operator that performs several
functions:
- 'and' compression codes that the previous concept package is complete, thus
avoiding the necessity for a 'concept complete' statement (such as saying "I
want
to go to town comma'. In the absence of the word 'and', the speaker could have
continued 'I want to go to town quickly in the morning' in which case, the
first part
of the statement 'I want to do to town' was definitely not complete. 'The word
'and'
tells the listener 'that part of the statement is complete, new part follows.'
- 'and' compression codes that a new concept package is beginning, thus
avoiding
the necessity for a 'new concept start' statement.
- The meaning of the word 'and' in this instance is that the concept package
now
starting is related to the ended concept package. (In fact, 'and' has other
meanings also).
Effectively, the word is a compression operator - it codes concept package end
and
concept package beginning without using any additional symbol to do so.
But the word 'and' also performs a second compression operation.
61
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
'I want to go to town, and buy a banana', decompresses to:
"I want to go to town"
"I want to buy a banana"
The rules that are part of the activity of Operator Words are implemented in
the form
of code that is called when the word is detected, and the code itself performs
the
decompression operation.
For example, the language processor, finding the word "AND" calls code that
does
the following:
Set statement before 'and' to complete.
Copy previous statement and record together with following.
14) Enabling a Computer to Detect the Meaning of Words by Enabling the
Computer to
Replace the Functions of Punctuation.
Sometimes more than one Compression Operator is operating at the same time on
the
same word. At the same time the majority of punctuation that exists in the
written word does
not exist in the spoken word. Hence, the information that is conveyed by
punctuation in the
written word is conveyed or coded in another manner in the spoken word.
Imagining that
most computer corrimands may eventually be verbal, the Any-to-Any machine
therefore
includes methods elaborate De-Compression Rules that can substitute for the
information
conveyed by punctuation and used to determine the correct word meaning to use.
A speaker may begin by saying: 'The dogs...'
In the spoken word 'apostrophe s' does riot exist. The sound made by the
speaker is
identical whether the speaker continues:
a) 'The dog's collar is red.' or
b) 'The dogs running to the beach' or
c) 'The dogs are running to the beach.'
In fact the speaker will say all of these examples without any 'apostrophe s'
included in
the mouth sounds so that when heard, they sound as follows:
a) 'The dogs collar is red.'
b) The dogs running to the beach'
c) 'The dogs are running to the beach'.
But despite the absence of any 'apostrophe s', the listener still knows that
in (a) it is
one dog, in (c) it is more than one dog, and in (b) it is still unknown
whether it is one or more
dog because the speaker could continue:
'The dogs running to the beach and will probably sniff that banana,'
- in which case it is one dog, or it could continue:
'The dogs running to the beach will all probably sniff that that banana'
62
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
in which case it is more than one dog.
These examples show that a trailing 's' as a suffix on a word is an example of
a single symbol
with three alternate meanings:
1 ) In example (a) 'The dogs collar is red', the trailing 's' states that the
concept that
follows belongs to the previous concept. The 's' is operating as a Concept
Compression Operator, as the single concept letter 's' in fact is a short,
i.e.
compressed, way of saying 'the next belong to the previous.'
2) In example (c) 'The dogs are running to the beach', the trailing 's' states
that the
concept symbol to which the 's' is attached is more than one. In this instance
the
1 p single Concept Symbol 's' is operating as a Concept Compression Operator
and is a
short - compressed - way of stating 'the concept of the word to which this is
attached
is more than one."
3) fn example (c) 'The dogs running to the beach' two alternate possibilities
exist, either:-
It is one dog and this dog is running to the beach, or
The dog quantity is 2+.
Which of these meanings of 's' as a suffix it is, is not coded in the phrase
'The dogs
running to the beach' but elsewhere. !f the word 'and' followed, dog would be
singular, and
the trailing 's' performs the function of '_, time now': the dog =time now,
running to the beach.
if the word 'are' followed, dog would be plural - 2+, and the trailing 's' has
the function
quantity = 2+: 'dog, quantity 2+, running to the beach.'
The function performed by 's' is completely and totally different in these
three
examples, and the trailing 's' is a single symbol with three possible
'meanings'. In fact, the
three possibilities for a trailing 's' comprise two different types of
compression. In one of
these examples - 'the dogs running to the beach are' - the trailing 's' is a
Own Word
Compressor Symbol- it operates on the word it is attached to and adds a
separate concept of
'quantity of 2+' to the word it is attached to.
In the other examples, the trailing 's' does not operate on the word it is
attached to but
on surrounding words - 'the dog's collar is red' - the trailing 's' operates
on the word 'collar'.
It is then acting as a Compression Operator, in that it is a compression that
operates on or
has an effect on a word or words other than the word to which it is attached.
When a trailing 's' is translated into Concept Language, these three different
meanings should be assigned to either to:
1 ) Three different operations - processes to be used as rules operating on
the
translation to Concept language of the surrounding text - or to
2) Three different Concept Symbols, or to
63
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
3) A combination of these - such that each different meaning of the trailing
's' is
handled in a different manner.
Distinguishing between the three possibilities is done in this Any-to-Any
machine by
the use of Concept De-compression Rules: However, the coding for which of its
three
possible functions a trailing 's' is performing is not contained in the
Compression Operator 's'
itself but is coded elsewhere.
Consider this example:
"The dogs are...' the addition of the word 'are' codes the 's', effectively
selecting the 's'
function that sets the quantity of the previous concept to 2&
The word 'are' is performing the following Compression Operator functions:
1 ) Set value of any previous trailing 's' to it 'quantity = 2+' function.
2) End previous Statement
3) Set following Statement to quality of previous concept package.
It could be viewed that the function of 'are' is redundant, and 'are' itself
sets the
previous concept to plural. However, this is not so, as shown in the following
examples,
where 'are'. does not set the previous concept to plural by itself - it
requires the trailing 's' as
well to do so- the previous concept can equally well be singular or plural. In
the following
examples they are written as they might be said (as opposed to how they might
be written,
which is shown in brackets afterwards):
The dogs are you going to get the dogs? ('The dogs! Are you going to get the
dogs?')
The dog are you going to get the dog? ('The dog! Are you going to get the
dog?')
The 'dog' concept preceding 'are' can be either singular or plural, hence the
word are .
In these examples, there is not necessarily a spoken pause or any other
indication
that the "the dog' is a complete concept, yet it is still clear, when heard,
that it is complete.
Neither the trailing 's', nor the word 'are' are redundant, each of them
performs a function.
Note the difference between grammar (where 'and' and 'are' are words with no
similar
features at all) and Concept Language where the two words, perform similar
functions.
(In fact a trailing 's' when it labeled a 'plural' form of a word even as a
plural can code
the quantity of the thing labeled by the word in one of three ways:
i) Trailing 's' can code for all of something: 'dogs are nice animals'
ii) It can code as 2+: 'The dogs.are running to the beach.' (obviously this is
not 'all
dogs everywhere are running to the beach.' So in this case, 's' = more than
two and less than all.
64
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
iii) It can code as 'all of a group': 'the invitees are coming at 8 o'clock'.
In this
case, it does not code for 'all invitees everywhere, but 'all of those who
have
been invited in this instance.')
15) Enabling a Computer to De-compress Component Concepts. Structural
Compression
Coding
Consider the sentence, taken from a popular magazine:
'Investment Banker Joe Blow's old and new office are two miles - and several
worlds
apart.' -
This sentence is in fact quite compressed and requires complex rules to
clearly extract
0 the meanings from it as it stands. However, the sentence can be de-
compressed into its
component facts as follows:
Joe Blow is an investment banker
Joe Blow has an old office.
Joe Blow has a new office
15 The distance between the old office and the new office is two miles
The distance between the old and new office is several worlds.
The above 'simple' sentences are similar to the manner in which a child speaks
when
(earning to use the language. That the example text is compression is
indicated by the fact
that the original sentence required 16 words but the decompressed sentences
require 42, a
20 compression ratio of 2.6:1. Note that, once the sentence is decompressed,
translating it into
Concept Language is relatively simple and then recording it in some type of
database - once
all other de-compressions are completed - is more straightforward than
attempting to record
and create correct relationships amongst the original data. If the
decompressed, Concept
Language text is recorded in a suitable database, then it can be envisaged
that a computer
25 would be enabled to answer such as 'What does Joe have?' and receive a
query return such
as 'an old office, a new office'.
16) Enabling a computer to tell Sense from Non-sense, & Decompressing
Structural
Compressions.
The same Any-to-Any machine method that enables a computer to Decompress
30 Structural Compression is also the method that solves the following
requirement for an
Understanding Computer.
Obviously, a Computer that Understands should not attempt to execute nonsense
orders such as 'e-mail the modem to the printer.' More seriously, if the
conditions for an
execution are not fulfilled, an Understanding Computer should be enabled to
detect what
35 conditions are missing and take appropriate steps - such as issuing an
appropriate user
prompt to get the conditions completed so that execution can occur. However,
before a
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
computer can be enabled to do this, it should be first enabled to be able to
detect when the
user considers that what he has said - the order he has given - is complete.
When he has, in
some manner, indicated his order is complete, then it can be tested to see if
it is executable.
A method of the Any-to-Any machine termed a "Complete Statement' is used to
determine when an order is complete. This method is explained in more detail
in the Detailed
Description, but is based on the fact that every word has certain
requirements, in order for it
to 'make sense'. A person's name alone and totally unassociated with any other
data does
not 'make sense'. If someone walked up to another person and said 'Joe Brown'
and walked
away again, the other person would be left wondering 'What did he mean? It
doesn't make
sense. He walked up and said "Joe Brown and walked away again. What did he
mean by
that?' Thus if a person's name is stated 'Joe Brown' the name has a
requirement - namely
that Joe Brown should then be stated to Be something, Do something, or Have
something.
'Joe Brown is a good guy.' 'Have you seen Joe Brown?' etc. Similarly the word
'see' has a
requirement - namely that someone sees something.
Reading the following examples shows that, at a certain point, they 'make
sense' - i.e.
the words so far said become complete and are not missing anything in order to
'make
sense'. To the right of line word, is a simplistic statement in the terms of
the method of the
Any-to-Any machine, of the requirement of the most recent word received:
'I 'I' requires something about 'I'
'I will 'will' satisfies 'I' requirement but 'will' itself requires an Action
"I will go 'go' satisfies 'will' requirement but 'go' itself now requires an
Action or a
Location
'I will go to 'to' selects the Location meaning of 'go' hence location now
required.
'I will go to town 'town' satisfied 'will' and 'go' but requires something
about 'town'
- satisfied by 'to'
t will go to town and All requirements of words so far received prior to 'and'
have.
been met by the words in the statement. Hence, the
previous statement is complete, new statement begins.
The method of the Any-to-Any machine takes advantage of this phenomenon of
human data handling, and states a word's requirements in a fashion that
enables them to
tested by software. It does this by stating - in essence - that each word has
Requirement
Rules, and that a Statement is a Complete Statement when all Requirement Rules
of the
words so far stated have been met by the words used. If Requirement Rules are
not met by
the time a word's rules state that a new statement is beginning, the previous
Statement is 'not
sense' (i.e, is incomplete) and should be queried.
66
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
For example, 'and' in the Any-to-Any machine is classed as a Operator Word and
one
of its operations is - in the particular case of the above example - is to
state that the previous
Statement is complete. If the person in the above example had said:
'I will go to and'
these words do not 'make sense' and prompt the query "you will go to where??
The
requirement for a Location has not been satisfied, although 'and' operates to
state the words
so far received are complete. In the method of the Any-to-Any machine,
associated software
receives 'statement complete because of the rule activated by the word 'and'.
However, the
Requirement Rules are not satisfied, and hence, software treats the words so
far received as
incomplete. Software can identify the missing data as a Location and can now
query for the
missing location: 'you will go where??'
The above is an example from the more difficult domain of testing the sense of
general text entry. However, the same Any-to-Any machine method applies in the
simpler
domain of computer control. In the Any-to-Any machine method the Requirement
Rule of the
word 'print' requires something to print. If the user issues a command 'Hey
computer, I want
printed OK?' The requirement of the word'print' to have an identified item to
print is not met
by the words received that the user has stated he considers complete by using
the word 'OK'.
The Statement is incomplete and the part that is incomplete is the Requirement
Rule of 'print'
for something to print. Hence software can issue the query 'What do you want
printed?'
This method of the Any-to-Any machine enables a computer to detect when it has
received words that do not 'make sense' in human terms and also enables a
computer to
detect why it does not 'make sense'. The fact that the computer can detect
what it is about
the words received that do not 'make sense' enables the computer to take
appropriate
corrective action. (This method does not enable a computer to have
'judgement'. It simply
enables a computer to copy the way a human handles the words).
Part of the method of the associated software is that all computer peripherals
have
recorded in Concept language format the things they can and can not do, using
the "Able"
field or record type in the Data Relation Table. Thus, in the nonsense example
given at the
beginning 'e-mail the modem to the printer' the modem would have recorded that
it can send
things, but can not be sent anywhere by the computer, and this would lead to
the request
being queried.
The addition benefit of the Complete Statement method, colloquially speaking,
is that
it can be used to cut Structurally Compressed text - such as the example given
previously
concerning Joe Blow - into its component Statements. This is done using a
combination of
Concept De-compression Rules and Complete Statement detection.
67
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Concept De-compression Rules de-compress the words one by one by looking up
their Concept Language Translation and entering the Concept Language
Translation into 'the
the database, together with the Complete Statement Rules of the next de-
compressed words.
As soon as a decompressed, Concept Language word is entered that results in
all Complete
Statement Rules so far entered being satisfied, that Statement is labeled as
complete and
sent on to the associated Execution software for further processing. The next
statement is
then processed similarly. Hence, the effect of the Concept De-compression
Rules and the
Complete Statement method used together, enables a computer to De-compress
Structural
Compression into component statements, such as those listed above as the
decompression
of the magazine text.
17) Enabling a Computer to Learn New Meanings.
An Understanding Computer requires the ability to learn new words and also new
meanings. Probabilities are not a useful solution in enabling a computer to
handle new words
or meanings. While calculation of probabilities will show for example, that
'roam' is most
usually concerned with people, any use of that probability to determine the
meaning will be
wrong in circumstances where a human would be right, and as such any computer
'understanding' will be limited at best.
A human rarely uses probabilities in determining a word meaning and then only
when
there is no other way. Even so, if the execution is desirable, he will rarely
execute based on a
probability. A human prefers to query the uncertainty and attempt to clarify
it (or if that is not
possible, not to act at all).
The Complete Statement method has the additional benefit of enabling one of
the steps
required for a computer to lean.
Firstly, learning obviously can not occur in the absence of memory.
18)The Nature of Memory Requirement for Learning to Occur
A person's first question on encountering a new object, is invariably 'what
does it do?' or an
alternative phrasing such as 'what is that thing for?' - the first thing the
person wants to know
is what are the capacities of the object. Imagine a child asking: 'What is
that daddy?' 'That a
saw, Johnny.' 'What's it for?' 'It's for cutting wood, Johnny.' The child
stores this data for
subsequent use. In computer terms he has defined a relationship:
Saw (the object) - tool & cut & wood
In the method of the Any-to-Any machine, this relationship would also be
stored and the
Requirement Rule for the word 'saw' with this meaning would be recorded as
'object, type
wood'.
68
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Later the child may hear "I'm going to cut this metal with a saw.' Johnny is
likely to come out
with 'You can't, saws cut wood." To which his father will reply "I can,
because saws can cut
metal too.'
In the Complete Statement method of the Any-to-Any machine the statement: 'I
am going to
cut this metal with a saw', the Requirement Rule for saw (i.e. a wooden
object') is not met
and hence, leads to a query, just as the child queries his father. The query
might be of the
nature 'Can saws cut metal?'
The user will give the computer a reply, just as the father gives Johnny a
reply: 'yes'
Johnny sets up a new relationship:
Saw (the object} - tool & cut ~ metal
The associated software records the new relationship also.
The first requirement for learning is that previous known data is recorded.
The recording of
Requirement Rules satisfies this necessity. The second requirement is to be
aware that there
is something to learn. The Complete Statement method, by detecting things that
'do not
make sense' detects that there is something to learn, and this something is
either an error in
data so far received, or new data unknown to the computer. The Complete
Statement
method enables the computer to alert the user to the fact that the data it has
received 'does
not make sense', and why. The user, just as he does in life, with other
people, will supply the
correction or the missing data.
The following illustrates this further in a business environment using the
word 'roam'. The
computer may have recorded only one meaning for 'roam' as 'aimless movement'.
The
Concept Statement exists (is recorded} for the word 'roam' as:
Roam - do & move & aimless
Now supposing that the Concept Language Statement for the abilities of a
telephone
includes:
Telephone & move & unassisted & negative possible
Telephone & move & assisted & possible
The computer receives the statement "my telephone is roaming'. Part of the
Requirement
Rule for 'roaming' will be that it requires an object that is capable of
moving unassisted, but
the telephone is recorded as only being able to move when assisted. The user's
statement is
not a Complete Statement because the Requirement Rule for the word 'roam' is
not satisfied.
Hence the Complete Statement method enables a computer to detect when a
received
statement is incorrect, or when existing definitions are incorrect or missing
further word
meanings.
The fact of this detection enables software routines to issue a query such as
'Can telephone's
roam?'
69
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The user will reply 'yes'
Further routines that are the province of associated software can revise the
definitions
of 'telephone' and 'roam'. ft can also be envisaged that software can be
created that, when
supplied with sufficient texts, can detect unaided and also record the
Associated Concept
Compression De-compression Rule for detecting the that the telephone meaning
of 'roam' is
in use.
19) Additional Requirements for Associated Software
A child, or a person learning a new language, takes a considerable time to do
so; in
the light of the Any-to-Any machine, what a child is actually doing, in
addition to learning
words it to learn compression rules and protocols by example (Grammar is
essentially a
protocol). A human in fact computes extremely quickly. A simple activity such
as driving
requires the simultaneous computation of a considerable number trajectories of
objects many
of which are moving; at the same time the human can talk, also requiring
computation. An
understanding computer is required to emulate human handling of data and as
this summary
shows, a considerable number of rules are required to do so, and it is
axiomatic that
considerable computing power is required in order to process a large number of
rules rapidly.
However, 1 ) most general use computer CPUs are idle 99% of the time and 2) A
human's
orders at any one time consists of only a relatively small number of words.
Hence his order
can be processed as it is being input, as there is no requirement in Concept
Language to
have received all words before processing the first word received. Hence the
users words
can be processed as he continues to say the order, so that by the time he has
finished saying
an order, the processing on it can be already complete. Hence the computing
power required
is realistic. Finally, it is fast for a user to say or type what he wants,
than it is for him to hunt
through menus to find the right icon.
Processing all text into Concept Language may require considerable processing
time.
A desirable aspect of the associated software using the Concept Language is
that - in order
to act in a human manner - it needs to be able to lay a task aside and pick it
up later, and
suiteable scheduling modules can do this. Hence the associated software needs
to be able to
lay aside processing a text into Concept Language and complete it at a later
time. In the
state of the art, most general-purpose computer processors are idle 99% of the
time. Text is
seldom required again immediately after it is entered. Therefore, the software
using the
Concept Language can utilize the ability to lay aside tasks and processor time
that is not used
in the state of the art, to process text into Concept Language format without
irritating the user
with delays on more urgent tasks.
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Additionally, it is clear that the software that implements a Concept language
should
be adapted to the easy addition and change of rules (The Data RElation Table
is so
adaptable).
A language changes over time. A single computer can hardly be pre-loaded with
all
knowledge there is on everything, and hence every computer that understands
should have
the capacity to learn. However a 'capacity to learn' is not something
nebulous, but simply a
capacity to record new word definitions and new rules in memory, and use the
new rules,
together with the pre-existing rules, and pre-existing data', for future
computation.
A computer that understands is effectively a computer that copies human
methods of
data handling. Therefore, human methods for handling data should be observed
before they
can be copied, Human methods for handling data can be implemented in a
computer if
language is treated as a lossy, multiple compression data transmission system.
Language
can further be treated as a system in which the De-compression required is
entirely rule-
based, and the inter-acting complex of De-compression rules apply to each
different word, as
15- well as to blocks of words. The first objective of decompression
procedures is that each
unique meaning is related to a unique symbol or a unique combination of unique
symbols.
The unique symbol or combination of symbols can then be related to a unique
execution, and
hence, the unique execution is related to a unique meaning. The first
requirement in order to
begin decompression is the creation of a Concept Language, in which each
symbol is unique
and has a unique meaning associated with it. The second objecYof decompression
is that the
decompressed form of the word enables software to maintain the same
relationships between
words that a human maintains. Decompression rules have as their object
enabling software
to copy human data handling and are therefore detected and isolated by simple
empirical
observation of the way humans use each word under a selection of different
circumstances.
When doing this, punctuation that is not evident in the spoken word should be
ignored.
Provided that all compressions are first removed from the language, the
resulting Concept
Language statements can be then recorded in such a manner that each unique
execution to
be done by the software can be related to its own unique statement. Once that
is the case,
the computer can be ordered in Normal Language. Whether or not the computer
can then
perform the ordered execution depends on whether or not a unit of software -
called a
Software Module' - exists to perform the execution that was ordered.
The process of de-compressing a language is itself an execution procedure and
has
certain specific memory requirements for the associated software system. For
the purposes
of the Any-to-Any machine, two types of memory can be considered to exist:
~ 'Content Related Memory' is defined as memory to do with the content of a
thing. An example applying to a computer would be the content of a letter or a
book - the
71
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
actual text: An example applying to a person could be the exact wording of the
exact
phrase he spoke at 9.31 am 613 days ago, or what he had for dinner 1129 days
previously.
~ 'Execution Related Memory' is defined as memory that is able to be
associated
with execution. An example in the case of human would be that he remembers
that 'he
telephoned Joe last week about the banana shipment'. He remembers that plate
glass
windows should not be walked through. (Words italicized to emphasize the
execution-
related aspect of the memory). These memories are execution-related. (A human
does
also have Content Related Memory).
Computers have fantastic Content Related Memory. if a computer has had
recorded
on its disks the entire Library of Congress it can return every single word,
in the correct
sequence without a single comma out of place. However, humans have
comparatively poor
Content Related Memory. It is rare that a person can recall what he said at
9.31 am 613 days
ago, or recall what he had for dinner 1219 days previously.
A human's Execution Related Memory on the other hand, is excellent. He knows
Joe
called last week, and he knows that if there is a plate glass window and he
walks through it,
he will probably damage himself.
However, in the state of the art, it is difficult to find examples of computer
Execution
Related Memory- at best, such facilities are extremely limited. Software does
not remember
it printed a certain letter last week, but a human does remember that.
Software does not
remember that if this is on the screen and that is on the screen also, then
you like this to be
over there, and that to be over here. About the only Execution Related memory
there is, is to
be found in scheduling programs that schedule backups or similar actions, and
computer
clocks that remember when it is summer time. However, unlike Content Related
memory,
which is more or less accessible to the user, the limited Execution Related
Memory facilities
that exist, tend to be buried deep inside software and difficult or difficult
of access. They are
certainly wholly inadequate for the processing of language and resulting
execution
requirements.
As the de-compression examples show, de-compression of language requires
Execution Related Memory, and can not be performed properly if such memory is
not easily
accessible.
Because of the absence of Execution Related Memory in state of the art
software,
software such as the Data RElation Table is required to provide unlimited
quantities of both
Content Related and Execution Related Memory. This is desirable both to
execute the
language conversion to Concept Language, and to elaborate and test all the de-
compression
rules that interact in the process of de-compressing a language into a Concept
Language.
72
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
A further requirement for de-compressing a language is the ability to easily
state and
modify the de-compression rules, and again, this is close to difficult with
state of the art
software, where rules are inaccessibly interspersed in globular multi-megabyte
software
masses. Further, Language is not static but a dynamic transmission medium that
changes
over time, hence it is also desirable that the software system that implements
these rules,
allows them to be modified or added to by the user, without programmer
intervention being
required. State of the art software generally does not have a place where
rules such as: 'if
this, then do that' can be stated, and the Data RElation Table also addresses
these problems.
The final benefit is that using this Any-to-Any machine, the user no longer
should learn
the computer. Instead, the computer learns him.
The three principal objectives to be achieved when creating a Concept Language
are:
1 ) Each Concept Symbol composing the Concept Language may
have only one meaning,
2) Each individual meaning that can exist in the spoken language
to be translated into Concept Language are represented by only by one unique
Concept Symbol or by only one Concept Symbol combination in the Concept
Language.
3) Concepts expressed in the Concept Language are related to
one another in the same manner that a human relates those concepts, or can
be so related by associated software.
Once a Concept Language exists, and the rules for translating between it and
one
spoken language - such as English - also exist, then the Any-to-Any machines
can use it to
make two different levels of an 'Understanding Computer':
1 ) Concept Language can be used to control the functioning of a
computer based onm a user's Normal Language input. While total control of the
computer with Natural Language is then possible, this does necessarily mean
that
the computer can answer questions on the data it contains. Content - such as
the
content of a fetter or a book - can still be recorded in the computer in
Normal
Language - the same manner it is recorded today. Under these circumstances,
the computer can be ordered in Normal Language to perform any manipulation of
which the computer's software is capable, and will do this successfully. But
it will
not be able to answer questions on content recorded in Normal Language.
2) In addition to the above, the further application of this Any-to-Any
machine is to translate all data entered into the computer into Concept
Language
before recording it - for example, all documents, all letters, all reports,
all
73
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
spreadsheets, and all data base contents etc. In this case, the Any-to-Any
machine enables a computer to answer questions on the data it contains. For
example, if all a company's information was stored in Concept Language format
in
the above manner, the computer could correctly answer queries concerning the
recorded content, such as: 'Give me a list of customers who contacted us in
the
last six weeks wanting better service'.
Business today is becoming increasingly international and is not conducted
only in
English.. Additionally the Internet contains useful information in many
languages. One of the
benefits of the Any-to-Any machine, is that, when several or many spoken
languages are
translated into one single common Concept Language, then any data entered into
the
computer in any one of those spoken languages can be accessed and used in any
of the
other spoken languages that have a Concept Language translation. This also
results in the
additional benefit that orders given to a computer in one spoken language will
be
comprehensible to the computer even if that computer's normal users normally
operate it
using another language - this effectively enabling a computer to be multi-
lingual. A final
benefit is that if adequate processing power is available, real-time computer
translation from
one spoken language to another can be enabled.
However, working out the translation of any one spoken language into a common
Concept Language, requires a detailed knowledge of the language of the
language to be
translated, and no one person can know several languages with adequate
understanding.
This desirable and beneficial requirement - to translate from any spoken
language into a
common Concept Language - requires that the Any-to-Any machine should be
described in
such a manner as to impart sufficient knowledge to others to enable them to
translate
languages other than English into a Concept Language.
In this Any-to-Any machine; the conversion of a spoken language into a Concept
Language becomes a mechanical process, governed by rules that can be executed
manually
or automated in software. Each spoken language requires the Any-to-Any
machine's
methods to be applied in a different manner to convert that spoken language
into a given
Concept Language. Each spoken language requires the Any-to-Any machine's
methods to
be applied in a different manner to convert a Concept Language into that
particular spoken
. language. Conversions between the English language and a Concept Language
that are
devised per the Any-to-Any machine's methods will not all work for another
language, which
will require other conversions to be devised using the Any-to-Any machine's
methods. For
example, in the French language, most names of things have a sex assigned to
them, and
that sex is often coded by a nearby word and not by the word itself, while in
English, sex
coding of words is relatively rare. Thus the French Language will need to use
the Any-to-Any
74
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
machines methods to devise a suitable system for that language to treat the
subject of the
sex of the words in the language. Similarly, the German language frequently
adds together
words (and hence their associated meanings) to create a new word that requires
several
English words to express: Hence the conversion processes themselves (but not
the Any-to-
Any machine's methods used to devise them) between the French or German
languages and
a Concept Language will be quite different to the conversion process between
the English
spoken language and a Concept Language. Each spoken language requires its own
Concept
Language methods..
Creating the procedures to convert a specific spoken language into a Concept
Language requires a profound understanding of the meanings of the words in the
spoken
language concerned. No one person is thought to have adequately profound
knowledge of all
languages in the world to be able to create translation rules for every spoken
language.
Hence, for the Any-to-Any machine to achieve maximum results and benefits, the
underlying
concepts should be described in such a manner that an expert in a particular
language - who
has also studied the teachings and methods of the Any-to-Any machine - can
then devise the
rules needed to control the conversion of between the language in which he is
expert and a
Concept Language. Additionally, even within a single language such as English,
many
specialist scientific sub-languages exist, each with their own words and
language
conventions, potentially requiring new ways to be created - per the Any-to-Any
machine's
methods - to translate these specialist conventions into a Concept Language.
Because of this requirement, the Any-to-Any machine is presented and described
in
terms of:
1 ) methods for creating a Concept Language
2) methods for devising the rules needed to convert a given spoken or
written language into a Concept Language, and
3) methods for devising the rules needed to convert Concept Language
into a given spoken language.
Language itself is a moving target that continually changes over time and
hence, and
hence from time to time, new methods may be required other than those
described in the
Any-to-Any machine. These may still be extrapolated without undue
experimentation if the
teachings and methods of the Any-to-Any machine are followed.
Basic Principles of Language Affecting the construction of a Concept
Language. A. Overview
The Any-to-Any machine does not take a conventional view of language -
conventional views have so far failed to produce computers that understand. It
has already
been mentioned that the Any-to-Any machine ignores most punctuation and the
subject of
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
grammar, because grammar classifies and describes word functions, and does not
assist with
interpreting meanings.
As suggested in the Summary, the Any-to-Any machine is a series of methods for
classifying and otherwise handling the meanings of the words in a given spoken
language,
such that applying the methods of the Any-to-Any machine, enables a person
suitably
qualified in a specific language to create a Concept Language that can then be
used to
control a computer.
It is clear and generally recognized that words have meanings. The processes a
human uses to store such meanings and the processes he uses to manipulate them
and work
with them are considered, for the purposes of this Any-to-Any machine, to be
unknown and
further, not required to be known. All that is required for the purposes of
the Any-to-Any
machine is
1 ) to observe how humans manipulation words and their meanings, and
2) to invent methods for manipulating words and meanings such that use
of those methods, applied to a specific language, and the resulting Concept
Language is implemented in software, the software manipulates words and
meanings the same way that a human would.
It is helpful to observe the results of methods humans use to handle meanings
(and
hence, the words representing those meanings) in order to construct a Concept
Language
that has as one of its requirements, the ability to mimic human data-handling
methods and
hence the ability to mimic human word-handling methods.
Utter precision in creating a Concept Language is desirable. The use of some
of the
methods in the Any-to-Any machine to attain complete precision of meaning may
appear to
be splitting hairs to the point of absurdity. However, firstly the subject of
computer control
using Normal Language is a new one and it is difficult to predict what
applications a Concept
Language may be called upon to control in the future. Secondly, computers and
their
software are utterly literal. A failure to 'split enough hairs' in the terms
of this Any-to-Any
machine is a failure to identify the different meanings of words with utter
precision when
creating a Concept Language. Any such failure could potentially lead to
catastrophic failures;
the potential power of a computer that is controlled by and able to execute
the commands
given with Concept Language is an unknown quantity at this time. Failures of
precision in the
computer world can be catastrophic - the Y2K problem that has cost billions of
dollars is
essentially a failure of precision. This leads to the Precision Principle and
the Precision
Principle Method of the Any-to-Any machine, which is stated as:
In creating a Concept Language for general use, any separate or slightly
different meaning for a word, no matter how small the difference, that can be
identified
76
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
is given its own Concept Statement and its own Meaning Rules to enable a
computer
to identify when that meaning that is use.
A Concept Language has several requirements it needs to fulfill in order to be
useful
in controlling the functioning of an Understanding Computer. One of the first
and most
obvious of these requirements, and an area of problems in the state of the
art, is the subject
of identifying documents or items that software is required to manipulate. In
essence, in the
state of the art, the computer can not understand the human's specification
for a specific
item, and the human can not remember the software's specification for a
specific item. -
Consequently, the identification of items to be manipulated by software is an
aspects of the
human-computer interaction problem that a Concept Language should take into
account. It
should be able to receive human item specifications and issue something to the
computer's
software that enables that software to identify the item concerned:
~ Concept Language Requirements. Need to identify items using human
specifications
Software can routinely execute complex chained operations automatically
without user
assistance - complex chained operations such as installing new software. A
user expects an
Understanding Computer to be able to execute complex chained operations - just
as another
human would - without requiring constant assistance to do so.
The ability to execute chained operations without user assistance is termed
'Automatic
Software Execution.' The paper points out that software can not do Automatic
Software
Execution when a human gives it orders to do so. The paper states that one of
the main
reasons for this problem is that no software exists in the state of the art,
capable of using a
normal human specification to identify the data on which the software is
required act.
The structure of any software is essentially 'Perform action 'A' on item "X."
A small
piece of software could easily be written that would perform action 'A' - for
example, print any
item. However, there is no point in doing that because software is incapable
of using a
human's specification to identify the exact item or items 'X' on which it will
be required to act.
The human can not remember any of the ways that software uses to specify an
exact item
such as a letter. The software can not understand any of the ways a human uses
to specify a
unique item. A small software module called 'Print' could be written easily,
and could be
coupled to and launched by a human saying 'Print (item specification) X'. But
there is no
point in doing this, because the software cannot identify exactly which item
the human is
referring to when he gives his specification for X.
It is axiomatic that an item - such as a letter - can not be identified,
unless the
specification that may be used to identify it in the future is recorded in the
first place. It is only
possible to identify (and thereafter, retrieve) a letter specified by a
statement such as "get me
77
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the letter from Joe' if it was recorded in the first place that the letter
came from Joe. Hence it
is also axiomatic that software can not identify an item from a human
specification, unless the
software has recorded in relation to that item anything and everything that
could be part of a
human's specification for that item.
Consequently, the first requirement is to identify what type of data a human
does and
does not use when specifying items on which he wants an action performed by
software.
Once those types of data have been identified, steps can be taken to record
them in relation
to all items in the computer. If they are recorded, then a software module
such as "Print X'
becomes both practical and useful. Adding enough software modules to perform
all common
tasks - such as 'E-mail X to Y', 'Fax X to Y', 'Make X boldface' and so on -
eventually results
in a computer that can be told to do anything a computer can be capable of
doing. (The only
other requirement then is to arrange it so that no matter how the user says
'Print X', the
software responsible for execution receives 'Print X' - the Any-to-Any machine
also takes care
of this problem). But none of this is possible, because the computer cannot
identify X based
~ 5 on the human's specification for X.
A specification that a human issues with the intention of identifying the
exact item he
wants is termed a 'Unique Data Specification.' The human issues a Unique Data
Specification
with the purpose of exactly identifying a specific item or item and that item
or items atone,
while excluding all others that he does not want. He expects that the
specification he issues
will identify the exact, unique item he wants, and will also exclude all other
items that he does
not want. If a boss says to his secretary 'Get me the letter Joe sent from
Chicago about
Bananas' he says so expecting that his Unique Data Specification will pick out
the one item
he wants, from the tens or hundreds of thousands of items to which his
secretary has access.
He considers his Unique Data Specification will identify a unique item. (An
item in this sense,
can be singular or plural - all the letters from Joe about bananas' for
example. A 'Unique'
Data specification is unique not in the sense that it unique means 'one' item,
but 'unique' in
the sense that only specific items - the ones he requires - will meet the
specification, hence
the items are unique in that no other items meet that specification. The word
'Data' is used in
the broadest sense. Not everything the human wants to identify is necessarily
a document.
He may want to identify a person's address, or a printer or some other
peripheral. The term
'Unique Data Specification' covers identifying all of these).
Hence, the more precise definition of the problem preventing software from
recording
data that could be used in a human's Unique Data Specification, is that the
types of data a
human uses in Unique Data Specification need to be identified so that they can
be recorded
and used. But even before identifying the types of data to be required, it is
first desirable to
invent a system to copy the way a human uses data to specify something. Only
then is it
78
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
possible to identify the types of data needing to be recorded and make
arrangements to
record them.
Concept Language Requirements. B. Human Unique Data Specification
Example.
The following conversation between a boss and his secretary shows the
principal used
in identifying a specific document uniquely:
Boss to Secretary: Get me the letter.
Secretary to Boss: Which one?
Boss to Secretary: The one I sent to Joe.
1p Secretary to Boss: Which one? There are several.
Boss to Secretary: The one about bananas.
Secretary to Boss: There are at least three of those. Which one are you
thinking
of?
Boss to Secretary: The one he sent me.when I was in Boston.
15 Secretary to Boss: Oh that one. OK, I'll get it.
The first Data Specification "get me the letter', used the word 'fetter' -
word that
means 'one letter.' However, the Data Specification resulted in a data
mismatch - 'the' has a
meaning of 'one' in this instance, and this mismatched with secretaries
recording, namely that
20 she has many letters filed, not just one. The data mismatch lead to the
query ('which ones?'),
and when queried, the boss added a two more concepts to his data Specification
'sent to' and
'Joe'. However, his Data Specification was still not unique - several letters
met those
criteria, and a mismatch between his specification and that the letters the
secretary knew to
exist, and this caused a further query 'Which one? There are several.' The
Boss continually
25 added further concepts to his data Specification - 'bananas', and 'when I
was in Boston' until
the specification for the required data - the letter - was unique and only the
required item met
the specification. Noticeably, as the Boss added specifications, each added
specification was
of a new type:
Letter (type of document); I (Name of person); Sent to (an Action - Sent);
30 , Joe (Name of a person); Bananas (Something in the content of the letter);
When (Time); I (Name of a person); was (Time past); in Boston ( A Location).
Note that the boss did not use several items of one type. He did not say, for
example '
The letter I though about (Action) ! wrote (Action) I edited (Action) I
printed (Action) I sent
(Action).'
35 ~ Concept Language Requirements. B. Enabling Human Unique Data
Specification in a Computer. - The Co-Reducing Concept Method.
79
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Co-Reducing Concept Method enables a computer to copy the way a human uses
a Unique Data Specification. The Co-reducing Concept Method has the effect of
enabling
software to ensure that it has sufficient different types of data available,
so that a computer
has adequate data with which to match any Unique Data Specification it is
given in order to
locate the required item. (Associated software (for example, the Data RElation
Table) should
provide for a) Detecting data mismatch between the Unique Data Specification
and.the data
found in response to the Unique Data Specification. (Had only one fetter
existed, no query
would have been necessary) b) Prompting for Concepts to be added when a Unique
data
Specification does not produce a unique result, c) To handle the added
concepts so that they
reduce the previous selection. d) To continue querying until the specification
and the found
items match. (Note that the reason for the continued queries by the secretary
was the
continuing data mismatch between 'the letter' in the specification (= 1 ) and
the results of the
query which were more than one letter. Querying continued until a Data
Specification was
obtained that produced a result that was, in fact, unique)).
The Co-Reducing Concept Method has wider application than enabling a computer
to
emulate human Unique Data Specification handling. The same method is the basic
method
that also enables a computer to record general text and answer questions on
that text.
Some concepts exist for which a specific word also exists. A word is
effectively a
name, a label, for the concept that is its meaning. The word 'banana' (with
the meaning of
the name of a fruit - there are other meanings also) is an example. Thus the
meaning,
banana(m) is labeled with the word 'banana'. Similarly, the words 'New York'
are a label for a
specific package of meaning New York(m).
However, as shown by the enormous number of concepts and the relatively tiny
number of available words to describe them, not every concept has its own
word. When
inventing a Concept Language that is to be capable of mimicking the known
aspects of a
human's word handling methods, it is useful also to invent a process for
handling the words in
that language that mimics the human's observable word handling methods. The
process
used by this Any-to-Any machine to do so is termed the 'Co-Reducing Concept'
method and
can best be explained by giving an example of its operation as follows:
Consider as an example, the phrase "My New York client friend.'
One person starts talking to another and begins with the word 'My'. He has, at
that
point conveyed a package of meaning to the listener: 'my(m)' represented by
the oval shape
below, with the words 'My' in it.
My
so
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
'My' is a word that conveys the concept of 'everything belonging to me.' It is
not limited
in any way. Anything that is the speaker's, is included and falls under the
word 'my'.
Everything that does not belong to the speaker, is excluded and does not fall
within the
meaning of the word 'my.'
The speaker now says the neXt word 'New York'. To the first package of meaning
'My'
he has now added another packet of meaning 'New York(m)', conveyed by the
words 'New
York'.
'New York' is a concept that, by itself, conveys everything that person knows
about
New York, as represented by the oval shape below with the Words 'New York' in
it:
New York
The effect of stating the two words one after the other, is that:
All of 'My' now described has now been reduced to that part of 'my' that has a
relationship with 'New York'.
Alf of 'New York' has now been reduced to that part of 'New York' that
has a relationship with 'my'
My New York
The two concepts 'my' and 'New York' co-reduce one another.
The person now says the word 'client' which, similarly is word with the
meaning 'all
about cliei
30
Similarly, the effect of saying 'client' is that"
Afl of 'My' has now been further reduced to that part of 'my' that has a
relationship with 'New York' and with 'New York and with 'client'.
All of 'New York' has now been further reduced to that part of 'New
York' that has a relationship with 'my' and with 'client'.
81
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The reduction effect continues when the speaker utters the last word 'friend':
10
Pictorially, the complete phrase "My New York Client friends' is conveyed by
the area
in the diagram that is within the area of all four of the ellipses.
Hence the effect of adding together the different meanings (conveyed by the
words
used) is to reduce the meaning of each one of them, until the concept that is
stated is the
concept that is required. This the 'Co-Reducing Concept' Method of the Any-to-
Any machine,
which is stated as:
A Concept that has not been labeled with a specific word is described
in language either by:
1 ) Giving it a name (which may then be called a 'word' if it applies to a
frequently occurring phenomenon or a 'name' if it applies to only one of
something
or a to a specific group of something), or by:
2) Adding together words that do convey individual concepts in such a
manner that they co-reduce one another's meanings to that part of the meaning
of
each that is common to all.
3) Even when concepts are given names as in (1 ), those names are
defined using the principle of (2).
4) The order in Which the co-reducing concepts are stated is of no
importance to the meaning conveyed by the co-reducing concepts themselves.
3Q 5) However, if a particular member of the co-reducing concept group is to
be further described, the one that is to be so described may be coded and
indicated by the order of the words in the group of Co-Reducing Concepts.
It can be easily seen that the order is not material to the concept itself
My New York client friend
My friend, a client in New York
My client, a friend in New York
82
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
My New York friend and client
Actions also operate on the Co-reducing Concept Method. The concepts:
'running, jumping, swimming horse' can be represented pictorially as:
When the Co Reducing Concept Method is presented in the description of this
Any-to-Any
machine, it is represented by the symbol '&' used with a special meaning in
this description to
mean:
"'&' shows that the two words with which it is used are acting on the Co-
reducing Concept Principle and therefore have a specific relationship to one
another
to convey the meaning of this concept.'
When a particular set of co-reducing concepts is used frequently, it tends to
be given
a name. As stated above, this name itself is described using the Co-reducing
Concept
Principle: as an example of this, consider the word 'roam' as used for
telephones. On the Co-
reducing Concept Principle, it can be stated as:
25
83
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
'Roam(m)' - telephone & connected 8~ outside & service & area
and can also be portrayed pictorially on the Co-reducing Concept Principle as
follows.
The Co-reducing Concept Principle can be stated simply and colloquially as 'in
order
to specify something, meanings are added together by stringing their
representative symbols
(words) together, each added symbol reducing the scope of the previous
meanings, until the
remaining meaning is the exact meaning required.' More precisely it is defined
as:
An item is specified by adding any one word to any other word, with the
corresponding result that the Concept encompassed by each word is co-reduced
to
that part of the Concept of each that is common to the other. The processes is
continued by adding any other word - and hence its corresponding Concept - to
the
pre-existing words - and hence Concepts. Each new word that is added further
reduces the Concepts encompassed by the previous words to that part of the
Concept
of each of the words that is common to all of them. The process is continued
until the
part of the Concept common to all words present is the Concept that the person
wishes to state.
(Concept of a word and Definition of a word. The two are not identical. For
example,
one Definition of the word 'move' is 'to change the place or position of.' By
'Concept' of a word
is meant ' the entirety of whatever the definition states' Thus the Concept of
'move' is
considered to be all of 'move' everywhere, at any time, done in any manner by
everyone and
2Q everything. Some idea of the broadness of this can be obtained by asking
someone 'What do
you know about 'word'? - 'What do you know about 'move'?'
This Co-Reducing Concept Method is used in the Any-to-Any machine, in
combination
with previously mentioned Concept Hierarchies, to identify the types of data
that need to be
recorded in order to ensure a human's Unique data Specification can be met -
if implemented
in the appropriate software.
~ Concept Language Requirements. C. Identifying and Classifying Words used
in Unique Data Specifications
The Any-to-Any machine views words as labels that humans ascribe to things.
The
word 'banana' can be considered a label for a person's knowledge about
'banana.' Humans
assign labels to anything and everything. Hence the Any-to-Any machine views a
spoken
language as a means of communication, consisting of labels for:
1) Physical universe phenomena, that exist whether an individual
observes them or not
2) Things that a human can experience or imagine - thought, emotions,
philosophies etc
84
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
3) Things that a human being creates or that are so, wholly because a
human considers they are so. Qualities fall into this category. One person
considers
something to be 'good', and for him it is good. Another person considers the
same
thing is 'bad', and for him it is bad.
More precisely, (2) and (3) are simply different aspects of a human, and
equally not all
aspects of a human being are of concern to a computer. Hence the above list
can be
restated as: A language is a means of communication consisting of labels for:
1 ) Physical universe phenomena, that exist whether an individual
observes them or not,
2) Those aspects of a human being that can be recorded in a computer:
- Names
- Emotions
- Qualities
- Reasons
Language that is a means of communication concerning the physical universe, is
necessarily a reflection of that universe it is used to describe. The physical
universe can be
divided into four basic categories: Time, Space, Energy, and Matter. The words
in a
language used in relation to the physical universe are all human-ascribed
labels for physical
universe phenomena, and while the phenomena themselves can not be stored
directly in a
20 computer, the labels for those phenomena can be stored. And thus, and
inevitably, each of
these physical universe categories - Time, Space, Energy, and Matter - has its
own group of
Meaning words applying to it. (As briefly described in the Summary, some words
have certain
types of meanings and are referred to as meaning Words. Other words have
meanings that
principally or most desirablely perform operations on other words, and these
are labeled
25 'Operator Words'. They are labeled as Operator Words to indicate that their
main meaning is
an operation they perform).
(It is of no concern whether or not the above categories into which the Any-to-
Any
machine divides the physical universe exist or not, or whether they are the
only categories
that exist or not. All that is of concerns is that that is the way this Any-to-
Any machine treats
3p the physical universe, and the Any-to-Any machine makes no claim to present
any ultimate
truths. It simply divides the physical universe this way for its own
convenience).
To these four categories - Time, Space, Energy Matter, can be added the
category of
'Life' as word to label the aspects of a human being that can be recorded in a
computer
(Names, Emotions, Qualities, Reasons).
35 This gives a final list of the categories of Meaning Words that can be
recorded in a
computer:
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Life, Time, Space (Location), Energy (Action), and Matter.
These five Divisions of data, when used for recording in a computer, are
termed 'Data
Categories.'
Data Categories are an invented method that is used to classify and manipulate
the
meanings of words.
Practical test shows that every single Meaning Word, without exception, can be
found
to fall into one or other of these 'Data Categories', as they are termed for
the purposes of this
Any-to-Any machine. (Operator Words, on the other hand, prove difficult to
assign to any of
these categories,.and this is one of the indicators of an Operator Word).
These invented Data Categories display certain conimon behavioral phenomena
that
are used by the Any-to-Any machine to solve the problem of identifying what
data needs to be
recorded, and how that data should be recorded, in order to be able to
identify an item based
on a human's Unique Data Specification. (The Life Category has some behavioral
differences from the other Data Categories and these differences will be
explained later. The
i 5 following description of Data Category phenomena applies to all Data
Categories, and with
some exceptions to the Data category of Life):
Phenomenon 1: The single, individual Concept Symbols in a Data Class each
label a
single meaning, and therefore, can not conflict with one another, and are
therefore Unique.
Because of this phenomenon, a selection of Data Class values from different
Data Classes
constitutes a unique statement. Therefore, adding sufficient Data Class values
to one
another, can constitute a unique specification for anything. For example, a
concept exists to
which the name 'chair' is given. No other concept whatsoever is the same as
the concept of
'chair'. Every other concept is different to the concept of 'chair'.
Phenomenon 2: Queries can only be answered with a value from their own Data
Category.
Humans often issue queries by Data Category - they query a whole Data
Category at once. Answers to such queries show that a query for a value from a
specific
Data Category:
1 ) Can be answered by any value from its own Data Class.
2) Can only be answered by a value from its own Data Class
3) Can not be answered by any value from any other Data Class.
(There are some additional aspects to the above, that will be described later,
but
the above three points remain fundamentally true).
In the following simple examples, each query can be answered with absolutely
any
value from its own Data Category but can not be answered with any value from
any other
Data Category:
86
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
4uestion trwnownt~nrime i~spormefromResponserrom"'~""'~'
G~tegory Category LocationAction ~ her
CategcxyCategory
rme Park Avenue
~Vl~adtheletterartive? ~rned
Christmas Letter
tnratlon Gvistmas
Where ~ ed
is Letter
the
iettei'?
Park
Avenue
Action Christrt~s
Wt>at Park
ad Avenue
d~ t.Etter
to
the
letter?
Printed
IvhtterWhat is that L.etteChristmas
thing you Park
are hddrx~. Avenue
~ rned
~
Phenomenon 3: Data Categories can be sub-divided into Data Classes that
display
the same behavioral phenomena as Data Classes:
In addition to querying by Data Category as in the above example, humans also
query by Sub-categories of these Data Categories. For example, a human will
query
'What furniture is in the room?' The word 'furniture' covers is a sub-division
of the Data
Category of Matter, i.e. a Data Class, and the Data Class of furniture
includes - chairs,
tables and so on. Exactly as for Data Categories, when a human issues a query
for
something from a specific Data Class, he expects to be given an item from that
Data
Class and not from another one. For example, if a human queries "When did Joe
go to
town?' - a Time category query - he will not understand it if he gets the
answer 'chair'
from the Data Category, Matter, Data Class furniture. If he issues a query
concerning the
Matter Data Class of furniture': 'What furniture is in the room?' he will not
expect, and not
want an answer '14.30 Tuesday' taken from the 'Finish Time' Data Class of the
Time Data
Category.
The interaction of these three phenomena are expressed as a whole in the 'Data
Classes Integrity Principle and Method', which is defined as:
~5 The meanings of words can be grouped together into groups of similar
meanings, beginning by dividing them amongst the five Data Categories, and
further
subdividing the meanings into Data Classes and Data Sub-Classes. A query
concerning a given Data Class can only be satisfied by a value from that
Glass, or
from a Class that is junior to that class. Normally, the most junior available
value is
required.
Note that the above definition refers to classification of meanings, not of
the words
themselves. Words often have one meaning that falls into one Data Category and
other
meanings that fall into other Data Categories. For example, the ward 'jump' as
in 'I jump the
fence' is an action and therefore falls into the Energy Data Category. But 'a
jump' which is a
thing, as in 'take your horse over that jump' lies in the Matter category.
a~
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Phenomenon 3: Data Categories and hence Data Classes, exhibit a Data Class
Functional Hierarchy that greatly facilities identification of data in a human
Unique Data
Specification.
The Data Categories when placed in the following order exhibit a hierarchy of
function
that,greatfy facilitates the location of a specific item:
Life - Time - Space - Action - Matter
It is well within the state of the art to create a database containing fields
for different
Data Classes and to record in it known data in relation to each item in or
attached to the
computer together with a reference to the disk location of the item. In a
previous example a
boss said to his secretary 'get me the letter sent from Joe about bananas when
I was in
Boston'). Suppose that the different concepts in the example were entered in
their
appropriate data Categories and Data Classes in the database as follows:
(Unused data
categories on the right hand side are not shown to conserve space).
The table above shows two blocks of Data Categories - one applying to the
Cause
side - the sender
Cat Life Time S ace ActionMatter ActionLife
o
Data 1st Doc T Content 1st
Ciass Name Name
Item Boss Sent Received
past T Joe
time Letter
Boston Letter
~ Content
of the document, and the other to the Effect Side the receiver of the
document. The
separation into two blocks is merely for convenience of comprehension and it
is supposed
that the fields of the two blocks are all entered in the same database as one
record. It is well
within the state of the art to write software to look up values such as the
above in such a
database and return the database record concerned.
Now supposing also that this database has data such as the above recorded in
it for
all documents produced by all the members of a large company. Clearly, if a
search for a
specific document begins with the fields applying to the most junior member of
the Hierarchy
- Matter - by looking for 'letters' as a document type, the search will be a
long one as there
may be hundreds of thousands of letters going back many years. Equally, if the
search
begins by searching all files in the computer for the content of 'banana', the
search will return,
as it does in the state of the art, a fist that is impossibly long and
therefore useless, as well as
taking an inordinate time to execute.
88
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
However, if the search is executed in the order of the Data Class Functional
Hierarchy, i.e. from outside inwards - the two Life Data Categories first- the
search is being
conducted on the smallest number of potential matches and is therefore as
rapid as possible.
The search begins with items contain both the Boss and Joe, of which there
will be relatively
few. Those items concerning both of them the Boss was in Boston will be fewer
still. The
number of items the Boss sent to Joe at that time are unlikely to exceed a
small number. The
very last step, per the Data Class Functional Hierarchy will be to search the
content of the
remaining few items for the one containing the content of 'banana' - using
state of the art
content search technology. When only a few items are searched for content, the
search
takes only a fraction of a second. Since someone can only issue a Unique data
Specification
at a limited speed, it is possible to imagine that the item identification
process will keep pace
with the speed at which the Unique Data Specification is entered. Hence, the
item
identification process is likely to complete virtually simultaneously with the
user finishing to
enter his Unique Data Specification.. Thus in addition the Co-reducing Concept
enabling a
computer to provide an easier way to locate an item, it has the added benefits
of locating
items with total precision and further, of being faster than state of the art
methods.
The information or data required, then, to locate specific_items can, in
theory, be
entered at the time of their creation into Data Classes represented as fields
in a database.
Additionally, Data Classes exhibit certain phenomena that enables an item to
be found based
on a human Unique Data Specification and found rapidly. The remaining
requirement is to
identify the Data Classes that are need to be used, and the values in those
classes that need
to be recorded, and these depend in part on the applications to be used and
hence, the items
that will need to be located.
While Data Categories do not change, Data Classes are not a fixed rigid list,
but are
added or subtracted depending entirely on the intended application. There is
little point in
having a Data Class for water pump controller names if the Data Classes are to
be used in an
office application, and equally little point in having a Data Class for
printer names in an
application controlling water pumps in a power station. Hence, the exact
selection of Data
Classes depends on the application to be controlled, and hence, the vocabulary
to be used,
as follows:
~ Concept Language Requirements. D. Using Data Classes to Identify Specific
Items.
Any spoken Language consists of a quantity of words used by most people
speaking
the language natively and these can be called 'General Use Words'. Every
language then
has various blocks of words that are used in specific activities, such as
accounting or
astronomy, that can be termed 'Specialist Use Words'. Hence the actual words
that need to
89
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
be translated into a Concept Language includes the General Use Wards and may
also
include Specialist Use Words depending entirely on the application with which
the Concept
Language is to be used.
Specialist Use Words also, sometimes fall within existing Data Classes, and
sometimes require their own Data Class if there is enough of one type of them
that they may
be called upon to serve as part of a Unique Data Specification. Equally, new
words can be
invented to describe new things, and while such new words will fall into ane
Data Category or
another, they may or may not fall into an existing Data Class.
Hence, the first step in incorporating Data Categories, Classes and Sub-
Classed into
a Concept Language is to identify the separate and different Data Classes that
exist for the
intended application.
~ Concept Language Requirements. E. Identifying Data Classes
The Any-to-Any machine has two methods to identify Data Classes, and the
choice of
which method to use again depends on the intended application.
~ 5 The first, empirical method, is to take a large sample of Unique Data
Specifications
that can be used for a specification application. Then, bearing in mind the
Data Categories
and various teachings and methods of this Any-to-Any machine, to divide the
Concepts found
in the Unique data Specifications into groups within the appropriate Data
Categories. This is
the method that was first used to identify and invent Data Classes for use in
general office
software applications, and is sufficiently powerful that it led to the
remainder of this Any-to-
Any machine. This method eventually furnishes a reasonable selection of Data
Categories
that can be used for identifying any stored item in a computer, or any
attached item.
Essentially, this method creates a limited Concept Language that is capable of
being used to
control a computer in most cases, but will not take accourit of different
phrasings used to say
the same thing, nor wilt it enable a computer to answer questions on stored
content. The
main benefit of this method is that it creates a mechanism to exactly identify
documents and
peripherals. Such identification can then be related to and used with software
modules such
as 'Print X' previously described, provided the user uses the specific word
'Print' or whatever
synonyms the programmer has provided for 'Print'. This method produces a major
benefit by
itself as it solves one of the major problems that exist in the state of the
art- the increasing
and major difficulty of locating the right document in a computer, especially
as these increase
in number.
However, the more thorough method is to use the method of Concept Hierarchies
because the Concept Hierarchy Method identifies all Data Classes anywhere in
the entire
spoken language being converted into a Concept Language.
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Because the Concept Hierarchy Method can be used with the entire language, as
opposed to just those parts of the language used in document identification,
the Concept
Hierarchy Method enables all Meaning Words in the whole spoken language to be
classified
into Data Classes and Data sub-Classes as part of the translation process into
Concept
language. The additional benefit of this method, as previously mentioned, is
that when all
data in a computer can then be stored in Concept Language form, enabling the
computer to
answer questions on the data it contains.
The method for creating Data Classes using the Concept Hierarchy method is as
follows:
~ Concept language Requirements. E. Using Concept Hierarchies to Determine
Data Classes.
Concept Hierarchies were discussed briefly in the Summary, as being the
Hierarchy of
grouping of words by which a human queries for information. A human can, for
example, ask
'what did Joe do?" and thereby query for any Action (i.e., any Energy Data
Category entry) of
any kind done by Joe. Thus Meaning Words - for example the word 'fly' - have
an effective
hierarchy of groupings - termed a Concept Hierarchy - by which they tend to be
queried. In
the case of the word 'fly' (as in an action) this was cited as
'do & move & travel & fly.'
Establishing such a Concept Hierarchy enables a computer to respond to queries
such as:
'What did Joe do' - Querying for any entry in the Action Data Category. (The
query word 'do' is used as the most generally used word to query for any
action.)
'How did Joe move?' - Querying for any entry in the 'do & move' grouping.
'How did Joe travel?' - Querying for any entry in the 'do & move & travel'
grouping
or "how did Joe go?" - the word 'go', in this instance, has the same meaning
as the
word 'travel' and hence, is translated to 'travel' before the query is run.
('Go' does not always
mean 'travel'; for example in 'What are you going to do?' It has the meaning
of 'intend').
A word's Concept Hierarchy can not be found mechanically by software but
should be
found manually by observation and analysis of the word's use in practice. One
method for
doing this is:
1 ) To select many texts using the word
2) To establish the each and every different meaning for the word (as per
the teachings of this Any-to-Any machine)
3) To ascribe to EACH meaning its own Concept Symbol
4) Work out the Concept Hierarchy for each different meaning that has
been located. This is done by asking a question or questions that essentially
are
91
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
of the format of 'is this word a type of something or a member of a group of
something?'. It is useful to use a number of different phrasings for the
question to
be sure to elicit all the groupings by which the word can be referred to. As
an
example, asking this question of the word 'banana' in one of its General Use
meanings, when it means a fruit as opposed to when it is a color or one of its
other
meanings: 'is 'banana' a type of something?' gives the answer of: 'Yes, it is
type of
fruit.' (For a Specialist Use Vocabulary it would give the answer of ' It is
type of a
type of plant). Asking the same question of 'fruit' - "Is 'fruit' a type of
something?'
- would give the answer 'Yes, it is a type of food.' Repeating the question
'is food a
type of something?' gives the answer ' Yes, it is a type of thing' - ie the
Data
Category of Matter. Hence, and in effect, starting with a specific meaning of
a
word, the questions work back up a Data Category to the top of the Category.
While a single word (which can have many meanings) can be found to have many
Concept Hierarchies, one meaning of the word will only be found to have one
Concept Hierarchy).
The above questions established the Concept hierarchy for the fruit
meaning of the word 'banana' as:
Matter & food & Fruit 8~ Banana
(where '&' represents the Co-Reducing Concept Method).
Note that it is desirable to establish the Concept Hierarchy for each
meaning of a word before establishing its Concept Hierarchy. The word 'going'
as
in: 'where are you going?' has a Concept Language meaning of 'travel'. Once
translated to Concept Language for this meaning as 'travel' the Concept
Hierarchy
for 'travel' can be found. But 'going' as used in 'what are you going to do?'
has the
meaning of, and Concept Language Symbol for 'intend'. Once translated to
'intend' the Concept Hierarchy for 'intend' can be found as above.
Attempting to find a Concept Hierarchy for a word with several meanings
will lead to finding several Concept Hierarchies for the same word. If more
than
one Concept Hierarchy is found, this is itself an indication that there exists
more
than one meaning, and these meanings have not in fact been separated per the
teaching of the Any-to-Any machine.
The actual questions used to locate Concept Hierarchies can be varied
depending on
the Data Category of the word being questioned. In the case of an Action, a
useful question
might be: 'Is this a way of doing something else?' or 'How else can you do
this type of thing?'
'Word X is a way of ~' (Flying is a way of ~ -travelling. (A full list of
questions devised for discovering different types of Concept Hierarchies is
attached as
92
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Appendix ""', but alternative questions can easily be devised following the
teachings of this
Any-to-Any machine).
In order to ensure all Concept Hierarchies are found, every Meaning Word in
the
language, after, or during the process of translation into Concept Language
should be tested
against a suitable question list - such as the one provided - to see if it
belongs to a Concept
Hierarchy. This is a matter of painstaking investigating, following the
teaching of this Any-to-
Any machine. It should be done manually and can not be automated, because the
Concept
Hierarchy a word belongs to is a matter of how the word is used. by humans in
relation to
other words, and this requires thinking observation of the human use and
behavior of the
-IO word.
Concept Hierarchies enable Data Classes to be established because the
relationship
between Concept Hierarchies and Data Class is as follows:
A Data Class is a group of words or items that have the same senior in
a Concept Hierarchy.
15 In the following example, the words 'fly' 'bus' 'car' are used in with the
meaning of
actions, not the meaning of the physical objects. Their Concept Hierarchies
are:
do & move & travel & fly
do & move & travel 8~ bus
do & move & travel & car
20 The words 'fly' 'bus' 'car' (as actions) are values in (members of) the
Data Class
named 'travel'. 'Travel' is itself one value in the data Class of 'Move' -
other members might
be 'slide' 'skate' and so on.
An office computer that can be controlled and also asked questions on all
recorded
data, or use software modules that work based on an analysis of recorded data
will require an
25 extensive Concept Language, many Concept Hierarchies and many corresponding
Data
Classes. An example of a list of Data Classes for such an application is
attached as
Appendix B.
However, an application to be programmed can be extremely limited, and not
require
an extensive language review in order to identify the possible Concept
Hierarchies and hence
30 Data Classes. For example, the application to be programmed might be to
enable Normal
Language control of a telephone with a limited memory. In that case, what the
telephone can
~do is extremely limited, and hence the number of possible instructions is
limited also.
Consequently, the Concept Language required is consequently small, and the
possible
Concept Hierarchies and Data Classes are very few.
35 In this case, where the application is small, the Any-to-Any machine
includes a
simplified method for detecting Concept Hierarchies and hence Data Classes,
consisting of
93
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
1) Make a list of the instructions the physical architecture can execute,
and add to that, the list of instructions the software is required to execute
(within
the capability of the hardware).
2) Make a list of hardware devices the application is to control, if any (in
addition to software actions)
3) Assemble these two lists into groups of similar actions.
4) Work out the Concept Hierarchy (and hence Data Classes) for these
two lists.
(Remembering that even in a small application, the software is still required
to handle
data and language concerning that application the same way human would handle
them, a
Concept Language should be devised that includes all words that could be used
with that
application. The Any-to-Any machine's methods for creating a Small Application
Concept
Language are described later).
The following example illustrates the application of the above simplified
process to a
very basic computer:
Step 1) Begin (with the Energy Data Category) and ask 'what can this
computer do? In order to get answers to Step1 above. Three of the answers
might
be:
It can print things, store things, fax things. It can make text bold
2p Step 2) Make a list of hardware devices the application is to control.
Printerl , Joe's Printer, screen, hard disk etc.
Step 3) Assemble the fist into groups of similar actions.
Do this by asking questions of each of the items on the list, to discover if
it one of a
group. For example, asking in relation to a computer's ability to print things
'Is 'print, a type of
something else?' shows that it is just a type of output and so is 'store'
another type of output.
But 'fax' things is a type of output but also a type of electronic
communication. Electronic
communication is itself just another type output. On the other hand, making
something bold
is not a type of output at all, but is in fact changing the appearance of
something.
Step 4: Use what has so far been discovered and questions (as given previously
to
work out Concept Hierarchies) to work out the Concept Hierarchy and Data
Classes for items
on the two lists.
The Concept Hierarchy for the word 'print' then could be:
Do & output & print00
And the Concept Hierarchy for fax (the action of faxing something) would be:
Do & output & communicate & fax
94
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The following table illustrates how the above Concept Hierarchies for the
individual
words can then be assembled together to form Data Classes. The Table also
shows some
Concept Hierarchies grouped into Data Classes for some members of the Matter
Data
Category:
Associated software should then record any value from any Data Class that
exists at
Data Class Data Sub-Class Data Sub-Sub Class "°'°
I I I I I l...__.l I Data Class
the time of any action. Failure to do so will result in the computer failing
to identify an item
based on a correct human Unique Data Specification. For example, if a user
does any action
on any item, this should be recorded in Data Class format. A user can for
example Print an
item. He can later issue a Unique Data Specification such as: 'get me the
thing I printed ten
minutes ago.' The only available data in the Unique data Specification with
which to locate the
item is 1 ) that he did Print it, and 2) he printed it ten minutes ago. If
Data Class Time and
Data Class Energy (action of printing) was not recorded when the action was
done, then item
can not be found form his Unique Data Specification.
However, if Concept Hierarchies have been worked out correctly as per the Any-
to-
Any machine's methods, and if every Data Class value that is available at the
time of an event
is recorded in relation to the item that was the subject of the event, then:
Every Unique Data Specification will consist of one or more values from one or
more
the Data Classes. If software searches recorded Data Class values to find the
Data Class
values in the Unique Data Specification, and treats these values on the Co-
Reducing Concept
Method, then the correct item will be found and incorrect items will be
excluded.
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Any-to-Any machine methods of Data Classes and Concept Hierarchies
produces
specific benefits, two of which are:
1 ) By enabling Data Classes to be created that reflect human use of
specific words, they provide the basis to enable items to be located based on
a
human's Unique Data Specification.
2) They provide the basis for enabling general text to be recorded in a
computer in such a manner that the computer can be questioned on recorded data
as a human would question it, and can also manipulate that or other data based
on
the results of its query or question.
The contribution of Concept Hierarchies to enabling text to be questioned as a
human
would question it will be explained after explaining in more detail what a
Concept Language.
A Concept Language is best explained by explaining the methods of the Any-to-
Any machine
to create one.
~ Creating a Concept Language. The Laws of Concept Language
The first step in the process of creating a Concept Language is to ensure that
the
Concept Language obeys the main Laws of Concept Language, which are as
follows:
1 ) Any Concept Symbol ('word') used in a Concept Statement may never
have more than one meaning.
2) Each of the Concept Symbols or Concept Statements used in the
language with a single meaning, may never be identical to any other Concept
Symbol
or Concept Statement the Concept Language used with another meaning.
3) Every individual Concept Symbol used as a component of Concept
Language may itself not contain more than one, single meaning.
4) Concept Symbols or Concept Symbol Statements, or a combination of
these, corresponding to any one meaning should be unique and distinguishably
different from all other Concept Symbols and all other Concept Statements or
combination of these that has a different meaning.
5) When a given unique meaning can be stated by one or more words or
word combinations in the language being converted to Concept Language, only
one
unique Concept Language Concept Symbol or Concept Symbol combination may we
used to represent that unique meanirig.
~ Creating a Concept Language. Basic Method to Create a Concept Language
or Translate Language X into a Concept Language.
Three difficulties exist both in creating a Concept Language, and in
translating
different spoken language into a given Concept Language, and these are:
96
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
1 ) A Concept Language consisting entirely of numbers - called a Number
Concept Language is much faster for a computer to manipulate than a language
consisting of word, and is therefore the most desirable type of Concept
Language,
and the one that should actually be used by associated software, but
2) Such a number language is virtually incomprehensible for a human. If
a spoken language is transformed directly into a Number Concept Language, it
is
very difficult to compare meanings and symbols assigned to them. A Number
Concept Language is also much more compressed than a Concept Language that
is created using existing words in a language, and this makes it even more
difficult
for a human to understand.
3) A profound understand of the meanings of the words in a specific
language is required both to create a Concept Language, and to work out the
rules
to translate a second or subsequent languages into an existing Concept
Language.
A userful solution to these problems is to use the following general method to
create a
translation from a given spoken language to a Numbers Concept Language:
1 ) Begin with the spoken language, language X. This should be a
language with which the person creating a Concept Language or creating a
translation of a spoken language X into an existing Concept Language is
extremely familiar. If the person's understanding of the language is limited,
or if
they believe that some words do not really have specific meanings (some people
believe this) their work will produce a nonsense language, not a Concept
Language
2) Transform the known language X into a Language X Concept
Language = i.e. a Concept Language that is a Concept Language version of that
same language. Do this by following the steps listed and explained below. This
process essentially involves using the same words as in the original language,
but
changing them in a variety of ways per the methods described, so that when a
word has more than one meaning, the different meanings can be seen from
looking at the Concept Language versions of the word. This result is termed a
Language X Concept Language
3) In the case where a Concept Language is being created for the first
time, each individual meaning in the language - which is now represented by a
statement in the Language X Concept Language - is given its own number. This
transforms Language X Concept Language into Number Concept Language that is
easy for computers to manipulate.
97
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
4) In the case where Language Y now needs to be translated into an
existing Numbers Concept Language, The first step is to create a Language Y
Concept language. Then someone who is familiar with both Language Y Concept
Language and pre-existing Language X Concept Language can look at both, and
assign the same Numbers Concept Language number to the Concept Symbols
with the same meaning in both original Languages. Because a Concept Language
does not have any ambiguous statements, and because each Concept Symbol in
the language has only one meaning, it is then relatively easy to compare a
meaning in Concept Language X with a meaning in Concept Language Y and
determine the Concept Language statements in both languages that are the same
as one another. As each matching pair is found, the Number Concept Language
number that is assigned to a statement Language X Concept Language is
assigned to that same statement in Language Y Concept Language. For example
an English word 'walked' is decompressed in Concept language to it component
meanings - walk & past time. Another language may have a single word that
decompresses to 'he & walk & past time' The decompressed concepts 'walk' are
the same in both languages.
This matching is possible, because regardless of language and country,
the physical universe that all people are subject to behaves the same way
across
the world, and hence words to describe those phenomena exist in all languages.
Equally, people across the world, while they have different social customs,
have
fairly similar thoughts. Occasionally a human-related concept exists in one
culture
and not in another. Then, a concept in Language Y Concept Language may exist
that does not exist in another culture and is not found in Language X Concept
Language. When this occurs, an addition to the base Number Concept Language
is required. Where the concept does not exist as single word in Language X,
the
Language X Concept Language definition of the word, translated into the
language
with the missing word is the way that word is said in that language. For
example,
language 1 has a word - 'XXY' that means 'I am happy because you are good.'
Language 2 does not have this word. When translating XXY into Language 2, the
translation simply uses the Language 1 definition. (It is sometimes said
'Concept
X does not exist in country Y.' Such a statement is false. There is no way of
looking inside people heads and knowing whether that concept exists or not.
All
that can be known is that a specific word - a label - for that concept does
not exist
in the language).
98
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
With the above basic method in mind, the following is an outline of the
processes to
create a Language X Concept Language:
~ Creating a Concept Language. Steps to Create a Language X Concept
Language
The following steps presented in the order of the sequence that can be used to
create
a Concept Language. However, the steps may have to be done several times, as
the result
of one step affects the work that was done on a previous step. Equally, as a
person
progresses with the steps, the depth of understanding of how the language is
working in the
light of the teachings of the Any-to-Any machine increases, requiring previous
steps to be
redone. The Steps are complete when it is found that no further conflicts
exist between the
results of one step and those of another step.
20) Step 1. Select a vocabulary suitable to the intended
application for the Concept Language
21 ) Step 2: Divide the words of the vocabulary into Meaning
Words and Operator Words, using the methods to be described. This division is
useful as the two types of words are treated differently by the Any-to-Any
machine.
The following steps apply to Meaning Words only:
22) Step 3. For each Meaning Word that takes multiple forms,
isolate each individual Base Concept.
A 'Base Concept' is defined as 'that part of the overall meaning of a word
that
does not change, despite different suffixes or prefixes or forms of the word.
For
example, the word 'invite' takes multiple forms - invite, invitation,
inviting, invitational
and so on.
(Operator words do not take multiple forms and this is one of the indicators
of
an Operator Word). '
23) Step 4. Make a full list of all prefixes and suffixes existing in the
language
Divide all prefixes and suffixes into categories of similar types based on
their
meanings or the operation they perform. In the English language, prefixes and
suffixes are a mixture of Operators acting as a compression code on their own
word,
Meaning Words that have their own meaning, and some are both Operators and
have
a meaning. The major types are:
1 ) 'Attach to' Operators. These perform a compression coding
that states which word type the word concerned is attached to and hence the
99
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
word for which the word with the code now operates on the Co-Reducing
Concept Method.
2) Meaning Operators result in completely changed meaning of the
Base Concept. For example '-age' adds onto orphan - a type of a person - to
make orphanage, as a location where orphans five. But '-age' also adds onto
the word 'broker' to make 'brokerage' which is not a place at all.
3) Time Operators are compression codes for time. '-ed' on a
word of Action for example, adds concept of 'past time' to a word, and that
past
time then operates with the word it is attached to with the Co-Reducing
i 0 Concept Method.
4) Quality Operators Some suffixes and prefixes add a quality to
the word they attach to per the Co-Reducing Concept Method. An Example of
this type is 'non-' as in 'non-destructive' which is essentially 'negative &
destructive'.
24) Step 5. Test each Base Concept with all possible combinations of
suffixes and pre-fixes.
It will be found that prefix and suffix additions occur more frequently in the
spoken language than in even the largest dictionaries and the only way to find
all
possible combinations is to test each word with all combinations of prefix and
suffix.
Frequently, such prefixes and suffixes are used ad-hoc to create words that
are clear
to the listener, and therefore, should be clear to an understanding computer,
but are
not found in any dictionary. Dictionaries inevitably record the words that
both existed
and were accepted by the authors as existing and as being acceptable, some
time
prior to the date of printing. Hence dictionaries are to some extent
historical, while a
computer should operate in present time. Also it is not the place of a
computer to
dictate acceptable grammar and word usage, but the place of the computer to
understand, if at all possible, what the user means.
Examples of such words are unreprintable, recyclableeness, terminatedly
Such combinations of a Base Concept plus any suffix and/or prefix
combination is termed a 'Variant' of the 'Base Concept' and should not be
confused
with words where the Base Concept itself changes.
When doing this, each combination should be checked for prefix and suffix
additions that result in the word having a special meaning that is not simply
the
meanings of the prefix or suffix and the Base Concept combined. When found,
assign
a Concept Statement to the word as per the instructions for doing this. An
example of
such a word is 'unprintable' which has three meanings that are not found in
the Base
o
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Concept of 'print' 1 ) 'can not be printed' 2) 'not fit to be printed' with a
conation of rude
or obscene 3) trousers.
Combinations should each be tested for their ability to combine further such
as
'unre-printableness - a word than can be understood but that can not be found
in a
dictionary.
25) Step 6. Assign Concept Symbol or Concept Statement
Concept Symbols or Concept Statements are assigned to each meaning of
each. word, and each Variant, at the same time assigning Concept Hierarchies
to each
word as it tested. Do this by following the methods described in detail to do
this.
The first objective of a Concept Language is to convert each word that has
more than one meaning under any circumstances that are likely to be
encountered,
into a form such that:
Each different meaning of a word has its own Concept Symbol
or Concept Statement (a combination of Concept Symbols). For example, the
word 'worked' decompresses to 'work' & 'past time'. It Concept Statement
(collection of Concept Symbols) is 'work & past time.' No other word may have
that Concept Statement. (Remember also, as will be explained in more detail
later, that a spoken language word is used as a Concept Symbol, (for example
the word 'work') as a Concept Symbol it will have only one meaning, and all
its
other meanings will be assigned to other Concept Symbols.
When a word, in specific circumstances, has a meaning that is the
same as that of another word another word also under specific circumstances',
then, for those circumstances, only one concept Symbol or Statement is
assigned. At the same time, the words concerned are marked as 'Alternates.'
An 'Alternate' is not identical to a synonym - the exact difference will be
explained later in the description. An 'Alternate' is defined as 'Two or more
words with only one meaning each under specific stated circumstances. The
words can be used interchangeably under the stated circumstances.'
26) Step 7. Create Concept Language Definitions.
The next step is to define each word, using the Concept Symbols that have
been created in the previous steps. In practice, a full definition of a word
will be found
to consist of the existing Concept Statement plus entries in other Data
Categories
than the Data Category of the word. For example, the meaning of the word
'roam' as
used in telephones, is distinguished Pram all other meanings of the word, by
the fact
that it applies to telephones, as opposed to the other meanings, all of which
apply to a
person or thing that has the ability to move.
101
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
There are only a limited number of features that distinguish in a given
piece of text, which meaning of one single spelling of a word is operative.
These
features fall into categories as follows (sub-categories exist and will be
described
later):
1 ) Data Entry Compression Coding. The nature of the type of data entry
(Command, Command query, or Data for recording) can change the meaning of
the word. The summary gave an example of this type of coding, where the
meaning of 'stop' changed when the word stop was used in a command 'stop
printing' and then in a query 'when did printing stop?'
2) Word Position Compression Coding. The meaning can be changed
depending on the physical position of the word in relation to other words in
the
Statement (a rough equivalent of a 'Statement' is group of words that make
sense' and is very approximately equivalent to a sentence, phrase or clause).
'Put
the stop under the door' codes stop as thing. 'Close the stop door' codes
'stop' as
a quality of a door.
3) Statement Position Compression Coding. This coding where the
position of the word in relation to the Statement itself changes the meaning.
An
example was give in the summary of this type of compression coding using the
example 'Stop I like this' and 'I like this stop'
2p 4) Prefix Suffix Compression Coding. Prefixes and suffixes compression
code the word in some manner. For example, the Time Code '-ed' adds the 'past
time' concept to an action word. For example 'walk' = do & move & travel &
walk.
'Walked' - with the addition of the '-ed' suffix, codes the additional concept
of
'past time' into walk., to give 'do & move & travel & walk 8~ past time' per
the Co-
Reducing Concept method.
5) Operator Compression Coding. Operator Words can act to select
different meanings of a word - as in the example of the word 'dogs' given in
the
summary.
6) Context Compression Coding. Proximity Coding is defined as
'something outside the Statement where the word occurs, codes the meaning of
the word to be used.' This is the case with the word 'roam' as used in
connection
with telephones, where the mention of 'telephone' - or some equivalent of
telephone such as 'mobile' - may occur at a considerable physical distance in
the
text from the use of the word roam.
It is a fundamental teaching of the Any-to-Any machine that software can
identify the specific meaning of a word in use, provided that there is a rule
that
102
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
software can use to detect which meaning to use. It is a further teaching that
a
rule can be created provided there is at least one characteristic of the
meaning
that is detectable. Finally, it is also a teaching of the Any-to-Any machine
that if
humans can identify a specific meaning that is use, then at least one
characteristic
of that meaning exists to distinguish it from all other meanings. The final
teaching
in this respect, is that the rule can be detected with proper observation and
testing.
Applying and giving an example of this teaching with the word 'roam. The
identifiable characteristic of the word 'roam' that sets the telephone
meaning, is
the use of the word 'roam' nearer to words that in some manner indicate
'telephone' than to words that are names of other things that have the
capacity of
movement. This characteristic is demonstrated in the in following pair of
examples:
'Roam. Yes Roam. The dog is in the garden - he loves sniffing
plants. My telephone is with me, a good companion, just like my dog.'
'Roam. Yes Roam. My telephone is with me, a good
companion, just like my dog. The dog is in the garden - he loves sniffing
plants.'
1n the first example, it is clear the dog is doing the roaming, and in the
second, it is equally clear that the telephone is doing the roaming. This
shows that
it is the relative proximity of the word to a word for something that has the
capacity
to roam that sets the meaning of the word to use. This is type of Context
Compression Coding called 'Relative Proximity Compression Coding' - there are
other types of Context Compression Coding also.
In this example, the detection of the characteristic - the relative nearness
of the word 'roam' to something indicating 'telephone' that is the basis of
the rule.
The Concept Hierarchy for 'roam' is 'do & move & travel & roam' and
contains no mention of telephones However, the definition (given in an earlier
example) does contain mention of 'telephone':
'Roam(m)' =telephone & mobile & connected & outside & service & area & pay
Because of this, the particular meaning (Concept Symbol or Concept
Statement) to use for a word that has Context Compression Coded meanings can
be detected provided that:
1 ) The definition of the word is recorded.
103
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2) The rules used by the word to detect the particular meaning
contain the necessary steps to use the Concept Definition of the word in its
Context Compression Check.
3) The Context Compression Check is performed after the
remainder of the text has been processed into Concept Language. The reason
for this is that 'telephone' (in this example) can be referred to in a
considerable
number of ways. 'Ring Joe' after translation into Concept Language will
appears approximately as 'Telephone Joe.' A Context Compression Code
check done on text that has not first been translated into Concept Language
will probably fail. It will certainly fail if the user says 'Ring Joe's
roamer.'
However, if translated into Concept Language first, as 'Telephone Joe's
roamer' the Context Compression check will find 'telephone' and hence use the
telephone meaning of roam, look for a thing to telephone, find 'telephone &
mobile' in the definition, and come up with a final command of: 'Telephone
Joe's Mobile Telephone.' The command will succeed providing the execution
software has contains suitable processing rules. (The Data RElation Table has
such rules). (Note that the word in this example is 'roamer' not 'roam' which
is
a different word used in the example of Relative Proximity Compression
Coding. Each word has its own rules that state how its meaning is determined
and the rules are not the same for the two words).
Hence, Concept Definitions (definitions of word in Concept Language)
are needed for Context Coded Compressions, as well as for other operations,
such as
the example given in the summary of one person saying 'Oh!' and another asking
if
that person was surprised.
27) Step 8: Review all Alternates
Expand the Concept Statement of each one to distinguish them from one
another. The two types of Data Class feature that generally distinguish
between
Alternates are:
1 ) Formality. Some words and word combinations contain a concept
compressed into them of formality or informality - for example 'Silence
please' is
more formal than 'Shut up,' but often means the same thing. Including the
formality and informality of specific words in their Concept Language
Statements
enables a "Formality' Data Class to be included and this lays the groundwork
to
enable a computer to be able to 'talk' or give messages to the user more or
less
formally.
104
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2) Contractions. Contractions are an informal alternate, and are therefore
only dealt with at this point. When un-contracted, their Concept content is
almost
identical to their uncompressed counterparts - and these will already have
been
assigned Concept Symbols or Statements in earlier steps. The difference
between the contraction and the un-contracted versions is the relative
formality of
the two. This can be useful if the Formality Data Class is in use.
3) Emotional content. Some words contain an emotional concept as part
of their meaning and if the Data Class of Emotion is used, the Concept
Statement
can include the appropriate Concept Symbol for the emotional concept of the
word
in that use. This lays the groundwork to enable a computer to give emotionally
appropriate responses to statements addressed by the user to the computer. For
example, if the user says "Damn you!' to the computer, part of those words is
a
concept of emotion - anger. If anger is detected in the user's statements to
the
computer, this enables responses to be programmed such as ' I'm sorry, what
did I
do wrong?' rather than 'Glad you like how I printed your letter.' Similarly,
some
words such as 'dead' especially in combination with values from specific Data
Classes such as Life - 'the cat is dead' have a very distinct emotional
content. If
this is record in the Emotion Data Class, it enables programming to ensure the
computer comports itself appropriately.
The following steps apply to Operator Words only:
28) Step 9: Classify Operator words into different Types
Concept Symbols or Concept Statements for the meanings of single words
(Meaning Words) can be put into Concept Language without needing to deal with
Operator words. However, operator words should be dealt with before phrases
with
special meaning can be translated into Concept Language Symbols or Statements.
Operator words are the most difficult to deal with and therefore a useful
method is to
handle Meaning Words first as per the previous steps.
29) Step 10: Create and Test Meaning Detection Rules.
The next step is to develop the rules that detect which of the meanings to use
for a given spelling of a word that has several meanings. Meaning Detection
Rules
are partly composed of rules applying to individual words, and partly of
Operator
Rules. These rules interact, and because of this their effect rapidly become
extremely
complex, and in order to be sure they are correct, their affect should be
tested on a
wide variety of texts, preferably using software designed for the purpose, and
individual rules adjusted as desired.
30) Step 11: Create Operator Rules
105
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Operator Rules are the rules concerning Operation Words. They first of all
detect which 'meaning' of the Operator Ward to use. In the case of the
Operator
Word, the 'meaning' is at least partly an operation that is performed on
another word
or words, and enables those other words to be correctly translated into
Concept
language. In the same manner as every meaning of a meaning Word should be
found, so should every 'meaning' - every operation - of an Operator Word be
found.
If the operator word only performs operations and has no other meanings, then
each
meaning requires at least one rule to detect that that meaning is in use, and
another to
perform the operation that is that meaning. If an Operator word also has a
meaning
like that of a Meaning Word, then that meaning is handled as for the Meaning
of a
Meaning Word.
31 ) Step 12: Translate Phrases and Colloquialisms into Concept Language.
At this point, each separate meaning of the words to be used in the Concept
Language has its own Concept Symbol, or Concept Statement, and no two Concept
Symbols and no two Concept Statements are the same. The next step is to
translate
phrases that have a specific meaning appropriate to the application, and
colloquialisms appropriate to the application into the Concept Language. This
is done
using only existing Concept Symbols or Concept Statements as elements. The
meaning of the overall phrase is translated, not individual meanings of the
words that
are the elements of the phrase.
The above steps complete the steps needed to create a Concept Language and
provide a language into which a spoken language can be translated such that:
1 ) Every 'word' (Concept Symbol) or statement (Concept Statement, a
selection of Concept Symbols) in the language has only meaning, and so that
2) All the same meanings in the original language have only one Concept
language Symbol or Statement.
32) Step 13: Create Concept Language Output Phrasing Rules
These are rules that state how single and multiple Concept Statements are to
be made in the Concept language. Their exact nature depends entirely on the
software that is intended to execute them. In effect, the Concept Language,
and the
associated software to control execution have to operate as a matched pair.
(This is
the case with the Data RElation Table). This Any-to-Any machine is the
Language
Processor, and is an input mechanism for something else - the associate
software.
Hence, this step - Create Concept Language Output Phrasing Rules - is the
steps
that matches the Language Processor with the software it is required to feed.
33) Types of Understanding Computers.
106
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The above are the steps to complete a Concept Language that can translate any
data
into Concept Language, whether this is original data or a query concerning
that data. There
are four levels of Understanding Computer that can be created and the choice
of which level
of Understanding Computer to implement depends on what the computer is
required to do,
particularly on whether or not the computer is required to speak or not. The
decision on the
level of Understanding Computer to implement governs the choice of the depth
of Concept
Language to be built using these teachings and whether the remaining step is
required. The
options are repeated and summarized here together as they can now be explained
more fully
and the relationship between them can be seen more clearly. Language
processing can be
integrated at any of the following levels:
1 ) Control only computer. Requires a limited Concept Language built
from a vocabulary based on the actions that the machine is required to
control,
plus small General Use Words vocabulary, as described earlier for a telephone.
The vocabulary and hence the Concept language is set by the actions of which
the
machine or computer itself is capable. This level of Understanding Computer
can
be controlled using Normal Language, but all its responses should be pre-
recorded, and it's searches for Content will be no more accurate than now
exists in
the state of the art. It can however identify items accurately, but the style
of the
content search used as part of the identification will be no better than the
state of
the art. This computer can accept orders in any machine-readable format such
as
keyboard, Mouse, Touch-screen, Voice (if Voice Recognition software is
installed)
e-mail, fax (if Optical Character Recognition is installed) or by telephone
(if
Telephone Voice Recognition Software is installed).
2) Fully Understanding, non-speaking Unspecialized computer. In this
option, a Concept Language is built from a full General Use Word vocabulary,
and
all data going into the computer or created with it, is translated into
Concept
Language and stored as Concept Language. This enables any text to be
searched with precise accuracy, and actions performed on the basis of search
findings. Text needs to be recorded in both Concept Language format and normal
format as this level can not re-format Concept Language into English or
another
language. User messages should be pre-recorded.
3) Understanding, Speaking Computer. This is an Understanding
Computer that can reply in a Normal spoken Language, composing its own replies
in Concept Language and re-formatting them into English or another language.
If
text to speech software is installed, this,computer can 'talk', and speak its
replies
and messages; otherwise it can output them to the screen or a printer or by
7
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
electronic transmission. Does not require user messages to be pre-recorded, as
messages can be composed based on rules. Can answer questions on recorded
text. Does not require original spoken language text to be recorded, as it can
reconstitute this from Concept Language.
4) Specialist Computer. To any of the above, can be added any number
of additional vocabularies, (and associated software modules) to enable the
computer to 'understand' and act in an unlimited number of specialties such as
accounting. Different peripherals can be added, each with their Concept
Languages. In its most advanced form, Concept Language enables such a
machine to control and perform as a robot capable of manual tasks such as
house
cleaning.
If the computer is not required to 'speak' -i.e. not required to translate
Concept Language back into a normal spoken language, then the following step
'Create Compression Rules' is omitted, as Compression Rules are the rules that
turn
Concept Language Statements back into compressed, spoken or written language
X.
34) Step 14. Create Compression Rules.
Compression rules reverse the effect of the different types of De-Compression
described above, and enable the computer to translate data in Concept Language
format into normal spoken language and supply this to output mechanisms such
as
screen, printer, text to speech etc.
While the Compression Rules can turn Concept Language held in the
computer back into the same language X in which the data was entered, nothing
stops
the recorded Concept Language being processed with the Concept Language and
Compression Rules of Language Y. Hence the input can be in one language, or
many languages, and the output in one language or in many languages, provided
the
Concept Languages and Suitable Compression Rules exist.
35) Step 15: Create a Number Concept Language - apply the Unlimited
Principle
Creating a Number Concept Language that is easy and fast for
computers to process is a manual process as it should be done intelligently
and can
not be done purely mechanically, on the basis of one Concept Symbol one
number.
A useful method for creating a Numbers Concept Language is to use a
Compound Number, in which specific positions in the number refer to one thing,
while
other positions in the number refer to something else. For example, supposing
that a
number is twenty digits tong. The first digit can be the number of the Data
Category,
the next three digits are the number of a Data Class, and so on.
1o8
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
36) The Unlimited Principle
However, in assigning such numbers to Concept Symbols in a Concept
Language there is one extremely desirable teaching and method of the Any-to-
Any
machine that is part of enabling a computer to Computer to Understand, and
preventing it from understanding if it is not followed. This teaching is
seldom followed
in the state of the art, and the failure to do so, quite by itself, blocks the
creation of any
Understanding Computer. This teaching is as follows:
Humans are not limited in any way in their capacity to think and. devise
concepts, and if a Computer is to Understand, it can not be limited either and
should
be able to track and record whatever a human can put into it. This is referred
to as
the Unlimited Principle and the application of it enables a computer to follow
the
human and not impose arbitrary limits on him simply to make programmer's life
easier.
Violating the Unlimited Principle can have small, or disastrous and even world-
affecting results - the Y2K problem, for example, is a problem that results
from
violation of the Unlimited Principle. At minimum, violations of the Unlimited
Principle
cause the user problems, and results in a computer that not only does not
understand,
but in a computer that can not understand.
The Unlimited Principle is stated as:
A computer, within the limits of the capacities of its hardware, should
never limit a user in a manner that he does not limit himself.
For example: software that contains a place for three phone number per
person only, or only 3 e-mail addresses can be made to 'understand' - provided
that
there are not four phone numbers or four e-mail addresses for that person. If
there
are four e-mail addresses, the simple inability to be able to enter only that
fourth e-
mail address has the capacity to half the entirety of the remainder of the
computer's
understanding. For example, supposing a person called Joe already has three e-
mail
addresses recorded and now e-mails the user from a fourth e-mail address, and
this is
not recorded because there is no open field in which to record it. Any action
requiring
that fourth e-mail address will fail. Supposing that the fourth e-mail address
was in
another country because Joe is abroad, and the user says 'Send an e-mail to
Joe's
latest e-mail address saying 'send to all our clients latest e-mail address
this 10°l0
price reduction notice.' Joe's copy goes toe-mail address number 3, not e-mail
address number 4. The computer can not alert the user to the mistake as - as
far as
the computer is concerned - it has not made a mistake. When the user
eventually
finds out Joe's fax went to the wrong place, his confidence in the
Understanding
Computer will evaporate as he will never be certain if it has made a mistake
or not.
109
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The usual solution of someone confronted with unreliability of execution is to
do it
themselves, 'then I know it is done right' and the Understanding Computer will
sit on
the shelf. Failure to apply the Unlimited Principle effectively dis-enables an
Understanding Computer.
In creating a Numbers Concept Language, obviously the number of digits
assigned to any particular series of items is chosen to be large enough for
any
conceivable need. But the need that is conceivable today is not necessarily
the need
that is conceivable tomorrow, and therefore, the following Unlimited Principle
Method 1
is applied:
The Last Number in a series may never be used by a Numbers
Concept Language. A 'Last Number' is defined as the highest possible
number in a number series. For example, the Last Number in a series of two
digits is the number '99' or in a series of three digits is '999'. This Last
Number
may never be used in a Numbers Language, as it is reserved for associated
software to use as an alert that a number series is full and a new series,
joined
to the old series, should be begun in some manner.
37) Step 16: Create a Number Concept Language - Assign numbers to
Concept Symbols and Statements.
A unique number needs to be assigned to each individual Concept Language
Symbol. Concept Language statements a not assigned symbols but are composed of
Concept Language Symbols.
Concept Hierarchies are assigned numbers with a particular method that
facilitates processing them. A Concept Hierarchy for a given word consists of
several
words in Language X Concept language. For example, the word 'fly', as given in
previous examples, has the Concept Language statement of:
Do & move & travel & fly
Supposing that the Number Concept Language number assignment for
the individual words in the Language X Concept Language is as follows (spaces
are
inserted only to assist understanding):
Do - 4
Move - 444
Travel = 4 44 199
Fly - 4 44 199 3416
Then the Number Concept Language for 'fly' is created by stringing
together the numbers for the Concept symbols composing its hierarchy, as
follows:
4 44 i 99 3416
110
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
This numbering system implements the Co-Reducing Principle Method
in the Number Concept Language.
As an example, if the user queries 'what did Joe do?' the query
translates into Number Concept Language as 'What did Joe 4?', and any value in
the
Data Class that begins with 4 is an acceptable answer. If the user asks, 'how
did Joe
travel?' this translates to 'How did Joe 4 44 199?' and any value in the Data
Class that
begins with 4 44 199 is acceptable.
The final step in creating a Concept Language is to designate the format in
which the
Concept Language will be output to the software that is to use it, as follows.
38) Step 17: Creating a Concept Language. Format of Concept Language
Output.
Concept Language output can be formatted in a number of ways depending on the
purpose for which it is required. The following are two examples of useful
ways of formatting
the output:
39) 1. Data Class Format Output Method
The Data Class Format Output Method is useful method to output Concept
language to enable a computer to select documents or peripherals based on a
human's Unique Data Specification. In that type of application, a single
document
(or peripheral) can have a large number of values from different Data Classes
associated with it. Software can generally perform simultaneous searches on
several fields at once, but can not usually perform several searches on a
single
field simultaneously. For this and other reasons then, a userful method is to
record afl Data Class values that are available for each computer event in a
database field of their own. Then, a simultaneous selection of a number of
values
from different Data Classes can be used to identify the document. This is
possible
provided that the document content itself (which is anyway Data Class itself)
is
either recorded in its own field in the same record, or, a disk reference to
it is in the
field for the 'Content' Data Class.
In Data Class Format output, the values in each Data Class are held in
each in their own field in a database table, and the Concept Hierarchy is
retained
in the logic with which the Database table is queried. To give a simple
example of
this, using the Concept Hierarchies for the actions expressed by the words
'print'
'screen', 'bold', and 'italics' whose Concept Hierarchies are:
Do & Output & Print Do & Appearance & Bold
Do & Output 8~ Screen Do & Appearance i~ Italics
111
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
In a Database, two Tables can be created, named 'Output' and
'Appearance' and the appropriate values placed in them:
Table 1 (Output) Table 2 (Appearance)
Print Bold
Screen Italics
These tables are called 'Data Class Tables' and serve as a reference to
which Concept Symbols - such as 'Print' 'Bold' - apply to which data Classes.
A third table can be created, of a special type invented by the Data
RElation Table called a "Data Relation Table' has fields corresponding each of
the
two tables mentioned above.
When a document - document X - is output to the printer (for example) a
new record is created in the Data Relation Table, and, using the Data Class
Tables, the appropriate Concept Symbols are placed in the appropriate,
corresponding field new Data Relation Table record. Hence the new record would
contain the reference number of document X in one of its fields, and an entry
'print' in the Output Data Class Field of the Data Relation table Record
corresponding to Output Data Class Table, Table 1 above.
When the user issues a query for the Action Data Category, such as 'what
did you (the computer) do?' the Rule for the word 'do' as a query will state
that the
Data Relation Table fields corresponding to both Table 1 and Table 2 should be
queried. (Both tables are members of the Action 'do' category). The query will
find the value 'print' in the Data Relation Table Corresponding to Table 1,
and no
entry in the field corresponding to Table 2, and will also find the reference
to
Document X in another field. Consequently, it returns the value 'print' as the
answer to the user's query 'what did you do?' It can equally well return the
value
'print(ed) Document X' as Compression Coding rules would state that a past
time
'do' requires past time coding for the word which is print + ed. Or equally,
depending on the mariner the programmer arranges it, the computer could reply
'Print' and if further queries - 'printed what?' could reply 'Document X.'
Concept Language output in Data Class Format for common office
applications can use between two and three hundred Data Classes. The decision
on what Data Classes to include as separate fields, and which to code into the
logic is a question of optimization for the particular application. If two
Data
Classes are recorded in one Data Relation Table field - for example by coding
them with a single digit distinguishing the two, this can lead to a single
field
112
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
needing to be queried twice. 4t can also lead to a pair of Data Relation Table
Records being required to record a single event. Hence, deciding whether to
apportion the designation of a particular Data Class to a Data Relation table
Field,
or to the recording and query logic is a question of optimization for the
individual
application. The Concept Language output is natively coded for its Data Class,
and the associated logic programmer can use this coding in the manner he feels
is
most suitable.
40)2. Free Form Output Method, Enabling a Computer to Answer
Questions about Recorded Text
Data Class Format output efficient output for locating items, but is
relatively
inefficient for large blocks of text where each sentence or phrase does not
contain
values from many different Data Classes. For example, every computer event has
a Time value from the Time Data category, and that Time should be recorded as
it
may be part of a reference to an item. People frequently use time as a
reference
'The thing I printed after I sent an e-mail to Joe' One item - the e-mail sent
to Joe
- is used to identify another 'the thing I printed'. 'The thing I printed'
could identify
thousands of documents, but the statement is made Unique by giving it a Time
Specification. The time identification of which thing that was printed is
required is
expressed as after (i.e. later than) then time of the referenced event (sent
an e-
mail to Joe). The times of both events have to be recorded
However, recording a long text in Concept Language in a database format
allowing for large numbers of simultaneous Data Classes results in most of the
fields being empty when recording a block of text, and hence is an inefficient
way
to store the data. In a block of text, for example, there may be only one Time
entry for the entire block and hence - if the text is recorded in Data Class
Format -
every Time Data Class field will be empty except for one.
In the case where a large block of text is to be recorded such as the
contents of a letter, a report or a book, the Free Form Output Method for
Concept
Language can be a more efficient method to output Concept Language and
enable an Understanding Computer to query accurately large blocks of text.
In the Free Form Concept Language Output Method, the text to be
recorded is converted to Concept Language and then stored in a block in
whatever
sequence it is produced by the translation process.
To give short and incomplete example of this with the purpose of explaining
the method generally and without detail, suppose that a Chapter in a book
begins:
113
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
'In 1982, Joe Brown'...... and then, several paragraphs later it continues 'He
flew
to New York ...'
Some of the Concept Symbols appearing in the Free Form Concept
Language text would be
1982 coded as a time 21982 ( Number of
Data Category for Time is #2)
Joe 112313 (number for the word 'Joe' in the first name Data Class.
The leading number '1' codes for the first, 'Life' Data Category, and 11 codes
for the first Data Class in that category, i.e., the First Name data Class.
3213
is the number assigned to the first name Joe. If 'Joe' were in this instance a
Last Name, the number 122313 might be assigned indicating that this 'Joe' is a
Data Class Last name = 12 type of Joe. Following this type of numbering
procedure enables all instances of 'Joe' to be found, while still knowing
whether the particular Joe that is found is a First, or a Last Name).
Brown 128919 (number for the word 'Brown' as a member of the Last
name Data Class)
Flew 4 44 199 3416 2 (as per the example given earlier for the
Number Concept Language reference for 'fly' with the additional digit (2) to
show this action was in past time.
New York 398989 (the number assigned to the City name 'New
York' (a leading '3' is the code for the Space (Location) data Category).
Then the above two groups of words expressed in Free Form Number Concept
Language would appear as follows:
In 1982, Joe Brown He flew to New York
21982 112313 128919 112313 118919 44419934162 398989
(Associated software gives people numbers. Thus Joe Browns number might be
6143, the leading digit '6' indicating that this is a software assigned code.
Joe Brown's
number would also have its definition recorded i.e. 6143 = 112313 128919, in
which case the
above would appear as:
21982 6143 6143 44419934162 398989)
Referring now to the original example, where Joe Brown's name is not further
coded
by software a user might query the recorded text as follows:
Question Concept Language query phrasing Query response
What did Joe do? i 12313 4? (Joe do?) 4441993416 (flew)
W here? 118919 4441993416 3? 398989 (New York)
114
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
When? 441993416 2? 21982 (1982).
This example is simplified and omits the actions of operator words 'in' 'to',
as Operator
words have not been fully described yet. ('He', for example is an Operator
Word whose
Operator Rule results in 'he' being replaced with the previous male name
found. The method
used to formulate Free Foi~mat query rules, so that they look for the data in
the right place in
the text, will also be described later). Effectively, the combination of the
other methods of the
Any-to-Any machine, together with the Free Form Output method, enables a
computer to
search for meanings. In the start of the art, searches can only be done for
words, and most
words have multiple meanings. Hence, in a state of the art search, the user
wants one
meaning, specifies it with words that have multiple meanings, and consequently
and
inevitably, receives back every item that has any of the multiple meanings of
the words he
uses. The benefit of the Any-to-Any machine's method is what the user says is
translated
into a string that contains only the meaning he wants, and this string is used
to search text
that is in a format where every meaning is represented by only one string.
Consequently, the
query string, with its single meaning, can be 100% matched with every
occurrence of that
exact string (with only one meaning) in the recorded text. Consequently, the
search finds the
meaning he wants, no matter the original words used to phrase it. In essence,
a user's multi-
word query - a sentence for example - has only one meaning for him, but
several meanings
for the computer, and hence produces several results, not the one result he
wants. With the
method of Concept Language the user's multi-word query with one meaning, is
transformed
into a Concept Language text with only one meaning. That meaning is defined by
the Co-
Reducing Concept Method of the various Concept Symbols in the Concept Language
query
text. Hence, a Concept Language Query running against a Concept Language text,
is
actually querying with symbols AB (that have a meaning XY for the user) to
locate symbols
AB (that represent the meaning of XY for the user).
Free Form Concept language output is desirable to enable a computer is to
answer
questions on stored text, and also to be enable a computer to perform
operations reliably
based on stored multi-line, multi-page and multi-format texts. The order 'send
this e-mail to
everyone who contacted us saying they thought our new Model X is great' is an
example of
an execution that is based on the content of stored texts. Such text would
need to be storied
in Free Form Concept Language in order to be sure of correctly executing an
order requiring
a search of text for meanings, as opposed to a state of the art search for
multi-meaning
words.
115
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
41 ) image Concept Language is a key enablement for a robot to act on
human instructions
The teachings of this Any-to-Any machine can also be used to enable a computer
to
handle data other than words, for example, images such as photographs or maps.
Any
image can be described in words, and some software exists and other software
can be written
quite easily that automatically describes the components of any image in
words. The words
used can be translated automatically into Concept Language by associated
software, and
then if suitably recorded, for example in Data Class Output Format Method, the
words
become a reference to the image. Software exists in the state of the art that
can recognize
images - for example the images of a street as a car moves down it - and this
recognition
also can easily be turned into words, and from words into Concept Language.
Data Class Output Format includes provision for all five data Categories
(Life, Time,
Space, Energy and Matter) and a Data Relation Table relates these to one
another for each
object, or event. Consequently, Concept Language is the key element enabling a
computer
to manipulate images and movements based on a user's instruction. If these
technologies
are united, a command such as 'get me the milk from the refrigerator' becomes
possible.
'The refrigerator' has a Concept Language equivalent. That Concept Language
equivalent
can be matched to an image and the coordinates of that image - the coordinates
of the
refrigerator - recorded in the 'Space' Data Category of a suitable Data
Relation Table. If the
computer is provided with a means of localizing itself - such as a form of
GPS, or reference
coordinates within a building, then calculating the motor inputs required to
make the two
coordinates coincide - to get the computer to move to the refrigerator is
relatively mundane
programming. Identifying a door handle, or making movements to open a door,
are simple
extensions of the same principles. But none of this can be enabled usefully,
in the absence
of the ability enabled by Concept Language, to relate directly, a user's words
with an image.
A Concept Language can be related to images through the intermediate stage of
words, or can be enabled to translated directly to a Numbers Concept Language.
In this
manner, Image X is Number Concept Language 5414, and 5514 can be output either
as a
word "refrigerator' or as an image. In this manner, images can also be
created, combined,
transformed and otherwise manipulated using Normal Language words. A computer
is then
enabled to perform commands, such as the following,: 'Make me a photograph of
a garden,
with a swimming pool in it. Make the swimming pool wider, and make the water
blue. Empty
the swimming pool.'
The Concept Language definition of a word - for example 'Table' - will be the
Concept
Language equivalent of a definition such as 'a table is a flat surface that
..... etc.' This
definition can be expressed as a Data Relation Table record or records. If the
definition is
116
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
sufficiently precise, a computer provided with visual imaging equipment can
continually run
the physical specifications of perceived images against the Data Relation
Table records that
define objects, and, if enabled for speech, thereby describe what it sees
using normal spoken
language. Equally, it can localize itself in a building by comparing the
identified objects, to
Data Relation table records for the Location of such objects. Hence, it can
move around,
knowing all the time where it is, by reference partly to where it was, and
partly to the objects
now visible.
42) Types of Concept Languages
A Concept Language that relates Concept Symbols to images following the
teachings
and methods of this Any-to-Any machine is termed an Image Concept Language. A
Concept
Language that relates Concept Symbols to sounds is termed an Audio Concept
Language. A
Concept Language that relates Concept Symbols to spoken Words, Sounds and
Images and
numbers, is termed a Full Concept Language.
The methods of the individual steps for creating a Concept language will now
be
described in more detail, beginning with further requirements for a Concept
Language.
~ Creating a Concept Language. User Requirements for a Concept Language.
When Voice Recognition software becomes good enough, orders to understanding
computers may often be given verbally. While a written order given to a
computer may often
be grammatically correct, there is no guarantee that verbal orders will also
be grammatically
correct. But whether giving a written or spoken order, no user wishes to be
interrupted by the
computer refusing his order due what it considers to be grammar or spelling
errors.
Therefore, Concept Language should be so constructed as to accept spelling
errors
and grammatical errors, rather than requiring the user to correct these.
However, when the
Concept Language does this, spelling errors may occasionally cause wrong
execution.
Therefore it is axiomatic that corresponding execution software should be able
to cancel or
revert any action that can be cancelled or reverted; in any case the user
expects such a
capacity, just as he would in the case of a secretary. (That capacity is
included in the Data
RElation Table).
The general method of this Any-to-Any machine for handling spelling errors is
1 ) To provide for common misspellings in the Concept Language
2) To provide in the accompanying software executing the translation
rules (such as the Data RElation Table) for incorrectly spelled words to be
set as
equivalents of their correctly spelled equivalent.
Incorrect grammar is not a problem with Concept Language since translation
from a
spoken language to a Concept Language does not take any account of grammar,
and
117
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
therefore conformity with grammar is not a requirement for Normal Language
input. When
using a Concept Language,the effect that is that something that is
comprehensible to a
person is comprehensible to a computer. However, people do not say things that
make
sense, and the accompanying software using the concept Language should be able
to check
for sense, and query non-sense, just as a human would. Non-sense essentially
defines as
specifying something that can not be done, or data mismatches - for example
when the user
specifies one item but the logic finds several. Part of the enablement to
check whether
something 'makes sense' is built into a Concept language with its use of the
Complete
Statement Method, and the CanDoCan't method - the name for the method used to
record
what an object can and can not do.
The remainder of the enablement to check for non-sense is the province of the
accompanying software, which should be built to use the Complete Statement and
CanDoCan't methods built into Concept Language.
Similarly all punctuation that is undetectable in spoken Normal Language input
is
ignored when translating into Concept Language (but not ignored when
translating from
Concept Language to written spoken language).
The Steps that enable a Concept Language to be built will now be described in
further
detail.
~ Step 1 Select a Suitable Vocabulary
A vocabulary can be selected as described previously for simple applications,
by
reviewing what the application will have to do and selecting a vocabulary
based on that. Even
so a considerable number of General Use Words are required. Alternately, large
numbers of
texts on a subject can be taken, and software used to remove all duplicate
words. The result
constitutes a vocabulary for the subject concerned, and this method is useful
for specialized
vocabularies for specialized subjects. Further, software can be used to remove
all words that
already exist in another generalized vocabulary, leaving only the words
needing to be added
to make the specialized vocabulary.
A useful method for selecting a General Use vocabulary is to begin with a
large
dictionary, preferably in electronic form, and place this in a database, where
it can be
manipulated.
Selecting the vocabulary to use is then a mechanical process of going down the
list of
words one by one and marking those to be used. Words not included at this time
can be
added later.
~ Step 2 Divide the vocabulary into Meaning Words and Operator Words
If the vocabulary has been placed in a database Meaning Words can be found by
asking a series of questions of each word:
118
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data Category Life:
Is this a name of something?
Is this a quality?
Is this en emotion?
Is this a body of knowledge?
Is this a word of reason?
Is this a Name of a person?
Is this a name of a group of people or type of group of people?
Is this a form of non-human life?
Is this a type of decision
or status (for example} 'complete'
Data Category Time
Is this a word to do with Time?
Data Category Space (Location)
Is this a word to do with
- a location?
- an address?
- something at a location? (telephone number for example)
Data Category Energy (Action)
Is this something that someone or something can do?
Can I (word x)?
Data Category Matter:
Can this been physically seen, touched or measured?
These and similar questions will find words that are Meaning Words, and those
that
are left are generally Operator Words.
it is advisable to mark each meaning word found with the Data category to
which it
applies. A typical numbering scheme for doing this is:
Data Category Number
Life 1
Time 2
Space 3
Energy 4
Matter 5
119
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
~ Step 2 Divide the vocabulary into Meaning Words and Operator Words - Data
Category Confusion
As the process of assigning words to individual Data Categories is continued,
it will be
found that this rapidly becomes confusing, because many words with identical
spellings can
be found to belong to more than one category. 'print' can be an action ('I
print the letter') or a
thing (Get me the print.') When this occurs, the word is assigned to both Data
Categories.
The fact that the word can be classed in two or more Data Categories is a sure
indication that
it has at least two different meanings, and each one of them should be given a
different
Concept Statement. The fact of assigning the same word to two different Data
Categories is
a first step to achieve the part of the objectives of a Concept Language -
that each individual
meaning has its own Concept Symbol or Concept Statement. Assigning the two
meanings to
different data categories gives each of them a different Concept Statement
(the Data
Hierarchy of a word is part of the Concept Statement for a word):
Print, the thing, now has a Concept Statement is now: Matter & Print
Print, the action, now has a Concept Statement is now Energy & Print.
The Meaning Rules, to be described later, will determine which of the meanings
is in
use in a specific and therefore, which Concept Statement is to be recorded.
This example also demonstrates the Any-to-Any machine's teaching that a
language
can be made usable by a computer if it viewed as compression. The reality is
that when a
person says 'I print the letter' there is a something in the sentence - other
than the word
'print' itself - that is stating that 'print' is an action not a thing. That
something is a detectable
characteristic and any detectable characteristic can form the basis for a rule
that software can
use to determine which meaning is in use.
~ Step 2 Divide the vocabulary into Meaning Words and Operator Words - Inter-
relationships of Data Categories, Compression Coding of Space/Matter Data
Categories
A further source of confusion when attempting to assign words to Data
Categories is
provided by the inter-relationships of Data Categories.
The physical universe consists of Matter, Energy, Space and Time, and together
with
this is the category of Life, and it is a curious phenomena that all words
other than Operator
Words will fit into one or more of these categories. As stated previously the
behavior of those
words that are to do with the physical universe mimics the behavior of the
physical universe
itself.
43) Space / Matter Word Compression
All physical universe phenomena always have a time and a space (location), and
thus
a reference to one is a reference to the other. In practical terms this means
that a particular
word with a given spelling whose meaning appears to classify it one Data
Category, often
120
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
appears to classify in another data Category also, but the different meaning
for the other data
Category is semi-invisible and hard to detect.
A prime example of this phenomenon is that words with a meaning of Matter are
often
used as words with a meaning of the Space Category - Location.
For example 'go to the house', 'go to the chair' 'move over to the wall.'
Houses, chairs
and walls are definitely matter. The physical space in which they exist is a
location, just as an
address is a location. The location of the house chair or wall can be fixed on
a map. A chair
exists and it can occupy an unlimited number of locations.
In fact, the meaning of 'chair' in the words: 'go to the chair' is 'go to the
(location of)
the chair' but the word 'chair' does not always mean 'location of the chair'.
If a person says
'Put the chair in the garbage dump' he does not mean 'put the location of the
chair in the
garbage dump.' Locations are coordinates in space and are not movable. A given
space is
there no matter what names it may be given, no matter what that space
contains, that space
is there and remains there. Thus when a person says 'Put that chair in the
garbage dump',
the meaning he is using is 'thing-chair': 'Put the thing-chair in the garbage
dump.' When he
says 'go to the chair' he is using the meaning 'location-chair': 'Go to the
location-chair'
This is another example of coding that can be treated as a form of compression
in the
language and this type of compression 'ss termed SpaceJMatter Compression.
Effectively,
whether the person is referring to a location or to a thing is not explicitly
stated but is hidden
by the compression mechanism, which conveys the data of thing or location,
without explicitly
stating it. 'Get the chair from the house' is 'get the thing-chair from the
location-house.'
Almost every word whose meaning classifies in the Matter Data Category usually
has
a minimum of two meanings - one as a thing, one as a location. Once again,
which one is in
use is detectable not from the word itself, but from characteristics of the
surrounding text, and
again, a characteristic that can be detected and made into a ruse.
This teaching and understanding of Space/Matter compression is extremely
desirable
to controlling a computer with Normal Language. As an example of this, suppose
that a user
says: 'Put this letter on my portable.' Assume that the computer treats
'portable' as a thing. It
transmits this piece of letter-matter down that wire-matter to that machine-
matter. 'Did you
put the letter on the portable?' the user queries, essentially querying if the
action was done.
Assuming that the action was recorded by software, the receding can be queried
and will
produce 'True', i.e. 'yes' 'OK' the user says, 'where is the letter?' There is
no recording of a
location for the letter, because 'portable' was treated as matter not as a
location, so the
machine replies 'Unknown.'
This Any-to-Any machine teaches that Matter is a reference for Space and Space
is a
reference for Matter.
121
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Matter as a Reference for Space *
Space as a Reference for Matter: *
Hence, there are in reality two meanings for 'portable' as used in this
example. There
is:
Matter & portable
Location & portable
Each meaning has its own Concept Hierarchy. Thus 'portable' has two meanings
and
two Concept Hierarchies - one as a thing, one as a location:
Matter & manmade & computer & portable.
Space & London & office & portable.
Humans give names to all things and these things are one or more Data
Categories,
and hence the name follow the Data Category behavior of that which it names.
For example,
a city can be given a name 'Boston'. As a location, a city is a set of
geographical coordinates,
that has been given a name a name 'Boston.' The same name 'Boston' has also
been given
to the city, a thing, i.e. a collection of buildings, streets and lampposts
all made of matter.
Thus "got to Boston and paint it pink' is in reality 'go to Location-Boston
and paint Matter-
Boston pink.'
Locations (often represented by their names) have their own Concept
Hierarchical
structure, which is normally set by their locations:
World & USA & New York State 8' New York City & Broadway & 1S' St
4tn Floor & Suite 298 & Room 4.
Location Hierarchies enable a computer to emulate human query procedure:
'Vllhere is Joe?' In USA.
'Oh yes? Where?' In New York at Klein & Pinch
Humans generally use the most compressed possible transmission. Hence the
person says 'at Klein & Pinch' - the location name for 'USA & New York State &
New York
City & Broadway 8~ 15t St * 4tn Floor & Suite 298' and does not say 'at
Broadway & First, 5~n
Floor, Suite 298' etc. Hence associated software should execute in such a
manner that when
it enters a company name it enters it into its Concept Language as a name for
a group of
people and also as a name for a Location. Any word - and a name is just a
special type of
word - is treated by the Any-to-Any machine method as a compressed form of its
definition
and this is equally true of a location Name. Thus a Location name - such as
'Klein & Pinch'
or 'the house' - should be treated by a computer as a compressed form of the
actual location
coordinates, just as 'banana' is a name - a compressed reference - for 'a long
tropical fruit
which....'
122
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
In the mind of the person replying to the question, 'Where is Joe?',
relationships exist
between USA, New York, and the Location name for the remainder of the address
given
above. Following the method of this Any-to-Any machine, the functional
relationship that is
evident in the way the human handles location data is expressed in the Concept
Hierarchy for
a word with a location meaning.
Because many words for things or locations actually have two meanings, one for
thing
as a piece of Matter, and another one for the Location of the thing, each
meaning should
have its own Concept Statement. Effectively, two Concept Hierarchies exist for
the two
different meanings of the word. This teaching becomes even more desirable if
the computer
in which the Concept Language is used has any power to control movement, as
for example,
in any form of robot. When that is the case, the orders such a unit will
receive from humans
will require the computer to follow the above methods for treating words for
Matter.
~ Step 2 Divide the vocabulary into Meaning Words and Operator Words - Inter-
relationships of Data Categories, Interaction of Time/Energy Data Categories
The Any-to-Any machine has a number of teachings concerning the interaction of
words with meanings concerning the Time and Energy Data Categories, as
follows:
44) Time / Action Compression
In the English language, Actions (Energies) are often related to one another
by time.
All physical universe actions occur at a certain time. While Matter tends to
persist for
considerable periods of time in the physical Universe, energies in the form of
Action do not.
This phenomenon is reflected in the English Language, as follows:
Words having a meaning expressing some kind of Action (Energy) are time coded,
but
words for all other Data Categories are not time coded..
The word 'walk' has a form 'walked'. From the viewpoint of Grammar, the
addition of
the ending '-ed' turns 'walk' into 'past tense'. Per the teaching of the Any-
to-Any machine,
there is no change to the meaning of 'walk' there is addition to the meaning
of walk - another
meaning is added. The '-ed' that is added is treated as a compression code
(compression in
that it is shorter than the text it replaced) that adds the meaning 'past
time' to the prior
meaning of 'walk'. Hence, '-ed' is a compression code replacement for 'past
time' to give:
Walk & past time
The Location Data Category, however, does not take time codes. There is no
suffix or
prefix that can be added to an address name or any part of an address that
makes the word
into address & past time. Similarly, words with meanings that label Matter
objects do not take
time codes. There is no prefix or suffix that can be added to a word for a
Matter object to
make it into thing & past time. The word 'book' can not take a form - bookque
for example -
that means 'book used to exist'. It is possible to say 'booked' - 'I was
booked' but, again,
123
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
'book' in that meaning is an action and hence takes a time coding. But 'book'
as thing can not
take a time coding in the English Language. When words in Data Categories
require to be
described as having existed in the past, this should be stated using word on
the Co-Reducing
Concept Method. 'It used to be blue' is the Quality (blue) equivalent of
'walked'
The real meaning of 'walked' as 'past time & walk' is an example of two
meanings -
two concepts - existing within one single word. .
That two meaning components - concepts - are now stated by a single word does
not
change the Concept Hierarchy of the original word, which remains the same. The
Concept
Statement for 'walk' is:
1 D 'do & move & travel & walk'
and for 'walked' is:
Time Data Category = past time. & Action Data Category Concept Hierarchy - do
&
move & travel & walk.
Care should be taken to ignore a Grammar view of Words, especially of words
stated
to be verbs when assigning the Time Data Category Concept Symbol to words of
Action,
since Grammar - the state of the art technology for dealing with words - is
often actively
misleading when considering meanings.
'Stop' is considered by Grammar to be the present tense, whereas in fact it is
often
future. Consider the order given to someone 'stop printing': The meaning of
'stop' is future
(immediate future) - the action of 'stop' can not begin until a time later
than the time the order
has finished being given. In fact, the version of 'stop' that is coded for the
Time Data
category value of 'Now' - is 'stopping' - the action of 'stop' is occurring
now. '-ing' is a Time
Compression Code, coding the word to which it is attached for 'Time now'. The
absence of a
time code in the word 'stop' is itself a Time Compression Code for 'time
future' when the
meaning of 'stop' is 'stop' as an order.
Viewed in this light, the command 'stop printing' when decompressed is:
Immediate Future & Stop, Print & Time Now
- and this is the truth of the situation. The person receiving the order 'stop
printing' is
expected, in the immediate future, to stop the printing that is occurring
riow.
The form of 'stop' that Grammar labels as 'future tense' is actually a future
Time
viewed from the point of view of a Time that is already in the future. The
person saying 'I will
stop the printing' is viewing events from the future 'I will..' and from that
viewpoint, viewing the
immediate future. If he were in the process of stopping the printing in the
future, he would
say "I will be stopping the printing' - at the future time, the action of
'stop' will be happening.
Grammar, not having understood that the 'stop' form of an action is actually
future, finds itself
124
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
with two 'present time' senses of the word 'stop', and hence labels one of
them 'present
continuous'.
45) Viewpoints of Time expressed in coding of Words of Action.
A human being can effectively move his point of view ('Viewpoint') in time. A
person
can discuss something, from a number of time viewpoints. He can write, today,
'in 1965, I
thought to myself, 'I am happy'. I really enjoyed the music I was hearing
these days...' From
where his body is - in time now - he is doing something a material thing can
not do, and is
assuming a Viewpoint of 1965- effectively talking as though he is in 1965, and
recounting
the present time events of 1965.
With various combinations of Time Compression Codes, and Operator Words, every
Action word - word with a meaning that expresses an action - can be coded for
twenty-seven
different time Viewpoints. A list of these and examples of each is attached as
Appendix **. In
each case, however the time is coded, it is part of the Concept Statement of
the word
concerned.
This teaching of the Any-to-Any machine is contrary to that of the state of
the art, but
is desirable for the proper functioning of computer control using Normal
Language.
Computers and software are extremely literal. If a computer is told 'stop
printing' and
'stop' is treated as present, software can of course be arranged so that,
receiving the word
'stop' it does the action now. But confusion quickly arises; imagine the user
says:
'Stop printing in five minutes'
The word 'Stop' now should be redefined in software with two meanings:
Perhaps stop now
Perhaps stop in the future if a time is received.
The confusion gets worse when the user says:
'Stop printing five minutes after if f say so'
The meaning of 'stop' and how software is to handle the command is becoming
extremely confusing, and the programming required is also getting complex.
However if 'stop' is handled as future, then the action of the software to
execute 'stop'
can be expressed in words as:
Stop = schedule action for earliest possible stop, unless further time
schedule specification received, in which case, execute as per that schedule.
If the software now receives 'Stop printing in 5 minutes', schedule stop time
is set to 5
minutes. The action of the 'stop' software is not changed. If the user says '
Stop printing 5
minutes after I say so', the action of the 'stop' software module is not
changed in any way.
The scheduler Module sets the time to execute as '1 say so & 5 minutes.'
125
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Effectively, because the programmer understands from the outset that the word
'stop'
applies to the future, the software arrangements to handle the exact
conditions or time of the
future stopping become relatively simple.
Hence it is desirable that the person creating a Concept Language pays great
attention to the correctness of Time Codings with words of action.
46) Actions are related by Time.
Certain phenomena of the behavior of language are matters that can only be
taken
care of by the software that uses the Concept Language. One of these is the
relationship
between words for things, acting as words for Locations, part of which should
be taken care
of by querying software.
Time used to relate different Actions to one another is a further example and
in this
case, the phenomenon needs to be handled wholly in software. While the
following teachings
does not affect the creation of a Concept Language, the person creating or
translating into
such a language needs to understand the mechanism that software will apply to
Concept
Statements created in the Concept Language. A person creating or translating
into a
Concept Language needs to know what should not be included, just as much as he
needs to
know what should be included:
A user says to his computer 'get me the letter f wrote when Joe cancelled his
order.'
The word 'When' questions for a value from the Data Category of Time. The
query
can be broken down as follows:
'get me the letter I wrote at time Value X
Time Value X = the Time value for 'Joe Cancelled his order.'
The two actions (as signified by the words in Italics in the example) are
related by a
common time of their occurrence.
A Location or a Thing is not given as an answer for a time query.
Time Data Category question: 'When did that happen?'
Reply using Data Category Matter: 'When house.
Reply using Data Category Location:'When 24t" Street.'
The only acceptable answers are from the Time or Time referenced by the Time
of an
Action:
Reply from Time Category: 'Easter'
Reply from A Reference Time: When I jumped.'
Note that, although the reply is superficially in the form of an Action, it is
in fact a time,
and is the time at which the referenced action occurred - the Data Class
Integrity Method
holds true.
126
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
As far as computer control is concerned, this means that associate software
should
record every action that occurs and should be recorded with it, the time of
the occurrence of
that action. The Time of any Action may be used to specify the Time of another
Action and
execution software should be able to handle such relationships. For example:
'Get me the e-mail from Joe I sent to Joe while you were printing the letter
to
him'
The two actions (as signified by the words in Italics in the example) are
related by the
common time of their occurrence.
47) Computer Commands, Time & Action, and Execution Conditions
Every order given to a computer by a human is always, and without exception,
for
execution in future time. An order can not be executed before it is received,
and inevitably
therefore, the time of execution is always later than the time the order was
given. An order to
do something 'last week' can not be executed if interpreted literally, only if
it is interpreted as
a colloquial phrase meaning 'as fast as possible.'
Hence a condition for the execution of an order to a computer is always a
condition for
execution in the future. Humans invariably specify conditions for an execution
(which is
always in the future) in the format of an execution that is to occur at such
future time as when
condition X or condition Y or Condition Z exists. Again Time is used to relate
actions:
Time of execution =
Time X exists
That condition can be any combination of anything in any data category from
existing
data or future data or any combination of both:
A simple example: 'When Joe sends me an e-mail, (then at that time) put a
notice in
my Agenda.'
A more complex example:
'When (= at the time that) 20,000 clients have bought product X, (then at that
time) send the advertisement called 'Thank you Clients' to our Ad agency.'
Note that the condition may already be true - 20,000 clients could already
have
bought Product X, but, it is not known to be true.
Thus the Format of a Condition for an execution, in terms of this Any-to-Any
machine's teaching is defined as:
'Two or more actions related by a common time, at least one of which is to be
tested until it is found to be true, and when found to be true, at least one
other is to be
executed.'
This definition of a Condition Format holds true even in complex Conditions:
127
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Send this to Joe when he is Chicago, if it is Thursday, if I am in my office
and if
my wife calls.'
Some of the Actions that are related by common times are themselves Actions of
the
time 'Existing' as an Action, and one of the 'existings' is itself a time.
Thus, in associated execution software, all Actions should have provision for
recording
the time at which they are to be done. This time should be able to set to the
time of another
action, and the existence of that other action should be able to be tested.
(The Data RElation
Table provides for this).
Note on Computer Execution. It is clear that while an order can be given in
Concept
Language such that it is clear and unambiguous and can not be anything else -
for example
'put item X in user's agenda' - the computer can not do this unless it has
software that will do
that action. There should be a software module capable of 'put item X in
Agenda Y'. Thus, to
carry out the orders a user is capable of giving, there have to be hundreds or
even thousands
of software modules that can do the actions ordered, or they will not happen.
The current
philosophy of software construction of millions of line of multi-megabyte code
is completely
unsuitable for this, especially because humans can string executions together
in virtually any
order, with different execution conditions and types of connections between
them, as for
example in the order:
'Increase the font size of the thing Bill sent me, and fax it to Joe. Take the
e-
mail about bananas not apples, color the text red, e-mail it to George and
Jeremy.
Make the text bold in the spreadsheet l finished yesterday, print it, and add
it to the
company report and e-mail it to Jeremy and also put it on my secretary's
computer.
A requirement for an Understanding Computer is that it should be able to do
what it
ought to be able to do. A human expects that if someone knows how to type a
letter, they
can type any letter. He expects that if they know how to make a typeface bold,
they can
make any and every typeface bold. The state of the art philosophy of software
writing, is that
it is acceptable that sometimes a typeface can be made bold and sometimes it
can not,
sometimes a text can be e-mailed and sometimes it can not without additional
steps. This
philosophy dis-enables a Computer that Understands because, as soon as the
computer can
execute steps out of sight, it will be treated as unreliable and not used if
it does something
sometimes, and not at other times. As per the an earlier example, if it is
considered
unreliable it will not be used.
To copy the way a human works, any one execution should be able to be coupled
with
any data on which it ought to be able to act, in any combination that can be
executed. In
state of the art software, the example above would require executions to done
by 1) Word
processing software 4) Contact software for fax number, 2) Fax software 3) e-
mail software 4)
128
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Spreadsheet software and so on. The software to orchestrate just the
combination and
sequences of software actions in the above example would be complex, let alone
orchestrating other possible combinations of executions and specifications of
items on which
to perform executions. Hence, state of the art software, resulting from state
of the art
software writing philosophy, is too inflexible to accommodate flexibility
human requirements.
Unless it is improved the enablements of this Any-to-Any machine will enable a
computer to
understand every order, and perform none of them. .
In effect, The Data RElation Table extends Concept Language expands the
Command
definition of each action word for which a software module exists to execute
that action. This
expansion of the definition is partly in the form of an additional Data
Relation Table record
that states the required condition for a module to operate.
It has been pointed out that words sometimes change their meanings when used
in a
command sense, and the Concept Language should provide these, but should not
specify the
conditions required for execution to occur, as this is the province of
associated execution
software such as the Data RElation Table.
Further information can be found on Energy Data Category (Action) words later
in the
description.
~ Step 2 Divide the vocabulary into Meaning Words and Operator Words - Base
Concepts
A useful method of doing this is to be begin by isolating and marking those
words that
take a variety of forms while still retaining something of the same meaning.
Such words are
called 'Base Concept Words' because they all have a Base Concept defined as
follows:
48) Enabling a Computer to Respond to Queries in a Human Manner. The
Base Concept Method
In the English language, nearly every single word can take a large number of
forms.
Some of these are found in the dictionary, but others are not - even though
they are in current
use and therefore need to be included in the vocabulary of an understanding
computer.
In the Summary, the following incomplete list was given of some different
forms of the
concept 'invite':
Invitation, invitingly, invitational, invitationally, invitee, inviter,
invite, invited,
inviting, invitationable, invitationableness, uninvite, uninviting,
uninvitingly, uninvitabfe,
univitableness, de-invite, de-invitational, re-invite, re-inviter, re-invitee,
re-invited, re-
inviting, dis-invited, de-inviting, non-invitingly, non-invitable, non-
invitableness, non-
invitably, unre-invitable, and so on.
It is clear that no matter what is the form the basic word takes, the concept
'invite' is
still present in all of them. This can easily be demonstrated by
129
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
1 ) Placing the above forms into any sentence or
phrase
i. Jack sent an invitation to Jill
2. Jack looks at Jill invitingly
3. Jack has an invitational attitude to Jill
4. Jack looked at Jill invitationally
5. Jill was Jack's invitee
6. Jack was the inviter
7. Jack, invite Jill
8. Jack invited Jill
9. Jack, inviting Jill...
10. Jack said Jill is invitationable
11. Jack said 'Jill's invitationableness...
12. Jack, un-invite Jill
13. Jack, un-inviting Jill...
14. Jack un-invitingly said to Jill
15. Jack said Jill in un-invitable
16. Jack said 'Jill's un-invitableness is such
that..
17. Jack de-invited Jifl
18. Jack sent a deinvitational letter to Jill
19. Jack, re-invite Jill
20. Jack was Jill's re-inviter
21. Jill was Jack' re-invitee
22. Jack re-invited Jill
23. Jack was re-inviting Jill
24. Jack dis-invited Jill
25. Jack, de-invitiing Jill, said 'it is better
if you don't come...
26. Jack, non invitingly, said to Jill
27. Jack said Jill was non-invitable
28. Jill's non-invitableness was a problem for
Jack...
29. Jack Said 'Jill is non-invitably young for
this party...
2) Taking each of the 30 forms of 'invite' in turn and using it create a
query and then running that query manually against the 30 samples.
It rapidly becomes clear that as long as 'invite' exists in some form in both
the query
and the query text, despite the fact that there are 900 possible combinations
of query and
sample:
130
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- A response of with some value - other than 'Not found' or 'don't know' -
wilt be returned
- If the exact value queried is not present, the nearest available value is
returned.
Hence, it is clear that in a person's mind there should exist a relationship
of some
description between all forms of the word 'invite'.
The method used by the Any-to-Any machine to enable a computer to emulate this
aspect of human behavior is termed the Base Concept Method. _
A 'Base Concept' is defined as:
'That part of the meaning of a word (which takes multiple forms) that is
common to all of the forms.'
Base Concepts have only one meaning, and do not have any relationship of any
kind
with Grammar, or any classification of words in grammar and are not verbs,
adjectives or any
other part of speech. The Concept Symbol of a Base Concept is whoify and only
a unique
symbol for 'that part of the meaning of a word (which takes multiple forms)
that is common to
ail of the forms.' In the case of 'Base Concept Concept Symbol 'invite' this
meaning could be
defined as 'ask & courteous' on the Co-Reducing Concept Method (see later
description for
the Any-to-Any machine's method for defining Concept Symbols).
A useful method to enable Base Concepts to be manipulated is as follows:
1) Each word in the vocabulary is reviewed to find those words that take
multiple forms, while still retaining a Base Concept.
2) Each Base Concept is assigned a Concept Symbol. In the case of the
English language providing the examples for this description, the Concept
Symbol
assigned to the Base Concept of all the above forms of invite, is 'invite'.
The Base
Concept Concept Symbol 'invite' is simply a convenient way of enabling the
Base
Concept concerned to be recognized visually. The fact that the Concept Symbol
for the Base Concept is spelled the same way as the spelling for one of the
English language forms of the word is incidental. One is the Concept Language
Concept Symbol 'invite' and the other is the English Language word 'invite'.
(While this may be confusing, it is less confusing than assigning the Concept
Symbol for invite as 'abtlte' or '34588' for example). Base Concept Concept
Symbols are distinguished by being inserted in square brackets thus: [invite].
49) Enabling Computer to detect Sense and Non-sense. 1. The Complete
Statement Method
~ A computer that is to understand the user and execute Normal Language orders
and
behave in a human manner has certain requirements for which Base Concepts are
part of the
131
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
solution. Such requirements are termed 'Understanding Computer Requirements'
and four of
these requirements are as follows:
1 ) The software needs to be able to detect when it has received a
complete statement. A 'Complete Statement' is defined firstly as 'a statement
makes sense to a human'. The statement 'A one.' is not a Complete
Statement because 'A one' does not by itself 'make sense' to a human. 'A one
what?' is the inevitable response from someone hearing only those words.
'This is a one-jump horse' is a Complete Statement per the definition of this
- Any-ta-Any machine, because, and only because, it makes sense to a human.
The human understands what is being talked about. That the speaker may
add something else to what has been said so far is immaterial. 'A house that,
when 1 went...' is two incomplete statements -'A house that - what?' 'When
you went - where?' Remembering that an 'understanding computer' is in
essence one that behaves as a human would behave under the same
circumstances, 'makes sense' in computer terms is defined as 'a group of
words that a human would understand and not need to query.' And hence a
Complete Statement for the purposes of this Any-to-Any machine is defined as
'A groups of words that a human would understand and does not need to
query.' Consequently an 'Incomplete Statement' is defined as a 'A group of
words that a human would not understand and would need to query.'
2) The software needs to be able to detect the reason why an
Incomplete Statement is incomplete.
3) The software needs to be able to detect that the complete
statement received is in fact executable. (A statement can be complete,
without necessarily being executable). A statement that can be executed is
termed an 'Executable Statement.' Consequently, a statement that can not be
executed is termed an Un-executable Statement.
4) The software needs to able to detect the reason why an Un-
executable Statement can not be executed.
(Items 3 and 4 are in the field of associated software that executes a Concept
Language When a computer is enabled with Concept Language to be commanded with
Normal Language, the state of the art icon-menu method of listing what the
computer can do
will need to be replaced. When only a few abilities are present, listing them
is practical and
workable. But when thousands of abilities are present, listing them as a
choice list for the
user (even if the icon-menu method can be improved) becomes impractical. The
human
method where an order is assumed to be executable unless data is returned to
the contrary is
132
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
a more practical method of choosing an execution. In order to enable this
method of ordering
execution, the software should be able to detect when an order can, and can
not be executed.
It would probably be assumed that all computers using the Any-to-Any machine
would
probably be able to print something. But such a computer might equally well
receive an order
to 'plot the reflex tangent curve of the data in spreadsheet X'. While this
might be a complete
statement and make sense, there is no guarantee the computer would have a
software
module to do that, and therefore, it needs to be able to detect what it can,
and what it can not
execute.
Any software that attempts to execute an incomplete statement will obviously
fail. An
order to 'Print.' is incomplete unless something is designated - in some
manner - to be
printed. At the same time, a statement can be complete, without being
executable. If an
order is given to 'Print this document' - assuming that 'this document' is
identified in a
manner that the computer knows which document is 'this document' - then the
execution will
fail if there is no software module capable of printing an identified
document.
If a computer is given an order to execute something, then a 'Complete
Statement'
and an 'executable statement' are the same thing. But if it is given data to
record - as data -
where the only action required is to record the given data, the computer will
be unable to
answer questions on that data if the user has entered something - probably
accidentally -
that 'does not make sense' - i.e. is incomplete or internally conflicting.
Therefore, the two aspects of a) whether a statement is complete and b)
whether a
statement is executable can not treated as one, as under some circumstances,
they are
separate items.
To explain the requirements 1 - 4 in more detail:
- The Software can Detect When it Has Received a Complete Statement
It is desirable therefore, to define exactly what constitutes a Complete
Statement for a
computer, and this should be defined for software in terms that software can
test.
If a user says 'A one' this is not necessarily an Incomplete Statement - the
user may
go on and say 'A one-jump horse is a horse that I do not want to own'.
Thus the first part of a computer definition for a Complete Statement is: 'A
statement
that the human in some manner indicates he considers to be complete.'
Consequently, a
requirement is to provide a method for software to detect if a statement is
considered by the
human to be complete.
Punctuation can not be used as a detection tool for a human's consideration of
completeness of a statement, as punctuation more or less doss not exist in the
spoken word.
For example, some words can be written and appear as: 'He said, "I will go to
the house
tomorrow." But when these words are spoken in a complete monotone with equal
pauses
133
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
between words: 'he..said..i..will..go..to..the..house..tomorrow' they are
stil4 completely
understandable. In this example, punctuation is not an element that defines
whether the
statement is complete or not.
Pauses between spoken words also do not indicate whether a person considers a
statement complete. When words are written, they may appear as "I am angry.
Jill, is
difficult. I shall fire her". When these words are spoken, they can be spoken
in a monotone
with equal length pauses between words, and still be correctly understood:
'I..am..angry..jill..is..difficult..i.shall..fire..her'. Pauses (represented
by the symbol J~') can
even be placed in the mast unlikely places and the sense is still retained:
'I..am/langry..jill./lis..difficult..il~shalL.fireAher'.
This example demonstrates that whether a statement is a Complete Statement or
not
is actually coded in the words themselves, and not in punctuation of any kind.
Although a
Complete Statement can be coded by punctuation, the fact that is does so is
incidental.
Punctuation is not an indication of whether the human considers a statement to
be complete.
Even the data conveyed by punctuation such as '!' and a question '?' as, for
example in: 'O!'
or 'O?', can be detected from the text that foifows.
A problem does not occur if a statement is a Complete Statement and is
detected to
be complete from the words used themselves. However, a user may issue a
statement that is
not complete, and indicate that it is complete when it is not. Part of the
computer definition of
a 'Complete Statement' was that it is a statement that the humans 'considers
to be complete.'
A Human may say, 'I am angry jilt is.that's all' The words 'that's all.' state
that the user is
finished, and therefore - it can be assumed he considers that what he has said
is complete.
However, the statement is an Incomplete Statement, and the fact that is not
complete should
be able to be detected by software.
The words 'the blue house' is not a normally a Complete Statement. But if it
is title of
a book - then it is Complete Statement 'The Slue House'. Hence, what does and
does not
constitute a Complete Statement also depends on the where the statement
occurs. As a
book title 'A one' is a Complete Statement, but as text, it is not.
Equally, what constitutes a Complete Statement depends also on the framework
in
which the statement is occurring. Just like 'the blue house' is nonsense as
text, and
acceptable as a title, the following examples are nonsense as commands given
to a
computer, nonsense when given as given as business data:
Command: 'Jill is'. 'Print the modem.'
Command to record business data: 'The ship jumped on the cat.'
But these are not necessarily nonsense in other contexts:
134
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Fiction:"Jill is," said Jack. "Jill is what?" said George. "I'm trying to
think, it's
hard to express," said Jack.
Computer Class: 'Can I print the modem, Sir?' 'Do you mean 'Print to the
modem?" 'Yes, Sir, that is what I meant.'
Science Fiction: 'the ship jumped on the cat. Its 100-foot wings
looked tiny compared to the three-kilometer body of the cat.'
Computer software also needs a method that copies the human behavior of
setting,
early on, the framework within which something is to be understood. Speaker
'The ship
jumped on cat.' Listener: 'What is this?' Speaker: 'Science fiction.'
Listener: "OK, go on.' If the
speaker had replied: "A Business document' he would not have received the
reply 'OK, go on'
but more likely a reply with the sense of 'that's nuts, ships can't jump onto
cats.'
Consequently, for a computer to use Normal Language, a teaching of this Any-to-
Any
machine is that is it desirable that a system exists for software to detect
whether a statement
it receives is a Complete Statement, or an Incomplete Statement, and this
method should be
able to detect that the nature and circumstances of the use.
- When a statement is not complete, the software can detect why it is not
complete
It is pointless to detect that a statement is an Incomplete Statement unless
there is a
method to correct the error and a system to correct an error requires that
software has a
system to detect the exact nature of the error. For a human, most of what
constitutes sense
or non-sense in a text can be observed to classify into two main categories:
Omitted Data: the words 'jilt is' omits the data of what 'jilt' is - 'jill is -
what?'
Data Conflict 'The ship jumped on the cat' 'print the modem'
are examples of data where the given data has a data conflict if
given as a computer command - the data orders something that
is an impossibility in this framework.
(An extension of these teachings of the Any-to-Any machine concerning Complete
and
Incomplete Statements enables a computer to analyze situations and detect
causes of
problems, but that is outside the scope of this Any-to-Any machine).
In order for a correction to be made, such as prompting the user to complete
the
missing data date or resolve the conflict, software needs a method to detect
the nature of the
omitted data or the nature of the data conflict.
135
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The software can detect that the complete statement received is in fact
executable a statement.
Statements can be complete and intelligible, without being executable. A
Command
can be a Complete Statement such as "print spreadsheet X' can not be executed
until
'spreadsheet X' is identified for the software module that is to the printing.
Thus,
requirements for execution are in addition to any requirements for a user's
statement to be
considered complete.
- When a statement is not executable the software can detect why it is not
executable..
Again, human behavior, when encountering an order that can not be executed (in
the
cooperative spirit that a person would expect from his computer) is normally
to tell the person
why it can not be done. An understanding computer should therefore also be
able to detect
why an order can not be executed, so that either the computer itself, or the
human, can take
corrective action. Note that the computer can not take any corrective action
until it can detect
the exact nature of the error - and that involves detecting when a statement
is not
executable.
If the abilities 1 to 4 above are enabled in software, then - given the same
input -
software can behave with these aspects of data in a similar way to the way a
human behaves.
For example, a secretary will not normally receive a Complete Statement 'Send
this
Fax to Joe' and still attempt to execute the order knowing it to be un-
executable because she
does not have the fax number. She will not normally go to a fax machine,
attempt to dial a
number she does not have and then return the unsent fax to the boss with the
message
'error.' Nor will she sit at the fax machine for the rest of the day waiting
for someone to give
her the fax number to dial. She will either obtain the fax number herself or
ask the boss for it,
and when obtained, send the fax.
With abilities (1 - 4) enabled, a computer, given an order to send a fax to
someone for
which it has no fax number, can check the conditions required for sending a
fax. It can find
that one of the recorded conditions is the existence of a fax number, together
with the
information that fax numbers are found in Location X, and the right one is
chosen with
procedure Y. Executing this and finding no fax number, the error handling
procedure
incorporated in the Execution Module can launch a user prompt or other
procedure to obtain
the missing fax number.
However, behavior such as the above requires:
1 ) A software record of what does and does not constitute an Executable
Statement,
136
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2) A statement from the user that is a Complete Statement.
3) A comparison of the two to detect if the Complete Statement is also an
Executable Statement.
The required ability to detect if a statement is a Complete Statement is
enabled by the
Any-to-Any machine with the Concept Condition Rules Method. Additionally
Concept
Condition Rules have the added benefit of providing the basis - (2) above -
for comparison
with a statement of an Executable Statement (1 ) to detect if a Complete
Statement is an
Executable Statement (3). _
50) Base Concepts and other Meaning Words have Concept Condition Rules
Taking the Base Concept [invite] as an example, it is clear that a Bare
Meaning has
certain requirements that need to be met in order for the word to be
intelligible. These
requirements can be found by the Any-to-Any machine method of testing the word
in various
uses and viewing the results in the light of the Any-to-Any machine's
teachings. Once found,
these requirements can then be expressed as rules, as in the following example
concerning
the Base Concept [invite].
If one person walks up to another and says 'invite' and then walks away, that
person
will be left wondering what the speaker meant. If questioned, he will say that
knows what
'invite' means but is likely to say 'What did he mean? Invite whom? What
invite? Who is to be
invited?'
No matter what the form of the word - whether it is 'inviting', 'invitation'
or any of its
other forms - the word has certain basic requirements, and that can not be
usefully
expressed in state of the art terms as 'subject, verb, object':
1) One requirement for this Base Concept [invite) is that there should be
something that is invited. The following examples do not make any sense, or at
best, leave the feeling that they are incomplete as stated and the person who
hears them is inclined to 'fill in the gaps' with data he 'supposes' to be
what the
speaker meant. The mere fact that the person feels the need to 'fill in the
gaps',
itself indicates something is missing from the statement:
'Invite to move into the box will you?'
'invite over here'
'invite into the harbor'
'invite to the party'
2) While 'invite' requires something that is invited, it will not accept any
object as the thing invited= which is the furthest that state of the art
grammar
takes the subject - but requires certain specific types of object:
'Invite the rat to move into the box will you?' - makes sense
137
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
"Invite the table over here' - does not make sense.
'invite the ship into the harbor' - makes sense
'invite the mountain to come to the house' - does not make sense
'Invite Joe to talk' - makes sense
It is clear that for [invite] to make sense, whatever is invited should be
either a person or a thing that is capable of movement. As previously
mentioned and
as will be explained in detail later, the capacities of an object - such as
movement -
are required to be recorded as part of a Concept Language and in fact are part
of its
Concept Statement, and as such, are available for use.
3) However, whatever does the inviting does not have to be capable of
movement:
'The house was inviting me to come in'
'The table is inviting me to sit down and eat.'
4) In fact any Data Class can do the inviting:
Life Name: Joe invited me.
Quality The goodness of it invited me to...
Reason It was the reason he did it that invited me to...
Time Twelve o'clock invitingly struck as i...
Space (location) Latitude 41 30 20 invitingly said to me...
Energy (Action) His jumping the stream was an invitation to me to
jump it too.
Matter The house invited me to come in.
Enabling a computer to determine when a user statement is complete. Concept A
useful method to enable a computer to determine if a statement is a Complete
Statement or
an Incomplete Statement [invite] is to state the behavior of Concept Symbols
including Base
Concepts in terms of a Concept Condition Rule as per the following example:
1) [invite] requires a Cause, and this Cause should be one or more Data
Class values
2) [Invite] requires an Effect and this Effect can be either Life Data
Category, Data Class Human Life or Data Class Non-human Life, or Matter Data
Category with the capacity of movement.
The Concept Condition Rule Method creates computer - executable statements
that
software can test to see if are satisfied or not. Using Concept Condition
Rules, enables
software to test and find whether the input is a Complete Statement or an
Incomplete
Statement and if incomplete, why it is incomplete. This ability on based on
the Any-to-Any
machine's further definition and final definitive definition of a Complete
Statement, as follows:
138
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
A statement is a Complete Statement when the words in a statement satisfy all
the Concept Condition Rules of all the words in the statement. A statement is
an
Incomplete Statement, when the words in a statement do not satisfy all the
Concept
Condition Rules of all the words in the statement.
This can be illustrated as follows. Several words in a statement can have
Concept
Condition Rules. One word - termed for this example ' a type 1 word' - can
have a rule that "a
type 4 word is required'. The type 4 word can have a rule 'a type 1 word is
required'. If the
statement contains a type 1 word and a type 4 word, both Concept Condition
Rules of both
words wilt be satisfied and the statement will be a Complete Statement. If the
user enters
only a type 1 word, or only a type 4 word, that word's Concept Condition Rule
is not satisfied,
and the statement is an Incomplete Statement. The reason that the statement is
an
Incomplete Statement is apparent in the unsatisfied Concept Condition Rule
(and hence can
be used to generate an appropriate prompt or corrective action).
This is further illustrated in the following example, using the words 'Jack
invited Jill'. In
the following table, the lines headed at the left 'Jack' and 'Jill' are
supposed to be entries in a
database. The database is supposed to contain two sets of Data Categories as
mirror
images of one another - one for the 'Cause Side' and one for the Effect Side',
and these Data
Categories are represented by database fields. These database fields have been
named in
the table for the purposes of this illustration with the Data Category names
(but may not
necessarily be so named in an actual application. The word in the first column
-'Jack', 'Jill' -
shows the word in question, and the remaining columns represent the database
fields, and
show where the word would be entered in the Data Base. A record in which data
is recorded
- such as the words 'Jack' or Jill' - is termed a 'Data Record'. In this
instance, the words
'Jack' and 'Jill' are shown as occupying two lines and hence two records, but
this is done only
for clarity - there is no reason both wards can not be entered in the correct
fields in a single
record.
The first line, containing the word 'Jack' shows that the word 'Jack' falls
into the Life
Data Category on the Cause Side. The last line, containing the word 'Jill',
shows that the
word also falls into the Data Category of Life but on the Effect Side. Meaning
Rules take care
of detecting the case or Effect assignment to the words 'Jack', 'Jill'
139
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
(~,se~ 8
liltrdLice Time ~e Ena N~tbaN~ 6~r ~aoe TirrELik
,.~c,~k
>ru~~~
.
~tsbte p~xahepter~epttar~,ePlter~ue(Pdet~ '
' ;
, ..
.
JII .
The middle row - containing the Base Concept [invite] in the left-most column
represents a type of database record termed a 'Concept Condition Record' that
is recorded in
the same or another database that is similarly organized to the one containing
the words
'Jack' and 'Jill'. _The Concept Condition Rule for [invite] is expressed in
the Concept Condition
Record in terms of the Data Category fields that are required or not. In this
Concept
Condition Record, the words 'Required Alternative' in each field of the Cause
Side represent
a suitable database expression with the meaning that any value of entry in at
least one of
these fields on the Cause Side are required. The words 'Required Alternative
(Able to Move)'
and 'Required Alternative' shown in fields on the Effect Side of the same line
represent the
fact that the same Concept Condition Rule also requires either an entry in the
Matter Data
Category or the Life Data Category. The words 'Able to move) further represent
a database
expression signifying that if there is an entry in this field, that entry
value should have
associated with it a Concept Symbol signifying that the object it represents
has the capacity to
move.
Accompanying software logic can now use the Condition Records of the entered
words ' Jack invites Jill' to query the Data Record, and determine if the
Condition Record is
satisfied by the Data Record or not, and hence whether the statement is a
Complete
Statement or not. If the Data Records do not satisfy the Condition Records -
and hence the
statement is an Incomplete Statement, it does not 'make sense' - the reason it
does not
satisfy the Condition Records can also be returned by the query.
In this example the Condition Record is satisfied by the presence of the word
'Jack' in
the Life Category of the Cause side of the Data Record and by the word 'Jill'
in the Effect side
of the Data Record. But supposing that the statement entered was 'Jack
invites', and nothing
more, the requirement of the Condition Record on the Effect Side would not be
met. A value
would be returned that would enable a prompt to be created such as: 'Requires
the name of a
person or an object that is able to move'. More colloquially this prompt could
be expressed as
'Who or what did he invite?'
Hence this method of the Any-to-Any machine provides the basis to enable a
computer to determine whether entered data 'makes sense' and if not, why it
does not 'make
sense'. Less colloquially, the method enables software to determine whether
entered data is
140
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
a Complete Statement or not, and if not, why the Statement is incomplete,
thereby fulfilling
Understanding Computer Requirements (1) and (2) previously stated.
As previously mentioned, one implementation of a Concept Language is a Number
Concept Language, as this is faster to execute. A Data Class value 'Able to
Move' as used in
the Concept Condition Record described above, is implemented on the following
broad
outlines, using 'boat' as an example - a boat being a thing capable of
movement:
- The Concept Statement for the word 'boat' is composed of Concept
Symbols, which are themselves numbers.
- One of these numbers will be the number that is the Concept Symbol
for 'move' for example '4451'.
- The Effect Side Matter data Category Condition Record contains one
number - for example the number '2' that query logic interprets as 'A value in
this
field is one of the alternatives that is required'. Additionally the same
field
contains the number '4451' which query logic interprets as 'If there is any
value in
this field, query its Concept Statement to determine if it contains '4451'. If
it does
contain 4451, return 'True' else return 'False'.'
- Supposing that a value is entered - for example ' mountain' that can
not move and therefore does not have '4451' in its Concept Statement - query
logic generates 'entered value does not contain '4451'. This return provides
the
basis for generating an error prompt such as 'mountains don't usually invite
things
are you sure this is what you meant?'
In a Data RElation Table implementation, alf database entries are numbers and
only
numbers, and hence, both Data Records and Condition Records can be stored in
the same
database, and in that case, are marked by a separate field as being a Data
Record or a
Condition Record.)
51) Enabling Human Query Procedure. Base Concepts Assigned Concept
Hierarchies
The following is an example of a type of human query procedure:
Person 1 to Person 2: I sent Joe an invitation
Person 3 to Person 2: What did person 1 do?
Person 2 to Person 3: Invited Joe
The above conversation demonstrates there is a relationship between 'do' - a
general
expression for an Action, and 'invitation', which, in this case, is a thing
and therefore a
member of the Matter Data Category.
This relationship that a human demonstrates exists for him between 'invitation
and do'
needs to be enabled in a computer environment in order for a computer to
accept queries in
141
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the manner a human can give them. A useful method to do this is to apply the
Concept
Hierarchy Method to Base Meanings:
1 ) To give the Base Concept [invite] a Concept Hierarchy - do & ask &
invite - based on the word definition,
2) Specially mark all words that have a Base Concept to show they have a
Base Concept, with the code for the Data Category of the Base Concept, in this
case, 4 for the Energy Category
3) The Data Relation Table then records the Concept Symbol for the Base
Concept in a separate field termed a 'Base Concept Field' in the same record
as
the rest of the data. The Data Relation Table logic includes this field in
queries
conducted to answer user queries. In this manner - referring to the above
example - a search for what did Joe 'do?' will find both [send) and [invite],
and as
usual, return the lowest (most detailed) value i.e. 'invite' Joe. Since the
record will
include a record of the Time and that Time will be earlier than now, the time
is past
time, and hence the logic adds the past time code of '-ed' and returns
'invited Joe.'
~ Step 3, Isolate each individual Base Concept for each meaning Word. Ward
Compression Codings
In the method of the Any-to-Any machine, the Meaning Words of a language are
classified by meaning into Data Categories. The words of each Data Category
take their own
types of Compression Codings. These Compression codings, described by category
are as
follows:
52) Requirements to enable a single Concept Language to handle any
Application
Further computing techniques that assist an ordinary computer to act as an
Understanding Computer are:
9 ) Such a computer intrinsically requires senior, controlling
software, that controls the computer as a whole, including controlling other
software that actually performs the executions ordered by the user
2) It is desirable that the controlling software does not have to be
changed depending on the data it is dealing with. The basic and fundamental
mechanisms - such as those for locating data - should remain constant across
all possible applications. A human handles data the same way, whether he is
talking to a friend, talking about secretarial work, or discussing gardening,
astronomy or quantum physics. If a computer is to be perceived as
'Understanding' it too will be expected to have the same constancy across
applications.
142
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Because of these requirements, it is desirable that the basic construction of
a Concept
Language takes account and is compatible with alt applications to which it may
be applied.
This is desirable to avoid application A requiring a Concept Language of one
type and
structure and application B requiring a Concept Language of another type and
another basic
structure.
In order to ensure that a single Concept Language can handle all applications,
a
Concept Language should be constructed with the broadest possible viewpoint,
and from a
consideration not just of what it may be needed to handle today, but what it
may be needed to
handle tomorrow.
This leads to two further requirements of a Concept Language:
1 ) A Concept Language should be constructed bearing in mind not only
the words in its vocabulary, but bearing in mind, and providing for the words
that
will inevitably be added by the user. Most applications will result in the
user adding
word to the Concept Language vocabulary - words for names of things and
actions, the words for names of people and the words and numbers for
addresses,
telephone numbers etc. '
2) The way humans handle the words of each specific Data Category
should be thoroughly understood, and the Concept Language constructed in such
a manner that it can handle correctly any word of that Data Category in any
application.
Because of this, the characteristics, requirements and behaviors of words in
each
Data Category will be described in turn.
53) Further Data Category Characteristics - Life
54) Further Data Category Characteristics - Time
55) Further Data Category Characteristics - Space
The Data Category of Space can be confusing, and the general tendency in the
state
of the art is either to ignore it, or to include into it things that do not
belong in it. For example
most computers have some provision to record the Life Category - people's
names for
example. Computers usually record Time in a limited manner - for example, the
Time a file is
last saved. Icons and Menus are, in a manner, recordings of the Energy Data
Category -
actions. Space however, it only really seen in a computer in terms of Disk
Partitions, and
otherwise, is more or less ignored.
Many problems with failure of computers to understand can be traced to failure
to treat
Space as a separate category of data.
143
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- Recording Space in a Computer
The only way a computer can really record the data in the Space data Category
is in
terms of:
- Coordinates. Coordinates can be used to record spaces and shapes
- Names of spaces - for example, "New York' is name for a space as
well as a name for a particular collection of material things.
- Lengths and volumes - hence distances - which are measures of
space
- Descriptions of spaces
In general computer use, the most usual representation of Space is as an
address,
and for this reason the Space data Category is sometimes (incorrectly)
referred to in this
description as a Location to make it clearer. Thus, in earlier parts of this
description the
words 'Space' and 'Location' have been used interchangeably, but from this
point forward,
'Space' with a capitalized first letter, is taken to mean 'The Space data
Category.'
- Use of Coordinates
It should be understood that space has three dimensions. Thus a point, in
order to
localize it, requires three coordinates. Hence, there is an intrinsic Concept
Hierarchy in the
Space Data Category:
A Space is defined by four or more coordinate sets where at least
one coordinate is not the same in all coordinate sets. A Space intrinsically
contains an infinity of areas.
An Area is defined by three or more sets of coordinates where
one of the coordinates in the coordinate sets is the same for all the
coordinate
sets. An Area intrinsically contains an infinity of lines
A Line is defined by two or more sets of coordinates (each which
consists of three coordinates) where two of the coordinates are the same for
all
coordinate sets. A Curve is a special type of lines.
A Curve is defined by more that two sets of coordinates where
one of the coordinates are the same for all coordinate sets and another
changes by a constant value in relation to its distance from the set of
coordinates at either end of the curve.
Any type of line intrinsically contains an infinity of points.
A Point is defined by three coordinates.
A Coordinate Pattern is defined as any number of sets of coordinates that are
each
separated from one another by distances, where those distances bear a fixed
proportion to
144
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
one another. The space occupied by any Matter can be defined in terms of a
Coordinate
Pattern.
An Object When an object is defined in terms of the Space it occupies, it is
defined as a Coordinate Pattern whose orientation with respect to gravity
falls within specified
limits. The direction of Gravity is a fundamental orienting factory in all
verbal expressions of
movement.
All shapes can be defined in similar terms. The importance of doing so is that
descriptions such as these form a basis for a computer to be able to recognize
shapes and
relate them to words.
Any Movement of any Matter results in the matter that existed in one space,
now
existing in another and can be expressed as a change of sets of coordinates.
This statement
of the obvious has however, not been obvious in the state of the art, where
there is generally
no place or manner to record the relationship between movement and location.
In the
absence of such an arrangement, a computer that is ordered to move something -
for
example a box on a screen - does not record where the box was, only where it
is now. A
computer told that 'Joe has moved' will not ask for his new address unless a
relationship
exists move = change of location.
- Components of an Address
An 'address' as referred to in everyday conversation is in reality an assembly
of
completely dissimilar data, which is often referred to as a block, and, in the
state of the art, is
usually treated by software as a single data type when it is not. For example,
most computers
in the state of the art, treating 'addresses' as a data type, give the data
type a matching
software type. This software type - contact software - deals with addresses
only and will not
process other data such as texts for letters or accounts data - both of which
need addresses
also. The least of the negative results of this error is that software with
complex and difficult
to use mechanisms is required to move address data where it is needed.
The following is an example of an address
Mr. Joe Blow, Ph.D.
Director of Thought,
Marketing Department
Room 4,
Suite 298
4t" Floor
291118 Broadway,
The Bronx
New York City
145
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
New York State
USA
291118
Separating this block of data that is collectively labeled an 'address' into
its component
parts:
Mr. A Greeting, and not necessarily the only
one that may be used
with this person. When a good friend addresses
him at home,
he may, perhaps for fun, use 'Esq.'
Joe Blow Name of a person, and while he may be addresses
this way at
his work address he may be addressed differently
where he
may prefer to be called 'Joey' or some
nickname
Ph.D. Qualifications; also an abbreviation
Director of Thought,A Job name that is part of an organization
chart. Joe is Director
of Thought - but only at this location.
He may have a number of
other titles also. Chairman of the Lyons
Club, President of the
Gold Club and potentially, dozens of others.
Marketing Department
A Group Name
Klein & Pinch A Location Name. Also a name of a group
of people
Room 4, A Location name
Suite 298 A Location name
4'" Floor This is one of the three coordinates
291118 Broadway, This line is two coordinates combined into
one. Broadway itself
is one of them, and the number is the other
one. Sometimes,
the two coordinates are separated 'Corner
of 1 St avenue and 6'n
street' in which case they are more clearly
seen.
The Bronx A Location Name
New York City A Location Name
New York State A Location Name
USA A Location Name
291118 This is also set of coordinates and is
effectively a
number that is a name for an area.
It is extremely desirable
that in creating
a Concept Language,
the types of data
and
the kinds of word used together, are labeled 'an address'
that, when are correctly assigned to
146
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
correct Data Categories and handled accordingly to the requirements of each
Data Category.
If they are not, it becomes virtually difficult to create an Understanding
Computer. The
reason for this is as follows:
The Unlimited Principle and the Space Data Category
The Unlimited Principle, stated previously, is as follows:
A computer, within the limits of the capacities of its hardware, should never
limit a user in a manner that he does not limit himself.
Most state of the art software violates this_principle when dealing with multi-
data type
called 'addresses.' For example a single person may have many locations at
which he is from
time to time - one or more work places, one or more homes, places where he
does sports,
and so on. Each of these places has its own coordinates - its own street
address.
Equally, this single person is related to many documents in his computer -
either by
the fact that he created them, or by the face that he received them. As far as
a human is
concerned, he is related to both his documents and his locations, but he is
neither of these
things. He is not a document and he is not a location. However, the only
representation of
that person in the computer is his address record - if he even has an address
record for
himself, which is not certain.
The address record creates a fixed relationship between the representation of
the
person in the computer - his name - and one location. Sometimes software, in
the state of
the art offers up to three possible addresses: 'Home' 'Business' and 'Other.'
If an attempt is
made to create a Computer that Understands with software such as this, which
violates the
Unlimited Principle, the attempt will fail, as follows.
As soon as a person needs to enter a fourth location for 'Joe' the computer
will cease
to understand. The work around solution to this is to create another address
record for the
same person, meaning that there are now two representations for one person in
the computer
containing Locations numbers 1, 2 3 and 4. This has now created a fixed
relationship
between one name and two sets of locations. As shown above however, as far as
humans
are concerned, a person who communicates with him - for example by e-mail - is
related not
only to that persons two sets of locations but also to all the e-mails he
sends to the user.
Should the documents received be related to the first instance of the name or
to the second
or to the third? Unless the spelling of the name in each of the sets of
address record is utterly
identical, the relationships will be lost. Suppose that accidentally, the user
entered the
second set of locations using 'Joey' with an added 'y'. Supposing that the
person who sent
the e-mails now moves to a new location. The user enters Location 5. He then
issues a
Unique Data Specification: 'Get me the e-mail Joey sent me about Bananas when
he was at
his old location.' The specification fails because
147
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Joey - with a 'y' - can not be related to the documents sent by Joe
No Time is recorded for the new Location, so viihich location is old and which
is'
new can not be found. In effect all locations are 'Time Now'. Often the onw
wav tn
mark an address as 'old' is to delete it. If that is done - since the address
record is
the only manner to relate the person's name to the documents - then the
relationship
with those documents is lost, and now, any Unique Data Specification referring
to
previous locations will fail.
If a time had been recorded, then, because there is a fixed relationship -
between 'Joe' and the 'ofd' locations, means that if the Location is
designated as 'old -
no longer in use, Joe is also designated as no longer in use - i.e. dead -
when he is
not.
This small example shows just a few of the problems that result from the
practice of
creating a fixed relationship between a person and a location as is done in
the state of the art
'address' software. This example is a symptom of a much wider problem in the
state of the
art, and is encompassed in the Any to Any Principle. This Principle and its
accompany
Method should be fully implemented in creating a Concept Language, as failing
to do so
results in a computer that does not understand.
The Any to Any Principle
The 'Any to Any' principle is stated as:
A Human being relates anything to anything within the limits of physical
capacity, functionality or agreements.
Language is itself can be described as any-to-any data transmission system.
Any
word can be related to any other word within the limits of functionality and
agreements
(grammar). For example the following words can be used (related) together, and
might be in
a science function story: 'The invisible thinking car' 'The singing non-
existent house'. The
Co-reducing Concept Method is one application of the Any-to-Any Principle. ,
'An item is specified by adding any one word to any other word, with the
corresponding result that the Concept encompassed by each word is co-reduced
to that part
of the Concept of each that is common to the other. The process is continued
by adding any
other word (etc).'
To further illustrate this Principle, in the example given previously of an
address, the
following types of data were listed:
Greeting
Name
Qualification
Job Title
148
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Group Name
Seven Location Names
Two Sets of Coordinates
A person can relate Any greeting to Any name. He can relate Any name to Any
Qualification. He can relate ANY qualification to Any job Title. He can relate
Any job title to
Any group name. He can relation Any group name to Any Location Name. He can
relate Any
location name to Any other location name. He can relate Any location name to
any set of
coordinates. He can relate any greeting to Any Qualification "Good morning Mr.
Ph.D.' to
any group name ('Hi Mr. IBM'), to Any Location name ('Hi, Mr. Subway'), to Any
coordinate
(Hi Mr. 42 degrees Sextant Angle').
The point is not whether he will relate those things, the point is that he can
do so, and
that the all elements of an Understanding Computer, should be able to do so
also - including
Concept language. To the degree that the computer does not apply the Any to
Any Principle,
it will violate the Unlimited Principle by limiting the user where he is not
himself limited. To the
degree that it does so, it will not 'understand' him., or he understand it.
There is also an observable and useful phenomenon concerning Data Classes and
the Any to Any principle, and that is that a person usually, and nearly always
uses values from
different Data Classes to describe a single something. When a person does
appear to do so
this is usually a compression of some sort. He is not likely to say 'the chair
table is a good
color' 'Jack Jill sat down. He may say 'Jack and Jill sat down' - which is two
separate people
performing the same action. But normally two values from the same Data Class
are not used
together as they tend to conflict with one another. 'Jack Jill' has no
particular meaning. Was
the person called Jack Jill? 'The dog cat jumped the tree' but is more likely
to say 'the dog
jumped the tree like a cat'. It is this phenomenon - which is an aspect of the
Data Class
Integrity Principle - that enables most items in a computer to be specified by
a selection of
values from different Data Classes.
The Any to Any Method to enable a computer emulate human handling of
'addresses'
The Any to Any Method is: to separate all data into its component types, and
to
continue doing so until no further separations are possible - in other words a
further
separation renders meaningless. For example the meaning of 'furniture' can be
separated
further into the meanings of 'chair' 'table' etc. But the meaning of 'table'
can not be further
separated or what is left is no longer 'furniture'
The reason for this method - in general terms - is that when something to be
stored in
a computer is separated into its component parts, those component parts can be
stored
separately and subsequently assembled by the human taking any one part and
using it with
149
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
any other part. The computer can record the parts the human assembled together
and how
he assembled them, and store them separately. Since the parts that are stored
separately,
they can be accessed separately and selected separately.
As a first illustration of the Any to Any Method, this has been applied by the
Any-to-
Any machine itself, to Concept Language in relation to words concerning
actions, for
example. Taking as an example the word 'worked', in Concept Language, the Any
to Any
Method is to 'separate all data into its component types.' The Meaning of
'worked' is therefore
separated into its component parts of 'work' & 'past time'. '..those component
parts can be
stored separately...' 'work' and 'past time' are therefore stored separately.
'Work' is stored in
the Action Data Category and 'past time' in the Time Data Category. '....since
the parts are
stored separately, they can be accessed separately and selected separately.
Hence if the
user wants to know, now, 'What was done?' because all Time is stored in the
Time Data
Category, Time can be accessed separately and hence can be accessed for all
records
containing the equivalent of past time. Finding such a record, the
corresponding action can
be retrieved, and is found to be 'work'.
Now further illustrating the Any to Any Method in relation to the types of
data that are
termed 'address':
One person may have many Locations - coordinates in effect. From time to time
the
user himself may be at on or even several of those addresses during a day. A
Secretary
would know this, and should a computer, which should be able to execute an
order such as:
'Call me when you get an e-mail from Joe'. If Names and locations are
separated, then the
Any to Any Method can be applied and Any (or Many) locations can be related to
- connected
with Any (or Many namels. All that is requires is a mechanism to show which
Names apply
to which Locations at this Time. People are not static and are at different
locations at
different Times of the day. On the principle, described in relation to Data
Classes that All
available Data Class Values are always recorded, data available in the data
category Time
will also be recorded, and hence, it is not complex to record which
coordinates are valid at
which times. Thus an Understanding Computer, told to contact someone, will do
so at the
coordinates - location - where they are likely to be at that time.
Similarly, one name - one person - may be a member of many groups, not just
his
group at work. He may need to be addressed at Any coordinates - location - as
a member of
Any group with Any title.
(For a Computer to be a Computer that Understands, the Any to Any Principle
requires that the computer to be able to record and use Any data with Any
other data to
cause Any Execution. In essence any attempt to feed valid Concept Language
output to
state of the art software would effectively fail, as software, in the state of
the art is incapable
150
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
of the Any to Any flexibility a user requires. Almost every conceivable
command that a
computer - theoretically - execute will fail because the software can not
maintain the Any to
Any relationship that will be in the user's commands. In essence, Concept
Language would
become a kind of icon-replacement mechanism, and the computer will not be seen
to
'Understand' because the execution software can not act in the manner a human
acts.
Unfortunately, the construction philosophy of state of the art software is one-
to-many in nearly
every respect. Further and worse, in order to make another relationship, the
first, rigid
relationship should be un-created before a new one can be created. One brand
of word
processor is rigidly related to many letters (that no other software can read
without
manipulation). Un-creating the rigid relationship so that other software can
read or use the
content is an extensive process in itself. Databases are built entirety on
rigid one to many
relationships and hence are useful for one purpose and use-less for any other
purpose. For a
computer to be considered understanding, and to be able to act in a human
manner, it is pre-
requisite that the associated software to the Concept language is an Any to
Any data engine
- it can handle data on the Any to Any principle. The Data RElation Table does
this).
The detailed application of the Any to Any Method will now be described in
relation to
the types of Data found in an 'address'
Components of an Address - Greetings, Names of People, Job Titles and Group
Names
All these are their own Data Classes in the Life Data Category - see that
Category for
description
Components of an Address -Location Names
Klein & Pinch A Location Name. Also a name of a group of people
Room 4, A Location name
Suite 298 A Location name
The Bronx A Location Name
New York City A Location Name
New York State A Location Name
USA A Location Name
These Location names, with the exception of the company name - 'Klein & Pinch'
and
'room 4' - are their own Concept Hierarchy:
Space (Data Category) & Earth 8~ USA & New York State & New York City & The
Bronx & Suite 298
151
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Just like any Concept Hierarchy, they can be used in queries, such as 'where
is Joe?'
'New York' 'Oh yes. Where?' 'At Klein & Pinch'.
This, in effect and with the method and teaching of the Any-to-Any machine,
shows
that this is the Concept Hierarchy of the name 'Klein & Pinch' in terms of
Space, and that the
definition of 'Klein & Pinch' in terms of Space is the coordinates '291118
Broadway &
Broadway & 4'" floor'. This becomes more clear if one asks 'What is suite 298?
Is this Klein
and Pinch? Can you take Suite 298 and you have Klein & Pinch?' This type of
question
makes it clear that Suite 298 is a Space that is occupied by Klein & Pinch. It
is not Klein &
Pinch, which is a group of people and systems etc, it is 'Klein & Pinch
space'. Hence, a
company name when used in an address is not the company itself, it is the
Space that
company occupies, and the Company Name has two meanings - one as the Space,
and
another as the Group of People. Associate software should treat company names
in this
manner.
The following example makes this nuance becomes clear. A Company is a group of
people and is not the same thing as the space occupied by the company.
Communications
are intended for the people, not for the Space, although the people occupy the
space -
usually, but not always occupy the Space. A computer that only has the
recorded relationship
of Klein & Pinch = address of Klein & Pinch and told late in the evening:
'Send this desirablely
urgent communication to Klein & Pinch', will send the communication for the
breakfast
meeting to the Space of Klein and Pinch, where no one will receive it until
after the meeting
was to have taken place. A secretary would know, instinctively, that Klein &
Pinch, in this
instance, is the people not the Space, and would communicate to the needed
person at
home. A computer, where the associated software is created with the
understanding of the
Teaching of the Any-to-Any machine, that communication is intended to be sent
to people not
spaces can also send the thing to the right Space..
Now in the original name the address was the name 'Miss Jones' who in this
example,
occupies Room 4 at Klein & Pinch. The Concept Hierarchy in her case is
Space (Data Category) & Earth & USA & New York State & New York City & The
Bronx 8~ Suite 298 & Room 4.
This demonstrates that associated software, when receiving an address, should
record the address of BOTH the company and the person as separate items, as
they are not
152
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the same thing. Miss Jones is part of Klein and Pinch, but she is not all of
Klein and Pinch. If
this is not done, then an order to 'Contact Klein & Pinch' will fail, because,
even thought he
computer has a recording for Miss Jones at Klein & Pinch, it does not have a
recording for
Klein & Pinch as an entity that can be contacted.
Each of the components of the two Concept Hierarchies given above are Names of
spaces, and Space Data Category Concept Hierarchies are spaces nested with one
another
Hence, when creating a Concept Language the method of the Any-to-Any machine
for
each word that names a Space, to obtain and record its Concept Hierarchy using
the methods
already described to locale Concept Hierarchies.
Components of an Address - Coordinates, and their Storage
Before describing the Any-to-Any machine method for handling coordinates in an
address - for example, those given in the example address above, it is first
desirable to
describe method for handling coordinates in general, as follows:
The description given at the beginning of this section on the definitions for
spaces etc
do not have great consequence to Concept Language for a general office
application-
However, they are relevant if the computer is also required to deal with
astronomy data, or to
navigate, or when a computer is required to move an item occupying ane space
into another
space, where the relative shapes and volumes of the spaces should be
calculated. As
previously discussed it is undesirable for the user, and adds unnecessary and
undesirable
complexity to the software, if an Understanding Computer should change
software because
the previous question concerned an address and the next question demands the
coordinates
of a galaxy.
1f a computer is asked: 1) 'Where is Joe?' 2)'Where is the Andromeda Galaxy?'
3)
'Where is the refrigerator?' It is desirable that the procedure far finding
where something is
should not require to be changed depending on the specialty in question. It is
equally
desirable that the place where a particular type of data is stored should
remain constant. It is
not desirable that software should look in place X if it requires an astronomy
coordinate and in
place Y if it wants an address coordinate and place Z if it wants a navigation
coordinate.
Software can be simpler, faster and more reliable if all coordinates in all
applications and
specialties are stored in place A, all names of people are stored in place B,
and so on.
However, the name given to a particular type of something changes depending on
the
specialty concerned. The following is an example of the same thing - a
coordinate - being
named differently depending on the specialty:
In office work, a set of coordinates is termed an address
In navigation, a set of coordinates is termeda way-point
153
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
In the army, a set of coordinates is termed a map reference
In astronomy, a set of coordinates is termedcoordinates.
However, the type of the data - coordinates in this case - does not change. In
fact,
data recorded under any one of these headings can be expressed in the terms of
any of the
others. A way point coordinate can be expressed as an address coordinate, etc.
Further, the Concept Hierarchy of a specific type of data does not change
either. In
the case of the above examples it is:
Space 8~ Location Name &.... Location name & Coordinate & street address
Space & Location Name &.... Location name & Coordinate & way-point
Space & Location Name &.... Location name & Coordinate & map reference
Space & Location Name &.... Location name & Coordinate
In a general office application, there will be many street addresses. Hence
the
Concept Hierarchy of each will be:
Space & Location Name &.... Location name & Coordinate & Street Address
Company 1
Space & Location Name &.... Location name & Coordinate & Street Address
Company 2
Space & Location Name ~.... Location name & Coordinate & Street Address
Company 3
The same computer may also have Map references:
Space & Location Name &.... Location name & Coordinate & Map Ref 1
Space & Location Name &.... Location name & Coordinate & Map Ref 2
Space & Location Name &.... Location name & Coordinate & Map Ref 3
As previously described,
A Data Class is a group of words or items that have the same senior in a
Concept
Hierarchy.
Hence, Street Addresses and Map References will all fall into the same Data
Class
'Coordinate'
However, a user will be surprised if, when viewing a number of addresses, he
sees
that the column of addresses with a heading 'Map Reference', or that a column
of map
references has the heading 'Street Address'. Clearly the way the data is
labeled needs to
change depending on the type of Data that is being displayed.
154
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The desirability of keeping a constant storage. location for a particular type
of data,
and the requirement to re-label the data as described above poses certain
restrictions on the
associated software:
1 ) If a database is used to store the data many databases do not accept
different
data types in a given field. However, the final form of a Concept Language is
a Numbers
Concept Language and hence whether a coordinate begins as a number or begins
as a
written address, it is still stored as a number.
2) If a database is used to store data, then it needs to have the capacity to
re-
name its fields depending on the data being displayed.
- Components of an Address - Coordinates in addresses
In the light of the above teaching coordinates in an address are dealt with as
follows:
4t" Floor This is one of the three coordinates, in this case, a type of Height
coordinate. The third coordinate is often missing from addresses, as often it
is self-evident.
When missing it is simply ignored.
291118 Broadway, This line is two coordinates combined into one. Broadway
itself
is one of them, and the number is the other one. Sometimes, the two
coordinates are
separated 'Corner of 1 S' avenue and 6t" street' in which case they are more
clearly seen.
When recording, the two Coordinates are separated into one Data Class for each
of the
horizontal coordinates.
291118 This is actually a duplicate coordinate belong in to another system
entirely and is actually a number name for a Space (t is recorded in the Space
Category in its
own "Post Code' Data Class.
- Components of an Address - Telephones, E-mail addresses and other
Communication Numbers
In the state of the art, telephone and other communication numbers and
addresses
are usually included in the multi-type data that is called an 'address.'
However, a telephone
number is actually simply a number name for Matter Data Category input out
device and
where it is physically is becoming less and less desirable - few people know
the physical
location of their service providor's e-mail server. Mobile telephones do not
have a fixed
location. In fact such devices are better selected by Time than by Location.
Most people's
active telephone number changes at least twice a day. Hence the number or
method to use
depends on 1 ) the person to whom to communicate 2) The person's activity at
that time of
day governs 3) Their Location. While fixed communication devices do have a
location, and
that location needs to be recorded, they also have active times that need to
be related to the
people who use them.
155
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Telephones and other communication devices are physical devices - and hence a
member of the Matter Data Category, together with their number 'name'.
Treating them with
this teaching of the Any-to-Any machine enables them Any telephone number (for
example)
to be related to Any Name. 'Call Joe at Bill's Number', for example, creates a
relationship
between Joe and a number that is related to Joe.
- Components of an Address - Handling Words in Addresses.
Words that have one meaning that is a name of a Location are assigned a
Concept
Symbol in the Space Data Category for that meaning.
When associated software receives address data contained previously unknown
words, and enters these into its Concept Language, it should use suitable
logic rules to find
out if it is a new member of an existing Data Class (which should mostly be
the case) or a
completely new Data Class. In either case it is assigned a new Concept Symbol
number in
the Number Concept Language directly, and given a definition of 'Location
Name.'
- Components of an Address - Output (Display and Printing)
Requirements.
The Any to Any relationship with which the component data types of an of an
address
need to be handled - Any Name with Any Coordinate with Any Space Concept
Hierarchy with
Any communication device name etc - is incompatible with state of the art
interface handling.
The One to Many software construction philosophy results in one set mixed data
types (an
address) being held in rigid relationship to one another, so that any one of
them can not be
used with any other one than the one for which the relationship has been set.
Further, this is
done by software that controls its own screen display - a further rigid
relationship, and
controls its own printing - still another rigid relationship. Thereby a set of
rigid relationships is
established between the different data types, and the software manipulating
the data, and the
screen output and the print output. Extensive experimentation has shown that a
One to Many
system never can be capable of handling or acting as an Any to Any system.
They are
fundamentally incompatible and the Any-to-Any machine Any to Any method of
data handling
is in tact the fundamental Any-to-Any machine - from which all other methods
stem - enabling
a computer to 'understand'. In terms of the screen and print outputs, this
means that the
existing software construction methods can not display or output data on an
Any to Any basis,
even if Concept Language can order it and the Data Relation Table can process
it. The
interface described below solves this problem. In summary the Data Relation
Table is an Any
to Any Data processing engine, and only does processing and, different to the
state of the art
method, does not display anything or control the display or output of
anything. The interface
takes care of all output and also screen input where the screen is used as an
input tool It
treats the display and printing of different types of data - a photograph,
text, a spreadsheet -
156
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
as an Any to Any display problem. In this manner, a file in the prior art
sense of the word,
does not exist. A photograph may be stored in one place, numbers data in
another, and text
elsewhere - each item is stored separately. A 'Document' or a 'Letter' then,
simply becomes
an output-time display assembly job, of assembling the right components, in
the correct
. spatial relationships to one another, and this, when seen on the screen or
printed, is 'the
document' or 'the fetter'. Thus Any output can consist of Any combination of
Any data type.
Thus Concept Language is an Any to Any mechanism. The Data Relation Table is
an Any to
Any processing engine. The Interface is an Any to Any input/output engine.
Because the
three entities, working together, for a system that is throughout, an Any to
Any system
obeying the Unlimited Principle, the system can handle and output address data
as above,
while handling it for the user on the Any to Any basis he requires. Thus an
'Address' is in the
terms of the Any-to-Any machine, is an output-time assembly of Any data that
the user has
related in Any way he wishes, and chosen to be displayed together
Words in the Space Data Category - Members, Compressions and Behaviors..
Different to the other Data Categories, the Space Data Category in the English
spoken
language has few compressions of it own, and when reference is needed to Space
it is
usually fully described. There is no compression that can be added to a word
in the English
that then states that that word is a place.
A few words - 'seaside' for example - properly belong in the Space Data
Category
The principle compression for the Space Data Category is the use of words
naming
matter objects as word for the Space the matter object specifies. Hence most
words in the
Matter Category also have another meaning - and hence a separate Concept
Statement - in
the Space Data Category. Meaning Rules are used to determine which of the
different
meanings of a word in the Matter Data Category are in use.
Just like words in other Data Categories that are in fact names or labels for
items in
that category, Space has its own words and many of these are specific or
general. place
names - 'New York', 'Village'. Place Names have specific behaviors:
1 ) Life Data Category, Data Class Groups. Place names, without any
change in spelling whatsoever are also used with a meaning of a group name in
the Life Data Category. This should not be confused with the '-er' suffix
described
below - 'New Yorker' as in 'he is a New Yorker'. An example of this use is "I
like
the New York mentality. Those guys are fast' In this example, the
word'mentality'
- which is usually but not always - a characteristic of people compression
codes
'New York ' as a people group name. However, the word 'mentality' itself can
be
used with other meanings, as for example 'the tables mentality'. Many words
that
can be used with a place name to show it is used as a people group name also
157
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
have more than one meaning, and hence, when place name
words are used as a
people group name, the potential ambiguity is often removed
by nearby words. An
example of this was given in the words above where 'I like
the New York mentality'
was followed by the words "'those guys are fast.' This
Relative Proximity Coding
A coding where the nearest words code the meaning of a
word) codes 'New York'
with the meaning of a people group name. The speaker could
have said '1 like the
New York building mentality. Buifd it high, build it tall.'
- in this case, it is part of
New York matter group that is referred to on the Co-Reducing
Principle 'New York
& building".
2) Life Data Category, Quality
Place names can be used as Qualities of Qualities. For
example "The box
was painted New York blue' 'He was always New York goad.'
'He looked New York
jumpily at me and said...'. It should be noted that when
creating a Concept
Language, the test question for a meaning is not whether
it the meaning conveys
anything in particular to the person building the language,
but whether anyone
could use the word combination and make some sense at least
for themselves.
Applying this test method of the Any-to-Any machine to
the above examples;
'Could someone say 'New York blue' and make some sense
at least to
themselves?' The answer is 'yes, they could apply that
term to a particular shade
of blue that they consider exists in New York.'
3) Tirne Data Category Meaning When a place name word has
a time
meaning, this is generally conveyed by adding a time word
to the place name
word. An example is 'It is New York time ! day / week.
Send them the routine
report.' 'Tomorrow is New York Thursday. Make sure you
leave early enough.'
4) Space Data Category Meaning. When a place name word
is used in
it's own Data Category it either used with the meaning
of the space it names, or as
a word of quality, but in this case a nearly word Relative
Proximity Compression
Codes it as a quality. For example 'This New York-like
town.' The word 'like' in
this instance codes 'New York' as a quality of something
else, in this case a quality
of the word 'town'. The words 'New York', with no change
of spelling, have
meanings in the Life, Space and Matter Data categories.
Which of these
meanings is in use is Compression Coded by surrounding
words as in these
examples:
Life: This New York-like town's people move just like New
Yorkers .
Space: This New York-like town - I come here just as often
as I
go to New York
158
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Matter: This New York-like town has streets just the same as
New York's
5) Energy Data Category Meaning. Place Name words are generally
Compression Coded with suffixes when required to state an action as a meaning.
"I am New Yorking my dog. He arrives Wednesday'
6) Matter Data Category meaning. Most place names (Space names,
names falling into the Space Data category) have a meaning for the name that,
without any change in spelling whatsoever, has a meaning in the Matter Data
. Category. This meaning can be stated as 'The Matter - material things - of
{place
name}'. For example: 'burn down the village' uses the word 'village' with the
meaning of the material things that constitute the village. A Space can not be
burnt, only a thing - Matter - can burn, but not Space, itself. Space itself
is simply
a volume and has nothing in it at all to burn. Anything that is in Space is
matter,
In this example, the word 'village' is used with a meaning in the Matter Data
Category. Note that when place names are uses with a meaning in the Matter
Data Category, this is intrinsically not a single matter thing, but a group of
matter
things. (See description of Matter groups undder the Matter data category
heading).
The Any-to-Any machine method for creating a Concept Language is that each
different meanings is isolated and assigned a separate Concept Statement.
Life, Quality
Quality Compression Codes. Place names can take some of the standard Quality
Compression Codes, and are used in the spoken language but do not appear in
even the
largest dictionaries, as shown in the following examples:
-y There was a villagy atmosphere to the place
'It was a really New Yorky day
-ous He talked in a very New Yorkous manner
ly 'He was really talking New Yorkily
~ New Jersey is a New York-less state
Non re-un-New Yorkinglessing itl am thinking New Yorkily.Words in the Space
Data
Category - Lengths, Distances and Speeds..
159
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
56) Further Data Category Characteristics - Energy
57) Action Word Codings
58) Emphasis pairs something something
59) Forms taken by Base Concept Words
In the English Language, any word that has one form applying to any of the
physical
Universe Data Categories (Time, Space, Energy or Matter) is invariably found
to have other
forms that apply to all five Data Categories.
Taking the Base Concept of [invite] as an example, and giving one example from
each
Data Category:
Data Category Word Variant Example
Life, Quality Data Class: Invitingly He looked invitingly
Time Invite time invite time, let's send out the invitations.
Space (Location) Invitation go to the invitation
Energy Inviting I am inviting Jae
Matter Invitation put the invitation in the post
60) Numbers.
Number 20, 20'"
Plurals are just one of the number codings. Also includes "some ' A few' , 20,
etc.
Only actions have reasons
61 ) Further Data Category Characteristics - Matter
~ Step 4. Make a full list of all prefixes and suffixes existing in the
language
~ Step 5. Test each Base Concept with all possible combinations of suffixes
and
pre-fixes.
~ Step 6, Assigning Concept Symbol or Concept Statement
~ Step 7. Create Concept Language Definitions
~ Step 7. Create Concept Language Definitions. Treatment of Synonyms
The fifth law of Concept Language states:
'When a given unique meaning can be stated by one or more words or word
combinations in the language being converted to Concept Language, only one
unique
Concept Language Concept Symbol or Concept Statement or combination of these
may we used to represent that unique meaning.'
This law of concept Language effectively means that if a user makes a
statement with
a specific meaning, any other statement with the same meaning should be stated
the same
160
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
way. The first step of achieving this is made during the creation of the
Concept Language
itself.
Take as example, the word 'terminate' in the following order given to a
computer
'terminate printing.' What the user wants done is the same thing he wants done
when he says
'stop printing.' Equally, if the user gives a query order to a computer: 'When
did printing
terminate?' he wants to know the same thing as if he had 'When did printing
stop?'
When words such as 'stop' and 'terminate' can be substituted for one another
they are
often said to be 'synonyms'. While the subject of synonyms is often discussed
in relation to
computer understanding, the subject does not appear very often in practice, as
it is not very
useful. A 'synonym' is defined as 'a word having the same sense as another
(in, the same
language) but more usually either or any of two or more words (in the same
language) having
the same general sense, but possessing each of them meanings which are not
shared by the
other or others'. It is this aspect of synonym words that possess 'meanings
which are not
shared by the other or others' that causes difficulty simply using synonyms
for computer
control with Normal Language.
In the above example, 'Terminate' can be substituted for 'stop' in the words
'stop
printing' or in the words 'When did this printing stop?" However, if it
'terminate is substituted
by 'stop' in other circumstances, where other meanings apply the results would
not be what
the user intends:
'Terminate Joe'. Substituting stop gives: 'Stop Joe'
'When was Joe terminated? Substituting 'stop' gives: 'When was Joe stopped?
'Stop terminating Joe. Substituting 'stop' gives Stop stopping Joe.
Effectively, when 'terminate' is used in relation to a person, it means 'fire'
or "cease
employment' and when it is used in relation to an action it does mean 'stop'.
Which meaning
is in force is determined by Meaning Rules.
Per the Laws of Concept Language, each different meaning of a word should be
given
its own unique Concept Symbol or combination of Concept Symbols, but at the
same time, .
one meaning may only be given one unique Concept Symbol or one unique Concept
Symbol
Statement.
Thus Concept Language translations for 'stop' and 'terminate', for the use in
the
above examples, are:
1 ) If 'stop' is used in an order to a computer:
Stop - do & stop & now
2) If terminate is used in an order to a computer in relation to an action,
definition
is
Terminate - do & stop & now
161
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
However, when 'terminate' is used in an order to a computer in relation to a
person
Terminate - do & stop & employment & now
The above are not necessarily complete Concept Language Statements of the
words 'stop' and 'terminate' but are intended to illustrate the manner in
which identical
meanings between words are defined identically, and non-identical meanings are
defined so
that the Concept Language Statement are not identical.
The result is that if a user says 'stop printing' and then asks 'when did
printing
terminate?' the computer wilt be able to give the correct answer. Equally, a
computer told to
'terminate Joe' will launch the employee termination procedure and not try and
stop Joe.
~ Step 7. Create Concept Language Definitions Words with more than one
Meaning.
Each meaning of each word or symbol that is to be used from a given language
is
given its own Concept Symbol or Concept Statement (group of symbols) such that
the
Concept Symbol or Concept Statement assigned to the meaning is unique. It is
the meaning
of the word that is given the Concept Symbol or Statement, not the word
itself. Several
spoken language words can have the same Concept Statement assigned to for
specific
circumstances. In effect, one unique meaning is assigned one unique Concept
Symbol or
Concept Statement that is not the same as any other Concept Symbol or Concept
Statement.
Concept Symbols may be combined into groups, for example, the action of
jumping
now can be stated as 'do & move & jump & time now'. This kind of grouping of
Concept
Symbols is termed a 'Concept Statement.' Concept Statements themselves may be
combined.
The following is an example - using the word 'stop' - showing how different
meanings
of a single word being assigned different Concept Statements when creating a
Concept
Language:
In the following: 'I like this stop', the word 'stop' signifies a location, a
place where
something stops, or where the speaker has stopped:
Concept Language treats this as one, unique, Concept Statement - a unique
assembly of Concept Symbols. For example, a Concept Language might assign the
value:
'stopL' (where 'L' is a way of saying that this use of stop means it is a
location) or, the number
'3214' to this meaning.
In the following: 'Stop printing this' the word 'stop' is an order to cause an
activity to
cease:
162
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Concept Language treats this as another - but also unique - assembly of
symbols.
For example, a Concept Language might assign the value: 'stop' or the number
'3215' to this
meaning.
Once the two meanings have been differentiated in such a manner, when a
computer
receives 'stopL' or 3214 from a language processing unit, it 'knows' this is
'a stop' as in a
location. When it receives 'stop' or 3215, it 'knows' this is 'stop' as in
something is to be
stopped. (Saying the computer 'knows' in this instance, simply means that the
software that
receives Concept Language output is written in such a way that it treats 3214
as a location
and 3215 as something to do).
The ambiguity of potential meanings in words such as 'stop' is removed by
using rules
for each original-language word to determine which of the potential meanings
is in use. Thus
a rule is used to determine whether a particular use of 'stop' carries the
meaning 'stopL' or
the meaning 'stop'. Based on the finding of the rule, the correct Concept
Language value is
provided to the Execution processing software.
Obviously, only imagination limits the number of different ways in which
different,
unique values can be assigned to different meanings of a word with a unique
spelling. A few
alternate examples of the values that could be assigned to the word 'stop' in
the above
examples are: 'stopl, stop2. StopA,~to~. Boo, Booo. , - in the last example
the
two different values are represented by pictorial symbols - a triangle and a
circle; but the two
meanings could equally well be represented by an electronic signal or an audio
signal, or a
different length or format of light pulse, or a light pulse and a radar pulse.
Equally, a Concept
Language adhering to these principles could even be developed using different
frequencies of
light or electricity as Concept Symbols as defined herein.
~ Step 7. Create Concept Language Definitions Different Meanings Depending
on Circumstances of Use
A word does not necessarily have an identical meaning when used as a
statement, as
a command, or as a query. Consider the following uses of the word 'stop.'
In an order to a computer: 'Stop printing'. The meaning is that the action of
printing
is to be stopped. Effectively, the real meaning is 'computer & now & do &
stop.' (This is a
further example of lossy compression, where the fact that the order is to the
person
addresses is 'understood' but is not part of the transmission).
In a query: 'When did printing stop?' The word 'stop' does not now mean the
same
thing in the previous example. It does not mean 'When did printing you & now &
do & stop.'
Firstly, it is not necessarily the person addressed that stopped the printing
and secondly, it is
not an order to stop printing. The meaning of the word is utterly different
and the word 'stop'
now means simply 'do & stop.'
163
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data Recording Consider the following, given as a statement - i.e. data - for
a
computer to record and otherwise take no action: 'stop printing.' No action is
required, and
therefore the word does, not mean 'you 8' now & do & stop,' but instead means
'person
addressed & do & stop.'
Essentially, the sentence construction used in the above three examples is
quite
similar, and in two of them it is totally identical, but the nature of the
item - Command, query,
or data recording - considerably changes the exact meaning of the word 'stop'.
Following the rules of Concept Language, each of the different meanings should
be
assigned a unique Concept Symbol or Concept Symbol combination, and in the
English
Concept Language serving as an example for the implementation of the Any-to-
Any machine,
these are:
'Stop' in a command computer ~ now & do & stop.'
'Stop' in a query do & stop
'Stop' in a recording Person addressed & do & stop.'
Consequently, one of the methods required to create a Concept Language is to
review
every word to be translated from the spoken language into Concept Language and
ensure
that the Concept Symbols or Concept Statement with the correct meaning is
assigned to the
word for each of these uses.
~ Step 7. Create Concept Language Definitions Different Meanings depending
on Addressee
Not only does the meaning of the word change depending on whether it is given
to the
computer as an order, a query or data to record, but the meaning of a word can
also change
depending on who says it and who it is addressed to. Because of this, Concept
Symbol
assignment to words needs to take account of these potential variations in
meaning. This can
be desirable when content is being recorded in Concept Language, and also in
the co-Any-to-
Any machine Data RElation Table, where different "Personalities' group
together different
functions such as accounting. ,
If a boss says to a junior: 'Report to me' this effectively means 'come here'
But one person says the identical words to an equal: 'Report to me' he is
effectively
saying 'give me a report' - which report he wants is not specified but is
required.
If a boss says to a doorman: 'Give me an account' the likely response is:
'about
what?"
But if the identical words: 'Give me an account' are addressed to an
accountant, the
likely response is ' which account?' or 'whose account?'
Consequently, one of the processes in creating a Concept Language is to review
every word to be translated from the language into Concept Language for
communication
164
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
pairs (boss junior etc) where a meaning can change depending on who says it
and who it is
said to. When such a pairs is discovered, appropriate rules should be written
to check for the
existence of the pair and to assign the correct Concept Symbols or statement
to the pair.
Step 8: Review all Alternates
Step 9: Classify Operator words into different Types
~ Step 10. Create and Test Meaning Detection Rules.
Meaning Rules and Operator Rules
The process of translating a spoken Language such as English into a Concept
Language is governed by rules, called 'Concept Language Translation Rules.'
One type of
rule is used to determine which meaning of a word applies in the specific
situation in which
that word is being used. Some words can be considered to operate on
surrounding text to
compress it, and these words also obey rules that are stated so as to de-
compress the text.
It is a teaching of this Any-to-Any machine that if a human being can
understand a
given text, then there are rules in application in that text, and these rules
can be found by
~ 5 testing individual words in different circumstances to discover what they
are really doing.
Once their true behavior is observed, that behavior can be expressed as a
rule.
As was illustrated in the summary, words can be divided into two major types
of word:
1 ) Meaning Words which have a meaning that relates to something
specific concerning a life, energy or actions space or locations, time or a
matter.
This is the classical use of the word 'meaning' and is similar to, but not in
all cases
exactly the same as the dictionary definition of a Word. Examples are good (a
quality), blue, table, jump. All words of this type can be said by themselves
and
still convey something. Quite by themselves, they mean something. House.
Chair. Think. New, and so on. Such words may add a quality to another word,
but do not otherwise operate on (aff
2) ect the meaning of) the word they are part of, or other associated
words. The word itself may be a compression, but it does not compress anything
else.
3) (Compression) Operator Words. These are words that may or may not
have a meaning as per (1 ) but they also perform some kind of compression
operation on the word to which they are attached or on words to which they are
not
attached. For this purpose, any suffix, prefix or punctuation that has a
verbal
equivalent is also considered to be a 'word', since it does have a distinct,
separate
meaning or operation. Some such words can be distinguished by the fact that
when they are said by themselves, they do not convey a specific meaning - for
165
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
example 'is' or 'of'. There is no such thing as an 'is' or an 'of'. One cannot
'is' or
'of'. Frequently, words have both a meaning and an operation that they do.
Each word in a language - with rare exceptions - is governed by one or more
rules.
Two types of rules, corresponding to the above two types of rules, are defined
for a Concept
Language; hence there are Meaning Rules and Operator Rules.
The reason for this, is that the0 two types of word as distinguished above,
are not
treated in the same manner when translating them into or from a Concept
language.
Additionally, while Meaning Words always appear in the Concept Language
Translation in
some shape or form, Operator Words do not always appear in the translated
version.
Sometimes their presence simply launches an Operator Rule governing the manner
in which
other words are decompression into Concept Language, and thereafter, they
serve no further
purpose in the Concept Language, and therefore, are not recorded.
The decision of which of several meanings of a word is required - and hence
which
Concept Symbol or Concept Statement is to be assigned - is done by one or more
Meaning
Rules. Similarly, Operator Words may have one or more Meaning Rules concerning
their
meaning, but also have one or more Operator Rules that control the translation
process.
Converting between a spoken language and concept language requires one set of
Meaning Rules and Operating Rules to translate spoken language into Concept
language,
and another set for the reverse process. Essentially rules required to
translate into Concept
language are de-compression-type rules, and rules required to translate into
the spoken
language are compression-type rules.
The relationship between these various components is further explained in FIG.
1,
where the heading "Word #' refers to words in a text to be translated into
concept Language.
The boxes numbered 1 to 3 in the columns below the heading "Word #' depict the
first,
second and third words in the statement to be translated. The heading
'Function Rules'
refers to the Function Rules applicable to the words and the boxes numbered 1
to 1 and 1
and 2, depict the Functions rules themselves, showing that Word # 1 has 4
rules, Word # 2
has 2 rules and Word # 3 has no rules applicable to it. Where a word has a
function rule, the
each rule select detects a particular meaning for the word, and hence a
particular Concept
Language Statement that is applicable for that meaning. In order to keep this
Figure simple,
all rules are considered to be simple - ie they test for one condition, and if
it exists, assign a
particular Concept Language Statement to it, and if it does not exist, they do
nothing. The
heading 'Operation Rules' refers to the Operation Rules applicable to
particular Operation
Rules, and the boxes numbered 1 to 3 below the heading, show that Word #1,
Function # 2
has 3 Operation Rules applicable to it, while the other Function rules and
Words have none.
The heading 'Concept Language Statement' refers to the Concept Language
Statement
166
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
applicable to particular meanings of each word and the boxes below the heading
numbered 1
through 9 depict Concept Language Statements. The Headings 'Executions' refers
to
software execution routines that could be associated with particular meanings
of the Words 1,
2 and 3. For simplicity, this Figure depicts each Concept Language Statement
having an
associated execution, though more likely several Concept Language Statements
would
combine to result in a single execution. The oblique arrow from Operation Rule
3 fo Function
Rule 2 of Word 2 is intended to depict that an Operation Rule can affect the
choice of
meaning for a word, and hence the Function Rule to be used.
The essence of a rule that software can execute is:
If condition X occurs, then action Y is taken.
Hence, all Concept Language Translation Rules are stated in this manner.
Further, it
is desirable that the software that does the translating enables these rules
to be changed
easily in order to follow changes in the language. The ability to change a
rule easily is also
desirable because it is unlikely that every possible meaning of every possible
word can be
pre-recorded in software. Hence, new words and their accompanying rules should
be able to
be added easily.
Data Relation Structures
This Any-to-Any machine is an Any-to-Any software construction method that is
unlimited and not intrinsically hierarchical and is capable of manipulating
data on unlimited,
non hierarchical, Any-to-Any basis.
The description describes how the Any-to-Any machine is used to build an Any-
to-Any
data manipulation engine that is not intrinsically hierarchical and is
intrinsically unlimited. The
data processing engine described provides a foundation into which any other
software
application can added provided the Any-to-Any machine teaching is followed in
building the
application to be added. The implementation shown provides the needed
mechanisms to
process data to control the Any-to-Any screen interface.
The Any-to-Any machine is a new method for building software, and is a general
architecture for building any software in such a fashion that all software -
any application -
built following the teachings of the Any-to-Any machine can integrate
seamlessly with any
pre-existing software built me manner. 'Software Packages' in the sense they
exist today no
longer exist; while any particular application may be put into a package and
sold as a
package, once copied into the computer, it forms a seamless whole with pre-
existing
applications already installed. Similarly, all data created with an
application using the
teachings of the Any-to-Any machine, is also a seamless, non-hierarchical
whole, much as a
person's memory is a seamless, non-hierarchical whole.
167
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Because software 'packages' no longer exist as such in software built with the
methods of the Any-to-Any machine, problems of software package integration
and data
integration do not arise as they do in the state of the art today, since all
applications built with
this Any-to-Any machine and all data processed by them are built on the same
pattern and
are intrinsically integrated to begin with. Additionally, Any data that is
entered or stored in the
Any-to-Any machine can be related, fluidly and easily, by the user, without
programmer
intervention, to Any other data that is entered or stored in an application
built with Any-to-Any
machine methods. Any one example of software built with the method of the Any-
to-Any
machine can control, or can be controlled, by Any other example of software
built with the
method of the Any-to-Any machine. The Any-to-Any machine adds functionality to
all existing
software, and adds usefulness to all existing data. The user is limited by the
available
processing power, by available storage capacity and by the physical limits of
peripherals that
are connected to, or in some manner accessible to the Any-to-Any machine, and
by installed
logics, but is not otherwise limited. As will be seen, when the Any-to-Any
machine is used to
create a data engine in the manner to be described, a computer is enabled to
'understand' a
human. The methods of the Any-to-Any machine, as will be described, can be
used to build
software such that an ordinary computer with no special hardware is enabled to
present a
human-like interface to the user, and to handle any data given to it in the
manner that a
human would expect another, subordinate human to handle that data.
This method may be used for controlling a computer and hence to enable an
ordinary
computer to both present an easy to use, human-like interface to the user, and
to manipulate
data provided by the user so as to produce the results a human would expect
another,
subordinate human to produce from the same data input. Colloquially, the three
Any-to-Any
machines together enable an ordinary computer to be 'a computer that
understands'.
~ DEFINITIONS
In the state of the art, the subject of the 'understanding computer' or the
computer that
manipulates data in a human-like manner and which has a human-like interface,
is sometimes
confused by terminology that is used in a conflicting manner by different
writers. Sometimes,
'natural language' is defined as 'being able to dictate to voice recognition
software without
pauses between words'. At other times it is used in the sense of having a
computer that
understands, i.e. _ 'being able to speak to a computer so that it understands
you.' This use
generally carries with it an unstated implication that the computer, having
understood you, will
then also execute what it has understood, while, in fact, the mechanisms
required to execute
a given understanding is a really a separate subject and a separate
technology. Since there
are no clear standard definitions in this field, the following definitions are
supplied for the
purposes of this application and are so used throughout:
168
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Term 'Natural Language' is defined in the sense in which it was first
used,
as 'the subject of being able to speak to Voice Recognition software without
having to
insert unnatural pauses between words.'
The Term 'Normal Language' is introduced as a distinction from 'Natural
Language'. It is defined as: 'the subject of being able to give an order to a
computer,
and receive communications from the computer, in the same language one would
use
to give that order to another human or receive communications from that human
concerning the order.' The term 'Normal Language' does not imply that orders
are
given to the computer using either key or voice recognition - how the orders
are given
i 0 depends on the installed input mechanisms such as keyboard, mouse or voice
recognition.
The Term 'Voice Recognition' is defined as: the subject of taking the sounds
of
the human voice and turning it into text, which is usually then placed on the
screen.
As used herein, 'Voice Recognition Software' is a substitute for a keyboard,
and has
no power to control the computer or cause it to execute anything, neither does
it result
in any computer 'understanding' of the words spoken by the user. So defined,
'Voice
Recognition' is of no further concern to this application, being simply an
alternate input
method.
The Term the 'Computer that Understands' or "Understanding Computer" is
introduced and defined as
"A computer with a hardware-software combination such that a user can
communicate to it, and give it orders in Normal Language (whether the language
is
entered by keyboard or using Voice Recognition software) and which executes
those
orders in a way that appears to the user to be similar to the way a human
would
behave when given the same order."
The 'Computer that Understands' is defined more precisely in terms of the
additional
systems (and their corresponding definitions) required to turn an ordinary
computer into a
Computer that Understands:
The Term 'Language Processing' is introduced and defined as 'The subject of
changing Normal Language communication from the user into something that
software could use, theoretically, to perform Executions if the Execution
mechanisms
existed to perform the action stated by the Normal Language'. Conversely, it
is the
subject of turning communication from the software into Normal Language
communication to the user that he can understand. Language processing is
further
defined as consisting of two complementary systems:
169
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Term 'Grammar Stripping' is introduced and defined as 'the treatment of
Normal Language to render it into something that a computer can,
theoretically, use in
order to control Execution, provided that the needed Execution mechanisms
exist'.
This is the part of Language Processing to do with the user communicating to
the
computer.
Ideally, a computer needs not only to understand the user, but also needs to
be able
to communicate with the user in Normal Language that the user understands, to
enable the
user to understand the computer. For example, if a computer is asked "How old
is Charles?'
the user expects to receive a return communication in Normal Language, such as
'forty-two'.
He does not want to get the answer in a form that he does not understand, such
as in
machine language or Hexadecimal notation. Thus the fullest interpretation of
the 'computer
that understands' requires not only the user being able to communicate to the
computer, but
for the computer to be able to communicate to the user in Normal Language
also.
The Term 'Grammar Formatting' is introduced and defined as: 'the treatment of
the output from the Execution mechanisms of the computer, to render
operational
communications for the user into Normal Language comprehensible to the user.'
This
part of Language Processing is to do,with the computer communicating to the
user.
The mechanisms required for the two parts of Language Processing - Grammar
Stripping and Grammar Formatting - may have similarities, but are not
necessarily the exact
reverse of one another.
Language Processing is further defined as being able to be divided into two
Stages:
Stage I: Processing language to a sufficient degree to enable a computer to be
controlled with either with Normal Language or with a Visual Interface. The
Any-to-Any
machine does Stage I language processing and can provide - if constructed as
described
herein - the necessary processing engine to do Stage II Language processing.
Stage II Processing of language to a sufficient degree to enable a computer to
understand, translate between, and create its own output in any installed
language in any
installed language domain.
The Term 'Order Execution Processing' is introduced and defined as: 'the
collection of
mechanisms needed,to take output from the Grammar Stripping part of Language
Processing
or from an alternate Visual Interface input or both, and use them execute and
control the
Execution of the user's orders. The definition is continued to include 'those
mechanisms that
supply output to the Grammar Formatting system of the Language Processing
mechanisms,
or to an alternate Visual Interface or to both, together with any necessary
replies, responses
or information to the user, or requests from the software to the user.'
170
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
When a computer is given the ability to process Normal Language and then to
execute the result of that processing, it turns out that the potential
variability of the output
exceeds the ability of current software either to display the required data on
a screen or to
output it to a printer or other output device. Screens, printers and other
output devices have
the needed abilities, but in the state of the art, the software supplying them
with output data
does not have adequate flexibility to accommodate a human's requirements.
Hence:
The Term 'Interface Processing' is introduced and defined as: 'that group of
mechanisms needed to control the screen and other input mechanisms so as to be
able to
receive input from a human being in an adequate manner to enable the input to
be processed
and manipulated and produce results similar to the result a human being would
produce if
processing the same data, and the mechanisms needed to control screen output
and other
output in a manner that is adequately flexible to accommodate the requirements
of the
manipulated data.
The term 'Data Component' or simply 'Component' is used frequently in this
description, and is defined as:
'The smallest part into which an item of data can be separated or
disassembled and still retain one - but no more than one - of its original
meanings or
uses as far as the user of the data is concerned".
Thus the words "Jo Brown' form the name for a person. These words can be
broken
into two parts "Jo' and 'Brown'. Each word still retains its original meaning -
Jo still means
'Jo', 'Brown' still means 'Brown'. The word 'Jo' cannot be further broken down
and still retain
its original meaning as a name for the specific person. It can be broken into
'J' and 'o' and
whereas the person might respond to 'J' he will not respond to 'o', 'Dear o,
it was nice to meet
you last week....' However, when it is broken down to 'J', then 'J' is not a
name at all. 'J'
could be a nickname, but even if it is, the meaning of a nickname and a name
are not the
same and they cannot be interchanged. Hence, every aspect of the original
meaning of 'Jo'
is lost by breaking down the word 'Jo' into further constituent parts. Hence,
the word 'Jo'
qualifies as a Component because breaking it down any further does not retain
at feast one of
its original meanings or used. Similarly, the word 'Brown' can not be further
broken down -
for example into 'Br' and 'own' and still retain its original meaning as a
name for the person.
Hence, the datum 'Brown' is a Data Component.
Similarly, with software data type, if a block some lines of code make text
Bold, and
can make text Italic and can underline text, this block of code can be broken
down into three
parts, one of which makes text bold, one of which makes text Italic, one of
which underlines
text. Each one of these blocks cannot be broken into a smaller block - as far
as the user is
concerned - because if so, it will not retain any of its original uses as far
as he is concerned.
171
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Hence, a block of code which makes text bold, qualifies as a 'user software
Component.'
However, as far as a programmer is concerned, a block of code that may make
text bold, may
in fact be composed of several different pieces of code, each of which
performs one of the
several steps required to make text bold. One block of code, for example, may
do one action
such as 'get name of the font name in use' and another 'get (user requested
font) value for
font name in use' and another 'place value in buffer A' etc. Thus, the 'make
text bold' code
can be broken down into three constituent Component blocks of code. Supposing
one of
these code blocks does the action 'place value in Buffer X'. The piece of code
'place value in
buffer X' cannot be broken down and still retain any of its original uses. It
therefore qualifies
as a Software Data Component.
Any Any-to-Any system is defined as:
A system in which Any number of a specific Component type can be related to
Any number of Any Component of the same type in a manner that is not
intrinsically
hierarchical and is intrinsically unlimited.
The life construction coding system, in which Any number of a specific
Component
type - bases, of which there are four - can be related to Any number of Any
Component of
the same type (bases) in a manner that is not intrinsically hierarchical and
is intrinsically
unlimited is an example of an Any-to-Any system. Transistors and binary code
are two further
examples of Any-to-Any systems. When two Any-to-Any systems strictly parallel
one another,
as is the case in the transistor and binary code systems, where both systems
have two
Components - one or off in the case of the transistor and 1 or zero in the
case of the binary
system - they can work closely and easily together; all computing is done by
the binary
system controlling the transistor system.
~ Methods for Constructing an Any-to-Any Machine in Software
An aspect this Any-to-Any machine, is that, in order to create an Any-to-Any
machine
in a computer, the following methods is followed (the words 'Data Component'
are used as
previously defined):
1. Each datum that may subsequently be required to be related to any
other data, is separated into its Data Component parts and these are stored
separately from all other data whatsoever, and should not be stored in a fixed
relationship with any other datum or data. Software, like everything else
stored in a
computer is considered to be just as much 'data' as any user data. Hence,
'data' as
used throughout includes both user data and software data.
2. Any aspect of any item in the computer that may subsequently required
to be controlled individually by the user is itself a datum, and therefore
needs to be
172
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
stored as a Data.Component separately from any other datum or data whatsoever,
and should not be stored in a fixed relationship with any other datum or data.
3. A relationship between items such as (1 ) and (2) above should not be
created by storing them together or by connecting them in a fixed relationship
with
programming.
4. Relationships between user data need to be capable of being created
and destroyed by the user simply by stating they are to be created or to be
destroyed,
without requiring any other action by the user than simply stating they are to
be
created or destroyed.
If the above teachings are observed the result is that Any separately stored
datum is
then - and only then - able to be related to Any other separately stored datum
of any type.
Whether creating such a relationship in any one individual case makes sense or
not, or
serves any purpose or not, is not the concern of the Any-to-Any machine, in
the same way
that that the building that is built with bricks, is the concern of the
builder not the brick-maker.
One description of the Any-to-Any machine then, is that it is a software
building
system that provides a framework and Specification for the storage and use of
user Data
Component 'bricks' and for software Data Component 'tools' to act upon them,
and other
software building materials such as Data Component 'wires' to connect them
together. This
Specification is such that the resulting different types of 'bricks', 'tools'
and 'wires' and can be
used with one another in whatever combination the builder of the software
building or data
building desires. The purpose of doing this, is so that the builder can
produce, easily,
speedily and simply, whatever software and buildings he desires, such that all
software and
data buildings built with the building system are intrinsically and
fundamentally able to operate
together with, are compatible to, related to, and harmonized with, afl other
buildings built with
the same system.
62) Method to Construct an Any-to-Any Machine in Software - Step 1, Data
Components
It was stated above that one of the requirements to build an Any-to-Any
machine in
software is that: 'each datum that may subsequently be required to be related
to any other
data, needs to be separated into its Data Component parts and these should be
stored
separately from all other data whatsoever, and may not be stored in a fixed
relationship with
any other datum or data.'
One method to achieve this, which is a suitable method for small applications
of the
Any-to-Any machine, is as follows:
173
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
1. Each item of user data - such as a letter - consists of a number of Data
Component
parts,
or
'user
data
bricks'.
Per
the
above
teaching
of
the
Any-to-Any
mac hine, in order to construct an Any-to-Any machine,
any kind of data in the
com puter - including the data that is a 'letter' - should
separated into its Data
Component
parts
and
before
storage..
2. The following is an example of performing this
exercise on 'a letter' and
shows
how
'a
letter'
can
be
broken
down
into
its
Data
Component
parts
- or
user
datum
'bricks'.
The
list
given
below
is
not
exhaustive,
but
is
illustrative
of
the
general
principle
and
application
of
the
teaching
of
the
Any-to-Any
machine
that
all
data
should
be
separated
into
and
stored
in
the
form
of
its
Data
Component
parts:
1. One or more Senders' signatures
2. One or more Company logos
3. One or more company Logo texts
4. One or more Sender's First Name
5. One or more Sender's last Name
6. One or more Sender's N Middle Names
7. One or more Sender's titles
8. One or more Sender's qualifications
9. One or more Sender's Company Names
10. One or more Sender's street addresses
11. One or more Sender's Zip Codes
12. One or more Sender's towns
13. One or more Sender's states
14. One or more Sender's countries
15. One or more Sender's Telephone numbers
16. One or more Sender's Fax Numbers
17. One or more Sender's e-mail addresses
18. One or more Sender's web-sites
19. For each addressee, CC or via: 4 - 18 above
20. One or more Titles
21. One or more sub-titles
22. One or more References
23. One or more Dates
24. One or more due Dates
25. One or more Urgencies
26. One or more Priorities
174
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
27. One or more Confidentialities
28. One or more Broadcast ratings (who should see
it)
29. One or more greetings
30. One or more titles
31. One or more Subtitles
32. One or more texts' Contents
33. One or more still Images' contents
34. One or more moving images' contents (if a way
exists to produce this on
paper)
p 35. One or more auditory contents (if a way exists to produce this on paper)
36. One or more calculation Contents (i.e. spreadsheet type calculation)
37, One or more headers on one or more pages
38. One or more footers on one or more pages
39, One of more footnotes on one or more pages
~ 5 40. One or more closing phrases
41. One or more closing sender's title
42. One or more PS (post-scripts)
43. One or more hand-written notes
44. One or more attachments
45. One or more notes concerning the item
46. One or more A Sending Date
47. For each item visible in the letter:
48. One or more display formats
49. One or more display relationship between all above items
25 50. One or more printing formats
51. A conventional software file format
52. Name of the Conventional software that was used to prepare the item and is
needed to view it in the conventional manner.
A manifestation of the fundamental system miss-match and system conflict
between
30 software and a human discussed in the Background, namely the conflict
between an Any-to-
Any system and a One-to-Many system is visible in the above. Each of the
Components of 'a
letter' listed above, is preceded by the term 'one or more' indicating that a
human may use
one or more of this type of Component. However, the two items - 50 and 51 -
that concern
conventional software that may also be used in preparing the item can not be
preceded with
35 this same 'one or more' flexibility that a human can use in preparing an 'a
letter'. If some of
the preparation is done with one commercial word-processor, another commercial
word
175
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
processor cannot complete it, without the first word-processor's data being
manipulated so
that the second word processor can read what was already done.
It will be noticed that the above list of the types of Component parts (the
word
'Component is an abbreviated version of Data Component') needed to build 'a
letter' has
similarities to any detailed list of Component parts that is used to build
something - for
example, a building or a car. Both have their lists of Component. A car is
assembled by
taking all the Component parts in the list and assembling them, following the
assembly plans
and methods. Similarly, in this Any-to-Any machine, 'a letter' is created by
using as many as
necessary of the available Component parts and then assembling them following
the
assembly plans. It will also be noticed that the above list of the types of
Component parts
that can be needed to 'build' a letter, contains Component parts that can be
used - without
any change - as part of assembling a considerable number of different items
that might be
stored in a computer.
Thus, it becomes evident that if an adequate selection of Component user data
parts
is stored in a computer as outlined above, any item that might be stored a
computer can be
created by assembling different combinations of different Component parts. The
principle is
similar to the construction process for a car. It a car is entirely broken
into its smallest
Component pieces, virtually every Component in the car can be used as part of
building an
almost unending variety of objects other than a car. In exactly this manner,
the Components
of 'a letter' can be used as part of building something other than 'a letter'.
An advantage of
this method, ~ivhen it is used in a computer, is that in a computer
environment, it is only
necessary to store one of each Component part. Any item that is required can
then - at any
moment that it is required to be visible or to be transmitted - be assembled
simply by
consulting an assembly plant that states both the reference numbers of the
Component parts
needed and the relationships of those parts. A further advantage of storing
data as Data
Components is that any one Component - such as a telephone number - can be
related to
any number of other Component parts - such as one or more names - or to any
groupings of
Component parts. However, this is only possible provided that a fixed
relationship is not
created between any two or more Component parts, as then one, of the Component
parts
with the fixed relationship can not be related to a third Component part,
without relating the
other Component with a fixed relationship also. This desirable method of the
Any-to-Any
machine can be illustrated using the analogy of a car. If a car uses a only
one kind of wire,
and the first assembly stage creates a fixed relationship between a wire and a
headlamp by
attaching wire to a headlamp, then from there on, a piece of that wire can not
be used without
also using a headlamp also, and wherever a piece of that wire is used, a
headlamp would
have to be used also. This would result in a car with as many headlamps as it
has pieces of
176
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
wire - a ridiculous situation that nonetheless accurately represents the state
of the art
software construction method. In effect, the first methods of the Any-to-Any
machine state for
all data, data wires shall first be separated from data headlamps and then
data wires and
data headlamps shall be stored separately. Then, a data wire can be, used
whenever a data
wire is required and a data headlamp can be used when a data headlamp is
required, and
using a data headlamp no longer forces the builder to use a data wire and
using a data wire
no longer forces the builder to use a data headlamp.
The major advantage of this method, is that any one datum Component - such as
a
reference number in 'a letter' - can then be related to any other datum
Component - for
example the same reference number in a note on an account - without also
automatically
relating some other datum Component to which the reference number is firmly
fixed.
Suppose each of the 52 or so Data Components that is listed above as making up
'a
letter' is given a specific value and that the number appearing opposite that
Data Component
in the list is used as a reference number for that value. So No 12 was
'Sender's town' and
this could be - for example - New York, and hence, 12 could be used as a
reference number
for 'New York'. Now further suppose that all 52 reference numbers are stored
with a fixed
relationship to one another as 'Letter to Joe' and that the fixed assembly
that is 'Letter to Joe'
is stored with a with a further fixed relationship to a software package and
with a further fixed
relationship to a particular directory - as in the state of the art, One-to-
Many system. When
so stored, the reference number for New York - number 12 can no longer be used
easily
anywhere else. If it is desired to create a record for (a telephone number)
New York 535
6677, the number 12 cannot be used as a reference for New York, because using
the number
12 automatically relates the phone number not just to New York, but to 51
other Components,
a software package and a directory. In effect the piece of wire numbered '12'
is attached to
51 other pieces of wire, all of which is sealed inside a software box, and the
that is sealed
inside a directory box.
Hence, when a fixed relationship is created between the Components of a
letter, and
the letter, it is no longer possible use or relate a specific occurrence of a
specific reference
number in the letter to occurrences of that same reference number somewhere
else - for
example, somewhere in an accounting package, without also relating or using
the particular
software package and the particular directory. The complexity of relating any
one Component
stored in a One-to-Many system, with any other Component in another One-to-
Many system,
is such that to all intents and purposes, it becomes to complex to use, even
if each possible
relationship could be could be programmed. (If only four types of item exist,
(Letter. E-mail,
spreadsheet, and presentation) and each potentially contains 60 Components,
then the
number of possible difference relationships between the Components is just
under 13'million.
177
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Hence, this requires 13 million software connections to be programmed, and the
same
number of program connections should in some manner be made available to be
selected by
the user. If one further type is added - 'web page' for example, the possible
relationships
jump to three-quarters of a billion.
Because it is effectively too complex in practical terms to program this, the
two
occurrences of the single reference number remain separated - essentially and
only because
they are each solidly related to their respective documents, software packages
and
directories. Hence, data that actually is related, cannot be easily seen nor
can be relationship
be easily detected, nor can the relationship be used easily. 'Object'
programming in the state
of the art has sometimes eased, but not solved the problem, since an 'object'
is itself a One-
to-Many construction. 'An object' as defined in the stale of the art, is in
fact a group of
software actions (Many), grouped together to achieve several (Many) specific
tasks and given
(One) name. The fact that it can be separated into Components that still
retain at least one of
the original functions shows that such objects meet the requirements of a One-
to-Many
construction.
The situation that results - in the state of the art - is similar to when
someone wishes
to bolt a TV antenna to the roof of his building, he is forced to attach his
entire car to that roof
in order to u.se the one bolt he wants. He should do that because that bolt
has a fixed
relationship to his car.
However, when the Any-to-Any machine method is followed, and data is broken
down
into its Components, it now becomes theoretically possible to use or relate
any one datum -
occurrence 1 of the reference number in a letter - to any other datum, for
example,
occurrence 2 of the same reference number in an account or in a note. The Any-
to-Any
machine makes it possible to do so, since the two occurrences can be related
to one another
without forcing or requiring anything else to be related at the same time.
Hence, this first
method of the Any-to-Any machine - to store items in the form of Component
parts - makes it
theoretically possible to enable software to relate Any data to Any other data
- something that
is theoretically difficult with the state of the art methods.
Suppose, for example, that:
1. A letter is written to John Brown, and placed in one directory, in one file
format,
2. John Brown also has an account (held in accounts software, which is
also held in another file format in another location).
3. The name 'John Brown' also appears in several spreadsheets, held in
another fife format in one or many other locations, and
178
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
4. John Brown's address exists in another file format in another location in
an 'address book' and
5. John Brown's address also exists in still another location in the address
book of the accounts software in still another format
Under these circumstances, a user order that should be able to be executed by
a
computer such as: "Give me everything we have on John Brown" can be executed
by a
human, but cannot be executed by a computer. It can be executed if a special
routine is
created to look in all the right places for each occurrence of a name- the
right places
meaning not only the correct directories, but in the correct file, in the
correct place in each
different file format. Doing this requires a special routine to be constructed
for every possible
query. Every single routine will have to be re-written if a single file is
moved or a single new
directory created. In addition to the near-impossibility of discovering the
relationships that
actually exist in the first place, it is equally difficult to execute a
command to group all the data
on John Brown. Just one single user order "make a file out of everything we
have on John
Brown" would be at best a complex piece of logic in the state of the art.
Equally, the instant a
file was moved or a new directory was created the logic would no longer work
correctly. Such
logic would be broken almost before it was written.
However, the Any-to-Any machine enables a computer to store every item - every
letter, every, account, every spreadsheet, every item of any kind - to be
stored is its
Component parts. Using these Components, the Any-to-Any machine then has a
method that
enables a computer to store the equivalent of an assembly plan for a car. The
method
enables a computer to store.in a useful manner, the assembly plan of an item
such as 'a
letter'. The plan that is stored contains the type of each Component, the
reference number
for the Component, the quantity of each Component, and the relationship of
each Component
to each other Component. Then the Any-to-Any machine has a further method that
enables a
computer to use the recorded assembly plan to assemble the 'letter' on demand.
Because these methods enable assembly plans to be stored and used to record
and
re-construct items such as 'a letter', the assembly plan for any item (such as
those listed
above) containing 'John Brown" will inevitably contain Component references to
the
Component 'John' and for the Component 'Brown'. Additionally, the Any-to-Any
machine
contains a method for storing each type of Data Component together with all
other data
Components of the same type, so that a given type of data Component is only
stored in one
place.
The methods of the Any-to-Any machine provide for:
179
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
1. Creating and storing an assembly plan for each item. Therefore, if the
name 'John Brown' is part of an item, one or more of the assembly plans will
contain
the Components references for 'John Brown'.
2. The assembly plan for an item will contain Component references for
'John Brown' if the item itself contains 'John Brown'
3. All Component references of a given type are only stored in one place.
Because of these methods, it is now possible to execute an order such as "Give
me
everything we have on John Brown". This is possible because the assembly plans
can now
be queried, and every assembly plan that contains the 'John Brown' Component
references
can now be found. Thus, the use of the Component storage method enables a
computer to
both to store, and subsequently to find any relationship of any data that
actually has any
relationship to any other data. To this degree, a computer is now enabled to
process data on
an Any-to-Any basis - the same basis used by humans - which is something that
state of the
art software cannot do.
, Hence, the first method of the Any-to-Any machine, namely, storing data in
the form of
Component parts, enables the following desirable, novel and unique actions to
be performed
in a computer:
1. Any number of Any stored Component part or parts can be assembled
into a group with Any number of other Component parts, and the assembled items
can
be manipulated as a group.
2. Any number of Any of the Component parts or Any number of grouped
Component parts can be assembled with Any number of Any other Component part,
or parts, or Any group or Any number of groups of parts, and manipulated as a
group.
3. Any data item can be recorded by storing the list of Component part
references or groups of part references and the relationships of those
references that,
together with the assembly plan constitute the item, and hence, any one
Component
part can be used -referred to - any number of times in those assembly plans.
It is not
desirable to store any Component part twice.
4. An assembly of any type, such as a letter, can be created and/or
stored, by referencing the storage location of each of the Component part or
parts or
groups of parts in it, without having to store the Component parts themselves
or the
groups of Component parts more than once.
5. Because a given part is only ever stored once, Any item containing Any
given part, or Any given group of parts, is intrinsically related to all other
items
containing that part or group of parts by the commonality of reference to
those parts,
or groups of parts contains in their assembly plans.
180
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
6. Any item can be located by specifying a sufficient number of its
Component parts or groups of Component parts, such that the combination of
Component parts so specified is unique and different to all other combinations
of
Component parts that has been stored.
7. Any number of items can be located by specifying the specific
Component parts, and the specific combination and/or relationship of those
specified
Component parts that the required item contains.
8. If there are a series of A, B, C... classes of different types of
Component parts, and the numbers of different Components in a given class is
n, and
the quantity n is unlimited, then the number of different items that can be
assembled,
and equally the number of different selection Specifications that can be
created is:
(An2) x ( Bn2~) x ( Cn2~)......and is effectively unlimited
The number of different items that can be assembled is always less than the
number
of different selection criteria - consisting of combinations of Component Part
references - that
can be created to select any of the created items, since criteria can be
created for which no
Component parts exist. Equally, a criterion can always be created that will
find any item that
exists that will also exclude every other item that does not include that
combination of
Components. For all practical purposes (since the user can add as many
different
Component parts as he wishes in each of the classes A, B, C... ), both the
number of
different items, and the number of different selection criteria are
effectively limitless.
It can be more compressed and compact to store or to transmit the references
to the
Component parts, and their relationship to one another, than to transmit
Components
themselves.
If two or more parties have each stored the same Components, and use the same
Component part references, then an item can be transmitted between them by
transmitting
only the Component references and their relationships. Such transmission is
confidential
from anyone who does not have available the Components themselves. If new
Components
are created by one of the two parties, only the new Components need to be
transmitted when
transmitting Component references and their relationships that contain a new
Component
part. If Components and the references to them that represent items are
transmitted between
parties at different times and by different methods, the item cannot be
reconstructed by
anyone ~ivho is unable to identify the two transmissions as being related to
one another.
63) Method to Construct an Any-to-Any Machine in Software - Step 2,
Classing Data Components with the Data Class Method
The above outlines the general usefulness of the Any-to-Any machine method of
storing data as its Component parts. However, that method is more useful if
methods also
181
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
exist to categorizing or class Component parts into types or calluses, so that
each
Component part of a given class can be stored in the same place. Hence, the
Any-to-Any
machine contains a new, novel and useful method for classifying Data
Components, termed
the Data Class method, as follows.
The first name 'John' of John Brown can be considered to be a member of a
particular
class of Components - those Data Components that are first names. Data
Components that
can be classed as first names of people clearly are likely to form one the
classes, out of a
number of classes of Data Components Classes and values that may be required
to record
and re-create an item.
Throughout the state of the art, data - particularly words, which are
themselves just
one body of data - tend to be categorized or classified either by their
function, or by the
sequence of the characters from which they are constructed.
For example, dictionaries are books in which words are categorized or classes
by the
sequence of the characters composing the words. Additionally, dictionaries are
often
hierarchical - in order to locate other forms of a given word, it is
frequently necessary to first
locate one form of that word, and then, the other forms are found under the
heading for that
word. Keyword searches are a system of finding items using character
sequences.
Grammar is a system for categorizing words based on their function in a
sentence and
is also to a degree often hierarchical - a hierarchy generally exists such as
All words - verbs
- present tenses.
However, human beings do not natively operate using either system for
classifying
data. Additionally, human beings rarely use hierarchies for handling data ,
except when it
suits some particular purpose, such as stating 'Department X is a part of
Division Y', or 'Name
X is part of team Y'.
A human composing a sentence - which is simply an assembly of a type of
different
data called 'words - does not say: 'I need a noun, OK here is my noun list,
now I need the
type 'proper noun', OK, now where is the name I need..... Ah, there it is -
'John'. Now I need
another word, type noun, let rne check my list.... Proper Noun.....Brown." The
human simply
accesses the words he wants in a direct fashion, and says 'John Brown.'
Human beings can be observed to classify things - when they classify them at
all - by
their concept i.e. by their meaning.
A human being, for example, asked "what is good?" may reply, "Cheese, sailing,
Friday, cats, and New York." The words 'cheese', 'sailing', Friday', 'cats'
and 'New York' can
not be classified into a single category in either of the dictionary system or
the grammar
systems - classification by character, or classification by function. For the
human apparently
however, apparently they do all fall into a single category - the category of
things that are
182
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
'good'. The characteristic of the person's categorization of these words is
that they have the
common factor of all being things he labels as 'good'. This is an example of a
classification
system based on meaning, rather than by either function - as grammar - or by
the position of
the characters that compose them - as in a dictionary; and as in keyword
searches.
It is a key teaching and method of this Any-to-Any machine that data - and
words are
one form of data - should be classified by meaning in order to enable a
computer to parallel
the functioning of a human who processes data based on meaning, and that data
cannot be
classified based on character sequences or grammatical functions in a manner
that-is useful
to enable a computer to act in a human-like manner.
The Any-to-Any machine's method for categorizing data into basic Components
that
can then be assembled on an Any-to-Any basis is to use a method termed "Data
Class
Classification' and this method classified words base don their meaning, not
on their
character sequence or grammatical function.
Data Class Classification is an invented method for categorizing or classing
all
categories of data, including words, into classes - termed Data Classes -
based on the
meaning of the data. Hence, a single Data Class contains, or lists individual
Data
Components that have a common meaning or significance. Hence, the word 'John'
has a
meaning, part of which is that it means a first name. Under this method,
'John' classifies as a
Data Class of words, which have - as their common characteristic - a
particular meaning,
namely that all the words in the Data Class mean 'first names'. Hence any word
- for
example a word that grammar might classify as a verb, such as (to) 'telephone'
- if and when
it used as a first name is considered to have a meaning part of which is
'first name' and
therefore, classified as a member of the First Name Data class. When so used
in a given
instance, the word can then be operated as, and treated as a first name.
Hence, if someone
happens to have a name that is Telephone Brown, software can operate the word
or use the
word correctly, and instead of asking which Brown it is to telephone, will
instead ask 'what do
you want me to do concerning Telephone Brown?'
The usefulness of this method is outlined and demonstrated in the following
example:
A word - such as the word 'good' - can be classified as a Data Component
assembly where
3D one of the Data Component meanings is of a single, specific, identifiable
type. The word
'good' is a word with a meaning of Quality. A 'Quality' word is a word that
can be defined as
'a word that states a characteristic of something that is assigned by humans,
and that does
not exist in their absence'. Hence, the characteristic 'good' exists only
because one or more
humans state that something has that quality, and for no other reason. Other
examples of
words of quality are 'fast' 'slow' 'bad' 'heavenly' 'inviting'. 'She. gave him
an inviting look'
states that the look had a Quality, and that Quality was 'inviting'. While the
look could be
183
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
physically measured in every parameter, those parameters would be nothing more
than
parameters in the absence of humans. A human could assign the word 'inviting'
to any look
that falls within given parameters. However, the look meeting the parameters
of 'inviting' is
only inviting because a human said it so, and for no other reason. If humans
had never
existed on earth, the parameters could still exist and be measured - for
example on a rock
that happened to have the form of a person's face - but the word 'inviting'
would not exist.
Hence, 'inviting' and 'good' are examples of words of part of whose meaning is
similar to one
another, that similarity being that they are have one meaning in common - that
of a quality -
and they are both different types of quality.
Hence, the word 'good' is therefore classified - by its meaning - in a single
Data Class
with other Data Component words with the same common meaning (that of
Quality), and
each member of that Data Class is a Quality, but of a different type.
Effectively 'good' is Data
Class 'Quality', Data Sub-Class Type of Quality, value, 'good', and has its
assigned reference
number in that Data Sub-Class.
Once the Data Component 'good' is so classified it can be related to other
words such
as 'cheese', or 'sailing', or 'running', or 'Friday', or 'cats' or 'New York',
or all of them, that are
similarly classified in appropriate Data Classes. Once the relationship of
these Data Class
Components has been recorded, so that 'good' has been recorded in relation to
'cheese', the
basic requirements exist for software to answer a question such as: "What is
good?" with
"Cheese, sailing, Friday, cats and New York". Similarly, the basic
requirements exist to
answer a question such as: 'What qualities do you know?" with: 'good' 'fast'
'inviting' etc. If
queried based on the question "what is cheese like?" the basic requirements
exist for the
query to return 'cheese' _ 'good'.
This example demonstrates the Data Class method that the Any-to-Any machine
uses
to classify Data Components into Data Classes based on the meaning Data
Components that
make up a word.
64) Method to Construct an Any-to-Any Machine in Software - Step 3, Building
Human Data Specifications using Data Classes values as Components.
As discussed in the Background, it was stated that one of the first problems
that
makes Automatic Software Execution of a human's orders effectively difficult
is the inability of
software to accept a human's Specification for an item - such as a document -
on which the
human wants the computer to perform an Execution. In the Background, an
example was
given of an order a user might give to a secretary:
"Get me the e-mail about bananas I sent to Joe on Friday when I was in Boston
and
he was in Chicago"
184
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Now supposing that the user's name - 'me' in the above, was actually Bob, the
Specification in this order can be analyzed as follows:
First Time, LocationActionItem Content Disk Location,First
Name, Name , Town, Type ReferenceTown, Name,
This This Other Other
Side Side Side Side
Bob FridayBoston E-mailE- Bananas C:\12345 ChicagoJoe
mail
Bob's location, the time, and the action itself (emailing) are all things that
are, or can
be known to the software that the created the item. Being known, they can be
recorded by
software without requiring user intervention to record them. If suitable
software did make the
above recording in a suitable database at the time the item was created, then
adequate data
would exist to be able to locate the item based on the particular
Specification given by the
user in this example. Once identified by means of the user's Specification,
the item could be
recovered using the Disk Reference, and, once recovered, could be acted upon
by an
Execution ordered by the user. In effect analyzing human Specifications in
this manner, is
one method by which Data Classes can be derived, and is a useful method to
derive them
when small application are being built.
Analyzing a variety of human Specifications in this manner into Classes of
Data used
by humans in creating Specifications, shows that virtually any possible
Specification for
anything can be analyzed in this manner. Secondly, it is found that there are
no more than
approximately 100 such Classes are required for most applications - for
example, to locate
data manipulated by general office software. (Naturally, because the full
classification is
approximately 100 Data Classes, and the above table shows only 8 Data Classes,
the
Classes shown in the above table give only a representative, summary sketch
and are not
exactly accurate as shown).
Taking the first entry in the table "First Name, This Side", this is shown
containing the
name "Bob": All First Names - Anne, James, Paul and so on - are words that,
out of the
entire available language, form a single Data Class by themselves - the Data
Class of First
Names. Classification of words in this manner is different to classifying them
according to the
methods of grammar, because grammar classifies words by_their function in a
sentence.
Since words are classified by the Any-to-Any machine by their meaning, the
words 'Bob'
'Anne' and so on are classified as 'First Names'. While there are sometimes
similarities with
the Grammar classification of words, there are also many differences, and the
two systems
are not at all identical. For example, if someone is addressed as "Jumping
Jack" or the word
185
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
'jumping' is used as a first name as in: 'Telephone Jumping and ask him to
come to the office
at once', then the Any-to-Any machine would class this use of this word as a
First Name.
When language data classified by the Data Class method, data displays the
phenomenon that one member of a given class is more similar to other members
of that class
in its meaning, than it is to any member of any other Data Class. Thus the
words 'Bob' and
"Anne' are more similar to one another in meaning, than they are to the
meaning of the word
'chair'. Hence, a First Name Data Class member, has the classification
characteristic that any
one First Name is more similar in meaning to any other First Name, than it is
to any other
word whatsoever.
It is a key, unique and novel teaching of this Any-to-Any machine, that a Data
Class is
defined as:
1. A Data Class is made up of Data such that each member of its Class is
more similar in meaning to other members of its Data Class than it is to the
meaning
of any other Data.
2. Data Classes can, and generally, should be further sub-divided into
Data Sub-Classes based on the meanings of the data in the Class, to the point
that
further division is no longer useful for the intended application, or results
in a division
that has no meaning.
Thus the name 'John Brown' can be divided into two words, 'John' and 'Brown'
each of
which have a meaning in their own right. Further dividing either of the words -
'Brown' for
example - into 'Br' and 'own' - results in words that have no meaning as
members of the First
Name Data Class, and hence, further division is not required. Hence, the word
'Brown' meets
the requirements to be considered as a Data Component. Even supposing First
Names
existed 'Br' and 'own' existed, these would be First Names.in their own right,
and not a sub-
division of the name 'Brown' into Component parts that still retain usefulness
in relation to the
person they name. Thus a 'Mr. John Brown' can be addressed as 'John' or as
'Brown', but if
addressed as 'Mr. Br' or 'Mr. Own' these further division will retain none of
their original use
for addressing that person.
Hence, First Names qualify as a Data Class under the definition given above
and the
values in the Data Class qualify as Data Components. Hence, a Data Class is
composed of
values that are one type of Data Components, each of which meets the
definition of the word
'Component' given earlier.
65) Method to Construct an Any-to-Any Machine in Software - Step 4,
Deriving Data Classes
The entirety of a spoken or written language is a transmission medium between
human beings. As such it is self-evident that the language can only contain
words that
186
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
describe phenomena that human beings observe, consider to be so, or imagine.
As such,
two basic divisions of all data are possible.-1 ) Data concerning the physical
universe and all
that is in it, and 2) Data concerning Life - meaning non-physical aspects of
human beings
and other life forms. Software itself cannot manipulate data, but can only
manipulate symbols
that represent that data. Software cannot itself turn a machine on or off. It
can send a
symbol to a printer that a material object somewhere in the printer can then
use as a signal to
do the work of turning the printer on or off. It is the material object that
does the action - the
material object manipulates the actual data; the software only manipulates the
symbols
representing the data. Images and sounds are manipulated by software in terms
of words
and numbers.
Hence, software is a manipulator of words and numbers representing data and in
fact,
since all words are in fact represented in software as numbers, software
manipulates data in
terms of numbers symbols representing the data.
Further, out of all data that has existed and that can exist, the words and
numbers
representing that data that software can manipulate can only be:
Words and numbers concerning the physical universe and all that is in it, or
Words and numbers concerning Life - defined as meaning any aspect of
anything humans can know or experience that can not be classified as being
part of
the physical universe. Essentially, 'Life' can be roughly stated as 'things
that humans
state as existing, that are not physical universe phenomena'. In the absence
of life
'good' and 'bad' do not exist and hence the words 'good' and 'bad' are
syrribols for
concepts that are not physical universe phenomena.
All physical universe observable phenomena fall into one of the following
categories or
can be described with a combination of these categories:
Time
Energy
Space
Matter
The words concerning each of these Categories are viewed by the Any-to-Any
machine as Categories of Data. All words that concern the physical aspects of
the physical
universe fall into one, or other of these Data Categories. Each Data Category
can be broken
down further into Data Classes, meeting the definition of a Data Class given
above.
Life, as far as the data that can be recorded or used by a computer is
concerned, can
be also be broken down into Data Classes and some examples of Life Data
Category Data
Classes are: First Name, Last Name, Qualification, Emotion, Decision, Reason,
Status, and
Quality. All of these have the common characteristic that, if there is no life
on earth, they do
187
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
not exist. This is in contrast to physical universe things - which continue to
exist whether
there is any life on earth or not. In classifying words by their meanings, it
is clear that a
person's body behaves, in the language, as a physical thing, and any manner of
using words
that it possible with a physical universe item is possible with respect to a
person's physical
body.
However, it is equally apparent that some classes of words in the language
behave in
a manner that is completely different to the manner in which words describing
the physical
universe behave. In the language, some types of words only get ascribed to
life forms, and
seldom, if ever in normal usage are ascribed to purely physical universe
objects. Thus a
person may tend to say "The person / dog l cat l bacteria died because it was
sad." But
people do not tend to say "the car ! flower pot / swimming pool l garbage can
! shirt fell apart
because it was sad." Even if humans did say so, and even if the physical
universe
parameters of what constituted a sad shirt for a given person were measured,
while any
number of humans could agree on the measurement of the parameters, they are
highly
unlikely to agree whether a given shirt is 'sad'. Essentially, the shirt is
'sad' because
someone said it is, and not for any other reason.
Thus words representing emotions (of which the word 'sad' is an example) are a
class
of words whose meanings do nat behave in the same manner as words whose
meanings
describe physical universe phenomena. Hence, the different behavior of some
such classes
of words, and the fact that these classes of words da not exist at all if fife
is absent, requires
them to be assigned to a Data Category other than the Physical Universe Data
categories
that is termed - for convenience - 'Life'. Theological arguments are not the
concern of this
Any-to-Any machine, only the behavior of words as used by humans to create
Specifications,
and it is that concern that requires a the Data Category of 'Life' to be
created in software. As
will be shown in the detailed description, words in each Data Category,
including the Data
Category of Life, behave differently from one Data Category to another, and
these differences
between Data Categories should be accommodated and not be ignored if the use
of words as
Data Components to construct data and applications is to succeed.
All words in a language can be assigned to one or other of the five Data
Categories:
Life
Time
Space
Energy
Matter
Words are used in human Specifications and humans Specify items using
meanings,
and hence, any Any-to-Any machine dealing with identification of human
Specifications on
188
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
which an Execution is to act, cannot ignore the meanings of words. As
previously stated, in
this Any-to-Any machine, Words and data are assigned to Data Classes based on
their
meaning, not on their grammatical or other function. However, many words have
more than
one meaning for a given spelling.
When words do have more than one meaning, it is up to the Interfaces - the
Visual
Interface to provide mechanisms to assign words to Data Classes, or up to a
Language
Processing Interface such as the Language Processor to decide to which Data
Class a given
word used in a Specification belongs in each particular instance.
In the case of a Visual Interface, this is easily achieved by presenting the
user with
suitable names - and additional Prompts and Help if necessary - for the Data
Classes
concerned with the particular operation. Correctly done, this results in the
user entering the
word into the correct Data Class himself as per the following example.
Supposing a user
wishes to specify the time for a communication to be sent, and is therefore
presented with
some Data Classes from the Data Category "Time" and further supposing that the
user enters
the word "Bob" as the time for the item to be sent. Either:
The user has already created a Specification for time to which he has assigned
the name "Bob", or
The entry is a new entry to the Data Class of Names of Time, or
It is an error
If (a) then the time named 'Bob' is applied.
If (b), which supposes that 'Bob' is intended as a new entry - a new name for
a
particular time, then it can be defined as a name for a particular
Specification of Time - just as
"Friday" is a name for a particular Specification of Time. Thereafter 'Bob'
can be used as a
Time Specification whenever the user wishes to use it. This process will be
more fully
explained in the Detailed Description.
Or, (c) the word 'Bob' was an error and was not intended to be a Time. In
either (b) or
(c), the Visual Interface should query the user and obtain clarification, and
then act
accordingly.
66) Method to Construct an Any-to-Any Machine in Software - Step 5, Data
Class Integrity Principle & Method
The unique and novel Any-to-Any machine of Data Classes is useful, because it
enables items to be identified due a unique and novel feature of the Data
Class Any-to-Any
machine, termed the: 'Data Class Integrity Principle and Method', which is
defined as:
The meanings of words can be grouped together into groups of similar
meanings, beginning by dividing them amongst the five Data Categories, and
further
subdividing the meanings into Data Classes and Data Sub-Classes. A query
189
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
concerning a given Data Class.can only be satisfied by a value from that
Class, or
from a Class that is junior to that class. Normally, the most junior available
value is
required.
This principle is demonstrated by the following example. If a person is asked
a
question such as "what furniture is in the room?" this question is questioning
for members of
the Data Class Type of Material Thing, Sub Class furniture. The question
cannot be correctly
answered by giving a value from any other Data Class whatsoever. It can be
answered by "I
don't know" or "Someone else may know" which are the human equivalents of "No
data" and
"Check Directory X" but it can not be answered by any value from any other
Data Class
whatsoever, and when one human does attempt to do so, that attempt is
generally met with
increasing irritation. Consider these examples of responses to the example
question:
Question Response
What furniture is in the room? Joe Brown (A response from the Life Data
Category,
First + Last Name Data Classes)
' Happy! (A response form the Life data Category,
Emotion Data Class)
Wonderful. (A response from the Quality Data Class)
Monday (A response from the Time category)
New York (A response from the Space category)
Walking (A response from the Energy Data Category)
A car (A response form the Matter Data Category, but
from the wrong sub-class)
A chair. (The only response that is from the correct Data
Category and correct Data Class).
Only the last response satisfies the question and this serves an example of
the
operation of the Data Class Integrity Principle - that-a query can only be
answered by data
from its own Data Class and the consequent Method - constructing software so
that a query
concerning a give Data Class is queried with the repository for values from
that Data Class
and not with repositories of values belonging to other data Classes.
The Integrity of Data Class phenomenon applies to all data. Thus, for example,
an e-
mail can be sent to any person's name but cannot be sent to "Thursday" (a
Time), or to
"Bicycling" (which is an Action) as an addressee, unless "Thursday" or
"Bicycling" are the
nicknames for people or groups (Nicknames is its own Data Class). Conversely,
if someone
wants to know what was sent to a person, he will specify that in terms of Data
Classes to do
with names of people. He will not ask "What have we sent to Thursday?" -
unless 'Thursday"
is the name or nickname of a person or group. He may ask "what have we delayed
to
190
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Thursday?' - but 'delayed' is a request for an Action with a Time Data Class
value of
Thursday, and is a different question altogether.
It is the Integrity Principle of Data Classes that makes Data Classes a useful
tool for
categorizing Data Components, so that they can be used in creating
Specifications. While
these remarks might be considered to be self-evident and obvious when so
described, this
'self-evident' and 'obvious' information has not before been sufficiently self-
evident to be
recognized or categorized to a sufficient degree to make it useful for the
purposes of
constructing software in the manner to be described.
67) Method to Create an Any-to-Any Machine in Software - Step 6, Using Data
Classes to Create Human Specifications; Method to Return Nearest Truth
It is further a key, unique and novel teaching of this Any-to-Any machine,
that a user
actually creates a Specification for something upon which Execution is to
occur, by continuing
to add values from Data Classes that are (or should be) available with respect
to the item to
be specified, until such time as his Specification is unique. The user
continues to add Data
Class values - Components - until the particular assembly of Components
specifies.exactly
the item or item he wants, and thereby also, exclude all other items he does
not want. As
discussed previously, because of the unique Any-to-Any assembly method, any
item that can
be created can also be specified. The. Any-to-Any machine has a method, termed
the 'Co-
Reducing Concept Method' (that is described in detail in the Detail
Description) that adds
together Component values from Data Classes to make a Specification that is
unique. The
Any-to-Any machine then uses these Data Class values to query recorded Data
Class values
in such a manner that the query proceeds similarly to the manner a human would
process the
same query.
The use of Data Classes as a method for disassembling data into Component
parts,
has the further unique and novel advantages that:
1. Any data can be disassembled in this manner into Components
2. Data be disassembled without accidentally ignoring any particular type
of Data Component
3. All data can then be classified as one or other types of Data
Component - i.e. one or other data Class Value
4. Once an item is disassembled and made into Data Components, the
plan for assembly of any given data item by software can be recorded, and
manipulated, producing the advantages already described from using data in the
form
of Data Components.
Data Classes are hence useful in constructing queries in a human manner and
are
equally useful in responding to them, as per the following- example
191
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Two people may have a conversation as follows:
Person 1: Joe flew to New York
Person 2: Ah. I knew he was going to go.
If a third person later asks Person 2 the following question:
Person 3 to Person 2: Did Joe train to Chicago?
The reply he is likely to receive is:
Person 2 to Person 3: No. Joe flew to New York.
This behavioral phenomenon is termed 'Return Nearest Truth', and this name for
the
phenomenon expresses the fact that if the strict answer to a query is No or
False, the human
expects to receive back the closest or nearest data that is true.
Mechanisms do not exist in the state of the art that enable a computer to
'Return
Nearest Truth' and queries typically execute on an all or nothing basis -
either they find an
exact match, or they do not. Person 3's query, entered into a typical database
query would
yield the answer 'False' or No' - which, as faras a human is concerned, may be
the literally
true answer, but the answer is not the answer that he wants. If a human
receives the reply
"No" from another human, he is likely to re-query in an irritated manner with
"quit being a
funny guy and tell me how he did go then."
Data Categories break down all words into five basic categories, one of which
is
Energy, or, an terms of what can be expressed in a computer, Action. People
habitually
query by Data Category
When did you do it? - requires any available value from the Time Category
Where did you do it? - requires any available value from the Space Category
What did you do? - requires any available value from the Energy Category
What is it? - requires any available value from the Matter Category
When words are classified by meanings, words in a given Data Category can be
further divided into Data Classes. Hence, all words having as part of their
meaning a concept
of Action can be sub-divided into Data Classes, one of which is 'Move'. Words
of Action that
have 'move' as part of their concept can be further subdivided based on their
meaning into
Sub-Data Classes, one of which is 'travel.' Words such as 'fly' and 'train',
when used as
words expressing a type of travel, show what is termed in the Language
Processor a
'Concept Hierarchy' - i.e. one group words with a certain type of meaning are
members of
another group of concepts, with a wider group of meanings.
Thus the Concept Hierarchies of 'fly' and 'train' can be expressed as
Action & move & travel & fly
Action & move & travel & train.
192
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
It will then be noticed that Concept Hierarchies and Data Classes and Sub-
Classes &
Sub-classes are interchangeable. Hence, the Concept Hierarchy of a word of
Action can be
expressed either as:
Action, Type, Subtype, Sub-Sub-type
Or as
Data Category Action,
Data Class Move, (Consequently requiring Data Classes for the other
senior members of the Data Category Action),
Data Sub-Class Travel, (which requires also creating Data Sub-Classes for each
0 of the other members of the Data Class Move). The Data Class
'Travel' then has other members such as fly, train, bicycle,
helicopter etc - in respect of these words when they are being
used in the sense of an Action.
The requirement to Return Nearest Truth in the light of this teaching can now
be
15 expressed as a method for implementing it, as follows:
If the first of the above methods were used, classifying words of Action by
their
meaning into Action Type, Sub-Type and Sub-Sub-Type, the original data - Joe
flying to New
York - and the subsequent query would be entered in the part of the Data
Relation Table to
do with the Action as follows:
Action Type Sub-Type Sub-Sub-Type
DATE
Move Travel Fly
RECORDING
QUERY Move Travel ?
Note that the query does not include the lowest value provided in the human
query,
which was 'Train'
Hence, one of the Return Nearest Truth methods is:
1. Use the Concept Hierarchy of the word provided to query for the lowest
recorded Sub-Data Class value
2. If the lowest value returned matches the value in the human query
return Yes, else return No + the avaifabfe value.
The same rriethod to Return Nearest Truth applies to the 'New York' and
'Chicago'
part of the data and query, except that the Concept Hierarchy for words
concerning Space -
193
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Location - is a different type of concept Hierarchy to that which is found in
the Action Data
Category and hence the Concept Hierarchy of a Town is of the order of
Continent, Country,
TownJCity.
This sort of query is can be processed using only a Visual Interface, but is
best
processed using a Stage II Language Processor. If there is a Stage II Language
processor,
the mechanisms of the Any-to-Any machine enable such queries to be processed.
Other requirements and methods to Return Nearest Truth are the domain of this
Any-
to-Any machine and Visual Interface, and the mechanisms for doing this will be
described in
the Detailed Description. In brief they require that, if an order is given to
do something, a
1 p check needs to be done first to determine whether it has already been done
or attempted,
and if so, what is the status of the action. A few simple Software Modules
work together to do
this Execution pre-check. The result is that if a user orders an action to be
done, such as to
fax a fax to someone about x, the Any-to-Any machine can be made to return
human
responses such as 'Are you sure? You already sent that fax an hour ago?' The
identical
Software Modules also serve to answer questions such as 'Did I do X?
With these methods, the Any-to-Any machine enables a computer to respond to
orders and queries in a human-like manner in this respect.
Method to Construct an Any-to-Any Machine in Software - Step 7, Constructing
the Any-
to-Any Data Processing Engine
Any state of the art database is used to provide a framework in which to store
Data
Components that have been classified into Data categories and thence into Data
Classes and
Data Sub-Classes. The chosen database is compatible with the platforms on
which the Any-
to-Any machine is to be used. Using the chosen database, one table is
constructed called a
'Data Relation Table' that is not related to any other Table. This Table is
unique and different
in that it has no fixed or programmer imposed relationship with any other
table in the classic
Relational Database method. For most of the Data Relation Table fields -
except those that
are used for numbers in the original data - there are also one or more Data
Class Tables.
These Data Class Tables also unique and different in having no fixed
relationship to any to
any field in the Data Relation Table nor are they related to one another in
the classic
Relational Database manner and method. However, when a Data Relation Table
Field exists,
one or more Data Class tables generally also exist. (When a relation is
created in a classic
relational data base between a particular type of value in one table and
another particular
type of value in another table, this is considered as being a fixed
relationship, in that it is a
relationship imposed - fixed - by the programmer and is a relationship that
cannot be unfixed
by a normal user).
194
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Not even one table in the Any-to-Any machine is related to any other Table in
the Any-
to-Any machine with a fixed relationship in the classic Relational Database
manner and
method. (To create even one fixed relationship between any table and any other
table,
immediately creates a One-to-Many machine, and prevents the construction from
being the
true Any-to-Any machine. Depending on the fixed relationships that are created
contrary to
this teaching, the Any-to-Any machine may still work, but in a crippled
manner, that
nevertheless could present some advantages for some embedded applications).
All values of all types of Data Components are entered and stored, each type
in their
own independent Data Class Table. Each Data Component (value) entered in a
Data Class
Table is given its own reference number in its own Data Class Table. Relations
between
Data Components are creating by storing as many as necessary of these Data
Class Table
value reference numbers in their corresponding field of one or more Data
Relation Table
records. Recording several such Data Class reference values in their
corresponding fields in
one or more Data Relation Table fields has the effect of recording one of many
possible
relationships between the reference numbers recorded, and hence between the
Data Class
Component values the reference numbers represent. Because Data Relation Table
records
can be recorded without limit - using logical mechanisms that will be
described - an unlimited
number of relationships between values in Data Class Tables can also be
recorded. At the
same time, no individual value in a particular Data Class Table ever should be
recorded more
than once as once the value is recorded once in a Data Class Table,
thereafter, only its
reference is used - as often as necessary - in the Data Relation Table. Values
that may be
missing from a Data Class Table can simply be entered, and instantly they are
entered, their
reference number is assigned, and thereafter that reference number can be used
at will in
Data Relation Table Records.
As an example of the operations of this Any-to-Any machine method to record
relationships, suppose firstly, that Data Class Table number 1 contains the
value "JOE" with
the reference number 3 and that consequently, the number 3 is entered into
field 1 of a
particular record in the Data Relation Table. Suppose secondly, that Data
Class Table
number 2 contains the value "Brown" with the reference number 7, and
consequently, that the
number 7 is now entered into the second field of the same record in the Data
Relation Table.
The record concerned in the Data Relation Table now contains the number 3 in
field 1, and
the number 7 in field 2. By referring to the appropriate Data Class Tables,
the value 'John
Brown' can now be re-constructed at any time.
This illustrates the basic relation recording mechanism of the Any-to-Any
machine,
namely, that while Data Class Tables store values, the Data Relation Table
stores the
relationships of those values. Different to classic databases, the only
relationship of one table
195
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
to another, is that one table - the Data Relation Table - is a storage area
for reference
numbers of actual data held in other tables - Data Class Tables. All the
tables mentioned
above are not otherwise related.
A major, novel and unique difference is that relationships between data are
not fixed
or hard-wired by a programmer creating specific relationships in the software
itself. With this
method, a programmer does not relate one table to another in the software he
writes, nor
does he relate one phone number to a name in the software he writes, nor does
he force the
user to relate a 'letter' to a specific file name. The unique and novel
difference is that, with
the methods of the Any-to-Any machine, the programmer provides small software
Modules
that enable the user that - at the users request - create and record whatever
relationships the
user wants. Expressing this in an alternative manner, any relationship can be
recorded, and
all relationships are only created by logic that is under the user's control
and not by software
construction that is under the programmer's control.
This method replicates in computer the method used by humans to manipulate
data.
The words - symbols representing data - exist in a person's memory. When the
computing
entity - the person - wishes to manipulate the symbols representing data -
i.e. to say
something - he selects the appropriate words, and assembles them together into
a specific
relationship. Similarly, the Any-to-Any machine stores words in Data Class
Tables, and the
computing entity - the software Modules of the Any-to-Any machine under the
control of the
user - assembles these into specific relationships and then records them - in
the Data
Relation Table. Hence, the absence of fixed relations as used in state of the
art relational
databases is an desirable novelty of the Any-to-Any machine.
As will be shown, any data whatsoever can be recorded using this method, from
a
single name, number or word, to an entire book or library or more. It will be
shown that
numerous advantages arise from this method of storing values and their
relationships.
Method to Construct an Any-to-Any Machine in Software - Step 8, Constructing
Software
using the Any-to-Any Data Processing Engine
Software is a form of data like any other, and the general method of the Any-
to-Any
machine to record data described above therefore applies to software as
follows.
1. Software applications to be written per the teaching and method of the Any-
to-
Any machine are constructed by writing code in the chosen software language.
The choice of
software language is decided by the platform on which the application written
with the
software is to run. Additionally, the construction method for software itself
takes care of a
number of complexities - such as branches and getting data - for which
provision is made in
many languages. Therefore, the desirable implementation is to use the simplest
- and hence
fastest - language that is suitable for,the intended application.
196
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2. Each block of code that is written, is written to perform only one
operation and
hence, meets the definition of a Component. A Block of Code that performs only
one
operation is termed a Logic.
3. Logics are record in a Data Class Table termed the Logic table, in which
each
logic has a reference number just as user Data Components have their reference
numbers in
their own Data Class Tables.
4. Logics are assembled into Field Logics using a type of assembly table
termed
a data Assembly Table, which is hence a table, each record of which stores the
references for
Logics that make up the Field Logic.
5. A Field Logic is a logic that operates on one type of data in one field of
data in
a Data Relation Record. Such Field Logics are normally very small and may be
as small as 2
or 5 lines of code, but do not normally exceed 100 or 200 lines. Such code
does not include
any branches, because as soon as code has a branch, this means the code is
doing more
than one operation, and to that extent, the application has ceased to be an
Any-to-Any
machine and has become a One-to-Many machine to that degree.
6. Once the reference number for Field Logic is assigned, the reference number
for that Field Logic can be stored in one of more fields of one or more Data
Relation Records
in the same manner as described previously for user data.
7. Data Relation Table records containing such Field Logic references in their
fields are a type of Data Relation Table record termed an 'Execution Record'.
If required, the
same Field Logic can be used in more than one field of a single Data Relation
Table
Execution Record. The act of recording the reference number of various Field
Logics in the
appropriate fields of one or more Data Relation Table Execution records,
records a
relationship between them in the manner previously described above.
8. An assembly of the different types of Data Relation Table records -
including at
least one Execution Record - needed to perform one specific operation, is
termed a Software
Module.
In order to create a true Any-to-Any machine in software, the teaching of the
Any-to-
Any machine is that all data, including software, is stored as Data
Components. Hence, a
single Logic is a Data Component and only performs one action. This principle
also holds
true at the level of a Data Relation Table record, where one record, does only
one thing. If
one record does several things, or is several things combined, then a One-to-
Many
relationship has been established in the record, and from thenceforward that
record cannot
be used for anything other than-its intended purpose.
Following the same principle and method as already described in relation to
the
Components making up 'a letter' the Any-to-Any machine splits into its
Components, all the
197
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
activities of 'software' that are generally bundled together as a One-to-Many
structures. In
the state of the art for example software typically includes a manipulation,
potentially one or
more Conditions, etc. Hence, these separate activities are separated, and
hence, Execution
Records operate in tandem with one or more other types of Data Relation Table
records,
such as Condition records, that state Conditions. Condition Records, for
example, state
Conditions that should exist for an Execution to occur successfully. Condition
records thereby
enable Field logics to test each individual field of the Data Relation Table
data record - on
which Execution is to occur - to see if it matches with the Conditions -
stated in one or more
Condition records - that are required for Execution to be successful. Because
of this method,
missing or incorrect Conditions can be found and repaired before Execution is
attempted.
Ensuring executable Conditions exist prior to Execution - and providing
mechanisms to
correct them if they do not - ensures that an Execution will not fail due to
the existence of
wrong Conditions, and therefore, have to re-started from the beginning. When a
given
Execution can have several outcomes, each requiring a different action to be
taken as the
next step, Condition Records also enable the outcome to be tested to determine
which of the
possible outcomes has occurred. A further type of Data Relation Table Record
called a
Director Record can be associated with a Condition Record as a pair, and
contains in each of
its fields, the reference number for the Execution Record to be called if the
Condition in that
field of its associated Condition record is tested and found to be true. In
this manner, any
amount of branching can be handled, but without ever requiring one Field Logic
to accomplish
more than one action.
A software application, such as an application that does faxing, or an
application that
does e-mailing, or screen control software, or interface software, or
accounting software, or
any other application whatsoever, is composed of one or more Execution Records
and their
supporting Data Relation Table records of several different types such as
Condition Records
and Director Records. Such a collection of software records is termed a
'Software Module'
and is generally given a name using the words most likely to be used to
describe the
manipulation it performs. Generally, an 'application' consists of many such
Software
Modules. When a given Software Module in an application is to be executed, the
actual Field
Logics referenced by the Execution Records are looked up, read into memory,
executed and
perform the single function of the Module. This is termed the Run-Time
Assembly method.
Alternatively, when an application is first run, Fields Logics and then
Software Modules
are assembled once per their assembly Specifications, and then stored in an
assembled form
in a special table following a method to be described. If a Software Module
needs to be
corrected, all that is required is to correct the Logic concerned and then re-
assemble the
Software Module. This is termed the Pre-Assembly method.
198
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Frequently used Software Modules, such as the one named 'New Record' that
creates
a new Data Relation Table record can be loaded into memory and kept there
while the
application is running.
When a programmer is missing one or more Logics, he creates the Logics he
needs
by writing a small piece of new code and can then use its reference number
wherever he
wishes. Mechanisms are provided for Field Logics and Execution Records to pass
communications between one to another (such as instructions on where to act,
orders and
completion reports) and to create any needed chain of command. Logics, Field
Logics and
Software Modules collectively, are called Software Units and are ail written
so that they are
independent units:
1. Whose code is complete in itself, and contains all the code required to
perform ONE action - but does not contain necessarily Conditions or other DATA
that
may govern how it acts.
2. Any number of a given type of Software Unit can be assembled and
work with and be used with Any other Software Unit of the same type. Hence,
Logics
can be assembled with any number of other Logics and work together, Field
Logics
can be assembled with any number of other Field Logics and work together, and
Software Modules can be assembled with any other Software Modules and work
together.
3. Any of these Assemblies can exist as recorded assemblies, or
alternatively, can be created by other Software Modules that assemble specific
Modules based on Conditions, data input etc, and to that degree, the
application can
be self-constructing.
In this manner, any required software application can be written, simply and
without
complexity. If sufficient computing power and general computer speed exists,
and the Run-
Time Assembly method is used, then, when no Software Module is active - no
application is
loaded into memory - only one copy of each specific Logic is actually
recorded.
To describe the result of this method of constructing software in the form of
an
analogy, the result is analogous to having a pool of specialized soldiers -
Logics - each one
of which has a single, specialist ability. From this pool of resources, an
army section (a Field
Logic), an army unit (a Software Module) and an entire army (an application)
is specified by
using the reference number of specialist soldiers as often as required. When
an army unit is
required - a Software Module - it can be constructed and used on demand -
without having to
go through any hierarchy to use it and without having to activate or construct
the entire army.
The Software Module that is required is constructed by consulting the Data
Relation Table
Specification - the assembly plan - for the Software Module.
199
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
A novel advantage of this method is that it solves a major problem for
programmers,
which is code that works correctly sometimes, and not at other times, a
problem that results
from code being written - in the state of the art - as a One-to-Many machine,
performing
multiple functions under multiple Conditions. Because of this complexity,
combinations of
Conditions can occur that have not been predicted, and because they have not
been
predicted, a block of One-to-Many code has not been written to cover them, and
the code as
a whole fails. The likelihood of failures of this type is so high, that
extremely lengthy and
expensive testing is required before publishing software, and even so, it is
generally
recognized that most early releases of software are prone to failure. Hence,
the novel
advantage with the Any-to-Any machine is that because the code that is a Logic
only ever
performs a single manipulation, it observably either performs its task
correctly, or it does not.
Each Condition is stated separately and either the specific Condition that
arose is covered or
it is not and it easy to see if it covered. Each Condition is stated as a
single Condition and the
Conditions that are stated are either observably correct or they are not. If a
Condition can
occur that was not predicted, correcting it is a matter of adding a further
Condition Record
that can be tested for the new Condition. Because of this unpredictable
possibility, Field
Logics are tested against all Condition Records accompanying the Execution
Record so that,
if another Condition Record is added in the future for some reason, no other
change is
required than to add the new Condition Record.
Since every software application is built on the same pattern and the pattern
of
Software Modules is set by the pattern of the Data Relation Table, different
software
applications can be added to existing applications by a process that is no
more complicated
than:
Copying the new application's Software Module Data Relation Table records
into the existing Data Relation Table which is already storing existing
application's Software
Modules
2. Copying Field Logic assembly Specifications into the Field Logic Assembly
Table
3. Copying any particular Logics required into the Logics Data Class table.
Lengthy install procedures are no longer required, and because all Software
Modules
are independent, they can be run as soon as they arrive. Naturally, it is only
desirable to copy
those parts of the application that do not already exist in the computer. If,
for example, a
Field Logic already exists to make text boldface, this Field Logic is already
available to the
user to use on any text whatsoever, and there is no need to write, or add a
new, or another
Field Logic to do the same thing. If the new application may require to make
text bold on
occasion, it simply uses the existing 'Bold' Field Logic to do this.
200
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Once an application is copied into the computer in this fashion, the computer
then has
available all the abilities of the Components of the all applications in it,
without requiring a re-
boot. The effect is that the Software Modules of the new application become a
seamless -
and non hierarchical - whole with the pre-existing applications' Software
Modules.
Similarly, since all recorded data is recorded in the sanie pattern, different
bodies of
data can be combined by copying them into the Data Relation Table and Data
Class Tables
containing the pre-existing data. Similarly, the new body of data becomes a
seamless whole
with the previous bodies of data. Because both software and data are built on
the identical
pattern, any Software Module can operate on any recorded,data. (Whether it
makes sense
for it to do so, is up to the programmer and the user. But because the ability
to so exists,
there are no internal limits on what can, and cannot be done).
Because all data is separated into Data Components, and because a Field Logic
is
also a Data Component, and therefore does only one action, any one error can
only arise
from one particular faulty Logic, Field Logic or Software Module or from one
particular field of
faulty data on which they operates or which is used to control how they
operate. Because of
this, any error 1 ) Can be traced swiftly, 2) Can be repaired or replaced
swiftly and 3) The
repair does not affect the functioning of any other software or data.
More precisely and as will be described, because:
Any number of Any values in Any Data Class can be related - using the Data
Relation Table - to Any number of Any values in Any other Data Class, and to
Any number of
Data Relation Table Records or parts of records, and because
2: Any number of Data Relation Table record or records can be related in Any
manner to Any number of Any other Data Relation Table records and to Any
Number of Any
Data Class values, and because
3. Any new Component values can be entered and then used, and because
4. The structure is not intrinsically hierarchical, although hierarchies can
be
created in it if required, and because
5. All of the above can be done without limit,
the Any-to-Any machine method can be used to create an Any-to-Any structural
architecture that is not intrinsically hierarchical and is intrinsically
unlimited. Because of this
structural architecture, the Any-to-Any machine is method capable of creating
a construction
that is capable of manipulating data on an Any-to-Any basis that is not
intrinsically
hierarchical, and that is not intrinsically limited, and is only limited by
the physical
characteristics of the computer in which it is installed. Because the Any-to-
Any machine
methods can be used to construct software that can manipulate data in the same
Any-to-Any,
non-hierarchical, unlimited manner exhibited by human beings, these methods
have the
201
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
innate capacity to be used to construct software that is enabled to emulate
human data
manipulation, with the all advantages that can be derived there from. For
example, one
application of the Any-to-Any machine is to construct a human-like interface,
and doing so,
makes it easier to construct other applications.
Because of these novel and unique features, the Any-to-Any machine can be used
to
build software that is capable of any handling of any data in a manner that
can emulate the
handling of any data by a human, who also handles data on an unlimited, Any-to-
Any basis
that is not intrinsically hierarchical.
Additionally, as described above, the Software Modules built with the Any-to-
Any
machine method, parallel, field for field, records containing the data on
which they operate, a
parallelism that is reminiscent of the parallelism between the
binary/transistor systems, with
the exception that whereas each of those systems can exist in only two states,
a single Data
Relation Table field can exist in any state whatsoever. Hence, data in the
Data Relation
Table is exactly paralleled by Software Modules, which are also in the Data
Relation Table,
and both of these, parallel the fashion in which a human manipulates data.
Consequently, the Any-to-Any machine solves the problems described in the
Background, all of which arise from the fact that state of the art software
fundamentally
conflicts with the manner in which a human handles data, because it is usually
limited, it is
built on a One-to-Many basis and because it is intrinsically hierarchical.
68) Method to Construct an Any-to-Any Machine in Software - Step 9, Data
Relation Table, Outline of Data Class Table Parameters, the Parallelism
Principle
The Any-to-Any method of software construction using Data Classes is
implemented
in software using any standard database. Alternatively, the Any-to-Any machine
can be
implemented partially in hardware and partially in any standard database, or a
specialized
database, using state of the art technology. For example, a CPU can be
constructed to
contain Execution pipe corresponding to each Data Relation Table field and
similarly, chip
memory can also be constructed with one register corresponding to each Data
Relation Table
field and finally, the bus connecting CPU, chip memory and disk can also be
constructed with
one line per Data Relation Table field so that the physical hardware system
closely parallels
the software and data system, which itself parallels the human data
manipulation system.
If this is done, then the most recent Data Relation Table records and
potentially Data
Class Tables can be read into memory that is close-coupled to the CPU.
A CPU is essentially any Any-to-Any machine within the physical limits of its
Components, since Any number of Additions can be combined with Any number of
subtractions for Any length and combined with Any Move of Any value to Any
location that
physically exists. Because of this parallelism between the fundamentals of a
CPU, and
202
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
fundamentals of the Any-to-Any machine, the more closely that CPU and Any-to-
Any machine
are coupled together without intervening One-to-Many mechanisms, and the more
closely the
Micro language used to control the chip is adapted to the Any-to-Any machine
and the chip,
the faster an application built with the methods of the Any-to-Any machine
will be able to
control the processor chip to manipulate data. The Any-to-Any machine actually
requires
three basic types of operation that parallel closely the operations performed
by a chip:
- Database query
- Record comparison
- Translation
- Move
None of these four of operations are much higher levels of operation than
addition and
subtraction, and so can be performed very rapidly by a close-coupled,
specialist CPU chips.
Any off-the-shelf or specially constructed database can be used as the basis
in which
to construct an application built with the methods of the Any-to-Any machine
and which one is
chosen is largely immaterial and is decided mainly by suitability for the
intended application.
The main requirements for the database are that it should have the ability to
query its fields
and return values matching the queries, and that there is some way to supply
it with queries
using code written in a language such as C++ or Java, and to obtain back the
records
matching the queries. Most databases have this ability. As will be shown, the
Any-to-Any
machine uses almost none of any other logic that may exist in the database.
The Any-to-Any
machine's prime requirement is a storage medium that can store a large amount
of
information on disk in a tabular format, and if unavailable, even this
requirement can in the
state of the art, be constructed in virtually any computer language by almost
any competent
technician. For most applications, such as multi-user, multi office use, the
larger the capacity
of the database program the better, although small and particularly embedded
applications
built with the Any-to-Any machine method can be created in small database
programs. If the
Any-to-Any machine is to be used to create an embedded application then a
Database
designed for embedded applications can also be used. The database used can
either be a
single platform database, in which case an application built with the Any-to-
Any machine
methods is single platform, or multi-platform, in which case an application
built with the Any-
to-Any machine methods can be multi-platform. The software construction
methods of the
Any-to-Any machine can be used with any computer language that can construct,
or use a
database and that can manipulate numbers and/or words.
An application is constructed with the Any-to-Any machine methods firstly by
creating
a large table, called the Data Relation Table in the chosen database program.
As its name
implies, the sole purpose of this Data Relation Table is to record the
Relationship of Any Data
203
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Component to Any other Data Component, and this table is the heart of the Any-
to-Any
machine. It is a recorder of relationships between data.
The Data Relation Table in most normal applications - such as that used in an
office,
for example, contains approximately 150 fields of which 50 fields are
concerned with the
administration of the table itself and this is sufficient to record all types
of data likely to be
encountered in an office environment. The number can be more, or less,
depending on the
intended application; the exact number and even the exact nature of each Data
Relation
Table field is not critical to the Any-to-Any machine.
Most, but not all, individual fields in the Data Relation Table are each
serviced by one
or more tables, termed Data Class Tables - A Data Class Table does not usually
service more
than a single field in the Data Relation Table but is not prohibited from
doing so, provided that
other requirements described in the Any-to-Any machine are met. Most Data
Class Tables
require two fields, one for the value and another for the reference to that
value, although
some require more.
The Data Relation Table does not usually hold actual values (unless these are
themselves numbers, and unless the Components themselves are being recorded in
Data
Relation Table records of Component type) only the relationships between
values. All values
(except numbers) are held in the Data Class Tables.
Each Data Class Table holds only ONE type of data building block or software
building
block. Each single record entry in a Data Class Table contains (or refers to
the disk
reference containing) ONE of the possible building blocks of ONE type, each of
which is a
Data Component that is one thing but is not two things, or does one action and
does not do
two actions (as per the Any-to-Any teaching of the Any-to-Any machine). Hence,
the Data
Class Tables between them contain all the Components required to assemble any
data, and
the Data Relation Table states how the Components are assembled - it states
which
Components are in the assembly and how the Components in the assembly are
related to
one other to create any given data. The actual data itself - the software or
user data that is
stated in the Data Relation Table - can be created at any time by looking up
the references
contained in each of the fields of the one or more Data Relation Table records
concerned,
and finding the corresponding values in the corresponding Data Class Tables.
Between then, the Data Class Tables contain all the data anywhere in the
computer
(except that of the operating system, which can, however, also be written in
the format of the
Any-to-Any machine, but does not have to be so written). Each Data Class Table
contains
only data of one specific type. The data contained in a Data Class table can
be either the
data itself, or a reference to the disk address of the data, at the option of
the programmer.
Where the size of the data in a Data Class Table is small - such as data in
the First Name
204
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data Class where a first name seldom exceeds 30 digits, there is reason to
keep the data in
the Data Class Table itself. Where the data entry in the table can be lengthy,
such as for the
"Content" Data Class it may be optimum to keep the data on disk and keep only
the disk
address of the data in the Content Data Class Table.
Whenever the programmer chooses to keep the data itself in a Data Class Table,
rather than keeping the disk reference for the data in the table, provision
should be made so
that the length or size of the data held in the Data class table record is not
limited - this is
desirable in order to preserve the Unlimited nature of the application. This
can be achieved
either by putting over-large entries on disk and recording the disk address
instead of the
value itself (and writing logic using the data accordingly) or by putting the
remainder in a
second, companion record and writing logic to use the data accordingly. Every
single field in
a Data Class Table should be handled in this manner so that the length or size
of data is not
limited. Various other Any-to-Any machine methods (covered in the Detail
Description) are
used by the Any-to-Any machine to ensure that an application built with the
methods of the
Any-to-Any machine is the unlimited.
The 'Content' Data Class is the Data Class that in a first level application
of the Any-
to-Any machine keeps the actual content of an item in a generic format such as
ASC11 so that
it can be re-used by any application built according to the Any-to-Any machine
principles. In
the case of a letter, the "content" is defined as the body text, and the
following things that can
be found in a letter are examples of some of the parts of a letter that are
not classed as
Content, but fall into other Data Classes: the addressee Name and address, the
greeting, the
date, the priority, the urgency, the title, subtitles, any attachments, any
inclusions such as
photographs, the format, the name of the software that prepared the letter,
the signatory, the
signatory title etc. Separate 'Content' Data Classes exist for different
media, such as
. drawings, still images, moving images, and sounds.
While Data Class Tables do contain actual values, the Data Relation Table
usually
does not contain values as such, only references to them (unless Components
are being
recorded in the Data Relation Table). These references are in terms of the
record number of
the record in the Data Class Table servicing that field of the Data Relation
Table that contains
the value concerned. For example, referring to the First Name Data Class,
suppose that the
First Name 'Bob' is record number 3 in the First Name Data Class. When a Data
Relation
Table record needs to show the First Name "Bob" it shows in its First Name
Data Class Field,
the number '3', which is the reference number = and the record number - for
the value of
'Bob' in the First Name Data Class Table.
The fact that a specific type of user data and the specific software. code to
act upon
. _ that user specific user data type are both held in the same field
(although of a different
205
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
record) and in the same format - i.e. as a Data Class reference number - is
termed the
'Parallelism Principle & Method of the Any-to-Any machine' and has several
desirable results:
1. It ensures that the type of data and the software to act upon it, are
aligned.
2. Even if a certain software Module - for example - does not use certain
fields, the fact that the field exists (even if not used) ensures that other
software
Modules that are perhaps added later and whose addition was not predicted,
that do
act on those fields, can be copied directly into the structure without
requiring any
change to the structure itself. Hence, preserving Parallelism is more
desirable than
reducing storage space.
Absence of deletions and insertions into the Data Relation Table has the
advantage of
simplicity and Data Relation Tables are not normally deleted nor are records
inserted
anywhere in the Data Relation Table,
A number of fields, termed 'Administration Fields' are provided in each Data
Relation
Table record that are used for administrative purposes. If a record is no
longer required, it is
. marked as inactive in the appropriate Administration field as 'inactive'.
Deletion is not the
used as it can seldom be predicted in advance the useful relationships that
particular records
may have in the future. Similarly, nothing is ever inserted into a record once
that record is
completed, as to do so, effectively deletes the existence of a past fact that
may, at some time
become needed and useful again. If an existing record requires to be 'changed'
this is done
by copying the existing record, marking the record that was copied as
'inactive' and changing
the new record. Since new records are not inserted between old ones the entire
Data
Relation Table as a 'time track' of activity, so that newest records are at
the top. Normalcy,
searches are limited to a past period chosen by the user and software only
goes beyond that
past period if requested to do so by the user.
Several Administrative fields exist that allow different types of Data
Relation Table
records to be created - and hence, different types of user data to be
designated. User data
can be given importance ratings and even the use of two Data Relation Table
fields each
containing a 32-bit number, allows 32 to the power of 32 different types of
record to be
created, and other fields allow for the use of algorithms to control archiving
and eventual
removal of old Data Relation Table records that are no longer importance or
based on any
other criteria, any of which can be stated by the user using Condition
Records; data - or
software - can be archived or made inactive based on any Specification
Conditions and
Conditions themselves are stated in terms of Data Relation Table Condition
records.
Because the location at which any Data Relation Table record was created is
effectively
related to each and Data Relation Table record, data can be archived or made
inactive based
206
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
on Location criteria such as a user permanently changing location. Other
Administrative
fields count what the choices that a user makes when he is given a choice, and
hence, allow
the Any-to-Any machine to learn the user's preferences.
69) Method to Create an Any-to-Any Machine in Software - Step 10, Method
to Identify an Item based on the User's Specification
Referring now to the following diagram, the first line, labeled 'Data Relation
Table'
represents the Data Relation Table. Field names are shown in the Data Relation
Table only
for convenience in understanding this diagram and to. make clear which Data
Class Table
(identically named) is supplying the value reference used in the Data Relation
Table record.
All structures used in an application built with these methods are preferably
not named with
written names and are instead given numbers.
Below the Data Relation Table in the following diagram are shown the Data
Class
Tables that correspond to the Data Relation Table fields also shown in the
diagram. These
Data Class Tables contain actual values (example values are shown) and each
value has a
reference number shown beside it. Similarly to the Data Relation Table, Data
Class Table
names are shown in the Data Relation Table (see FIGS. 19A-H) only for
convenience in
understanding this diagram and to make clear which Data Class Table
(identically named) is
supplying the value reference used in the Data Relation Table record. Data
Class Table
fields are not named with written names and are instead given numbers.
It is a key, unique and novel teaching of this Any-to-Any machine - in
contrast to state
of the art and practice in relational database technology - that fixed
relationships are not
established between any of the tables in the Any-to-Any machine whatsoever as
to establish
even one such fixed relationship is to turn the Any-to-Any machine instantly
into a One-to-
Many machine, with all the consequent disadvantages of One-to-Many machines
already
described. To the extent that the Any-to-Any machine is made into a One-to-
Many machine,
its capacities as an Any-to-Any machine will be reduced, and lead to
complexities. This is
true to the extent that a working rule of thumb in writing software or storing
data in the Any-to-
Any machine, is that if complexity begins to arise, or difficulty arises in
creating a relationship,
this is due to a One-to-Many relationship that has been established
accidentally, or that
existed previously and has not been identified and removed. Hence, the mere
presence of
complexity can be used as an indicator to search for, identify and then remove
one or more
One-to-Many relationships. Simplicity is found to return or appear as soon as
all One-to-
Many relationships are removed. One-to-Many relationships are removed using
the Any-to-
Any machine method of separating any One-to-Many data relationships into the
Component
parts, and treating each Component individually.
207
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Referring now to the Specification contained in the example order "(Get me
the) e-mail
about bananas I sent to Joe on Friday when I was in Boston and he was in
Chicago". It can
now be seen that every element in the Specification that serves to identify
the item required is
now represented in a single Data Relation Table record - the record numbered 1
in the
diagram above.
Considering now the previous time at which the named e-mail was being
prepared, it
can be seen that all the information appearing in Data Relation Table record
number 1 was in
fact available at the time the e-mail was created and sent. This information
was available,
either from data the user would have to supply in order to create and send the
item at ,all, or
from data that is - or can be made to be - known to Software Modules.
Therefore, all data
shown above can be recorded in a Data Relation Table record without requiring
any more
user intervention than is necessary for the user to create the item he wants
to create. It only
suffices to arrange to record the available data at the time an item is
created. It will be noted
also, that a Data Relation Table record such as this constitutes the
beginnings of Execution
Related memory - memory of what the computer did - that was noted to be
missing in the
State of the Art, where the nature of the problems resulting from that
omission where
described.
It is a fact of human behavior that was described in the Background that a
selection of
the terms used to specify an order - such as to send an e-mail - will be found
in the
Specification given by the user later to recover the item created by the
order. This is a
manifestation of human Execution Related memory, and the mechanism described
above
enables that behavior, to be copied into software. Thus it is clear that every
Unique Command
Specification - the unique Specification used to create command - becomes part
of a Unique
Data Specification - the unique Specification of the item. The remainder of
the possible
Unique Data Specification is made up from circumstances surrounding the
Execution - such
as the user's location at the time and hence, Software Modules are arranged so
that the
circumstances that existed at the time of the creation of an item are recorded
and in some
way related to it.
Hence when an order is given by a user, either through a Visual Interface or a
Language Processor interface, the data concerning the item is recorded in a
Data Relation
Table field as shown in the diagram above. It was previously commented that
the Any-to-Any
machine contains no programmer-imposed fixed relationships as per state of the
art practice.
It can now be seen that it is because of the very fact that the Any-to-Any
machine methods is
that there should be no fixed relationships previously imposed, the user is
free to impose any
relationships between Data Components he wishes to impose. Hence, when the
user now
gives an order, simply by doing so, the user imposes a specific relationship
on certain Data
208
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Components. The specific relationships he imposes by giving his order are
recorded in the
Data Relation Table record of his order. This demonstrates how the Any-to-Any
machine
enables software to capture and record - i.e. to manipulate relationships
between Data
Components in a computer in an Any-to-Any manner that emulates the human's use
of words
- Data Components - in his order to the computer.
In effect this shows that, using Data Classes in the above Diagram as an
example, a
user can now relate Any First Name to Any Time, Any Location for himself or
for the
addressee, Any Action, Any document type, Any location for someone else, and
Any First
Name for someone else, simply by stating what he wishes to do.
A selection of Data Class values exists when something is created, and when
the
teaching of this Any-to-Any machine is followed, these are recorded as per the
above method.
The recorded values can then be used by a human not only to specify to the
computer what
to do, but also to specify and/or retrieve any item created as a result of the
action. With this
method, the Any-to-Any machine solves the following problems discussed in the
Background:
1. How a human specifies something is not understood and can't be implemented
in the state of the art.
2. State of the art software cannot identify an item on which to perform
Execution
3. In the state of the art, software is unable to identify item based on human
Specification
4. There is nowhere in the state of the art software to record an order as an
order
5. Hence, in the state of the art, it is not useful to program Execution
because
identifying the Specification on which to execute is a problem.
70) Method to Create an Any-to-Any Machine in Software - Step 11, Method
used to Query the Data Relation Table based on the User's Specification. The
Co-
Reducing Concept Principle and Method.
Some concepts exist for which a specific word also exists. A word is
effectively a
name, a label, for the concept that is its meaning. The word 'banana' (with
the meaning of
the name of a fruit - there are other meanings also) is an example of a
meaning - a concept
- that is labeled with the word 'banana'. Similarly, the words 'New York' are
a label for a
specific conceptual package of meaning that is New York.
However, as shown by the enormous number of concepts and the relatively tiny
number of available words to describe them, not every concept has its own
word. Humans
nevertheless succeed in transmitting Specifications for virtually anything
using mainly words
and numbers. (Images are used to a lesser extent - humans cannot create images
quickly as
they can create sounds - and humans do not use texture or smells - humans
cannot create
these rapidly either).
209
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
When an Any-to-Any computer machine receives Specifications from a human, for
a
computer to be easy to use, a process or method is needed for handling the
words in a
human Specification that emulates the observed results of a human's word
handling. The
Any-to-Any machine to do this is named the 'Co-Reducing Concept Principle &
Method'. The
Co-Reducing Concept Principle & Method can best be explained by giving an
example of its
operation as follows:
Consider as an example, the phrase "My New York client friend.'
One person starts talking to another and begins with the word 'My'. At the
instant he
says the word 'My' and before he says the next word, he has, at that point
conveyed a
package of meaning to the listener that is conveyed by the symbol he uses the
word - 'My'.
This word symbol is the symbol for a package of meaning. The concept - the
meaning of
'My' is represented by the oval shape below, with the words 'My' in it.
My
'My' is a word that conveys the concept of 'everything belonging to me.' It is
not limited
in any way. Anything that is the speaker's, is related - included in,
represented by - the word
'My'. Equally desirable, everything that does not belong to the speaker, is
excluded and is not
related, does not fall within the meaning of the word 'My' and is excluded by
the utterance of
the concept symbol 'My'.
The speaker now says the next word: 'New York'. To the first package of
meaning
'My' he has now added another package of meaning that is 'New York', conveyed
by the
words 'New York'.
'New York' is a concept that, by itself, is a word relating everything that
person knows
about New York, as represented by the oval shape below with the words 'New
York' in it:
New York
The effect of stating the two words one after the other, is that:
All of 'My' now described has now been reduced to that part of 'my' that
has a relationship with 'New York'.
All of 'New York' has now been reduced to that part of ''New York' that
has a relationship with 'my'
My New York
The two concepts 'my' and 'New York' co-reduce one another.
210
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The person now says the word 'client' which, similarly, is word with the
meaning 'all
about clients'
10
Similarly, the effect of saying 'client' is that:
All of 'My' has now been further reduced to that part of 'my' that has a
relationship with 'New York' and with 'client'.
All of 'New York' has now been further reduced to that part of 'New York' that
has a relationship with 'my' and with 'client'.
The reduction effect continues when the speaker utters the last word 'friend':
Pictorially, the concept that is stated by the complete phrase "My New York
Client
friends' is conveyed by the area in the diagram that is within the area of all
four of the ellipses.
Hence, the effect of adding together the different meanings (represented by
the
ellipses and conveyed by the words used) is to reduce the meaning of each one
of them, until
the concept that is stated is the unique concept that is required. This the
'Co-Reducing
Concept' Method of the Any-to-Any machine, which is stated as:
A Concept that has not been labeled with a specific word is described in
language
either by:
211
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
1. Giving it a name (which may then be called a 'word' if it applies to a
frequently occurring phenomenon, or a 'name' if it applies to only one of
something or
a to a specific group of something), or by:
2. Adding together words that do convey individual concepts in such a
manner that they co-reduce one another's meanings to that part of the meaning
of
each that is common to all.
3. A 'word' or a 'name' is created by 'Adding together words that do
convey individual concepts in such a manner that they co-reduce one another's
meanings to that part of the meaning of each that is common to all.' and then
ascribing to this assembly, an existing or new assembly of characters (a
'word').
Hence, even when concepts are given names as in (1 ), those names are defined
using the principle of (2).
4. A 'word' is defined by using other words as per (2).
5. The order in which the co-reducing concepts are stated is of no
importance to the meaning conveyed by the co-reducing concepts themselves.
6. However, if a particular member of the co-reducing concept group is to
be further described, the one that is to be so described may be coded and
indicated
by the order of the words in the group of Co-Reducing Concepts.
It can be easily seen that the order is not material to the concept itself but
does
indicates which of the concepts is likely to be described next:
My New York client friend
My friend, a client in New York
My client, a friend in New York
My New York friend and client
Actions also operate on the Co-reducing Concept Method. The concepts:
'running, jumping, swimming horse' can be represented pictorially as:
212
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Co-reducing Concept Method is used frequently in this Any-to-Any machine
and is
one of the fundamental understandings, teachings and methods of the Any-to-Any
machine
that enable and make possible the remainder of the Any-to-Any machine.
When the Co Reducing Concept Method is presented in the description of this
Any-to-
Any machine, it is represented by the symbol '&' used with a special meaning
in this
description to mean:
"'&' shows that the two words with which it is used are acting on the Co-
reducing Concept Principle and therefore have a specific relationship to one
another
to convey the meaning of this concept.'
The Co-reducing Concept Principle can be stated simply and colloquially as 'in
order
to Specify something, meanings are added together by stringing their
representative symbols
(words) together, each added symbol reducing the scope of the previous
meanings, until the
remaining meaning is the exact meaning required.' More precisely it is defined
as:
An item is Specified by adding any one word or any one symbol to any other
word, or other symbol with the corresponding result that the Concept
encompassed or
represented by each word or other symbol is co-reduced to that part of the
Concept of
each that is common to the other. The process is continued by adding any other
word
or other symbol - and hence its corresponding Concept - to the pre-existing
words or
other symbol - and hence to their Concepts. Each new word or other symbol that
is
added further reduces the Concepts encompassed by the previous words or other
symbols to that part of the Concept of each of the words or other symbols that
is
common to all of them. The process is continued until the part of the Concept
common to all words or other symbols present is the Concept that the person
wishes
to state.
213
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
(The Concept of a word and the Definition of a word are not identical. For
example,
one Definition of the word 'move' is 'to change the place or position of.' By
'Concept' of a word
is meant ' the entirety of whatever the word states or refers to for the
listener' Thus the
Concept of 'move' is considered to be all of 'move' everywhere, at any time,
done in any
manner by everyone and everything. Some idea of the broadness of what a single
word
means to a person can be obtained by asking someone: 'What do you know about
'word'? -
'What do you know about 'move'?' - 'What do you know about 'banana'?'
The Co-Reducing Concept Principle is desirable to the actual mechanics of how
a
query is run and effectively dictates that, optimally, a query is run in the
following manner, and
that manner is named the Co-Reducing Concept Method (of querying). This Method
does not
require the entirety of the Any-to-Any machine in order to work, but will also
work perfectly
well, and usefully on any state of the art database table:
As many different classes of Data Components (in effect Data
Classes), or values, should be made available to the user as can be pertinent
in
creating a Specification for a given item.
2. When the user enters the first value in a field, the entirety of the
dataset
that is to be queried is queried for that value and the records matching that
value are
displayed if appropriate.
3. As other values are added in other fields or Data Classes, that query is
run, but only on the data subset selected by the existing query. Hence, the
effect is
that the previously selected sub-set is further reduced. Matching values are
displaying
as appropriate
If a previously entered value is changed, then all queries should be re-run as
per (2)
and (3), Matching values are displaying as appropriate.
The advantage offered by this query method compared to the state of the art
database query practice is that the continuous display of records that match
the Specification
given by the user enable the user to continue to refine the query process
until he gets what
he wants and Dynamic Execution Interaction - whose absence was described in
the
Background as being a problem - can now occur. This creates a dynamic - and
faster -
query process in which the user can interact with the result of his
Specification, just as a
human would do if querying a secretary as per the example given in the
Background. This is
in contrast to state of the art query processes, where a query Specification
is given, found not
to produce the result required, the user revises the query and then the entire
query is re-run
on the entire dataset as though it had not been run before.
The second advantage of this query process can be seen in relation to Internet
search
engines, where the entirety of the content found by Internet research is
treated as a single
214
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
lump, when it is in fact composed of many identifiable types of Data
Component. The single
lump is then indexed and catalogued in complex and multiple manners, all of
which are
varieties of One-to-Many mechanisms. Single words, or a few words are then
queried against
the indexes and produce results that lack usefulness. The failure lies not in
the ability to
5' include the required items but in the inability to exclude the items that
are not required, and
eXClusion of items that are not required is an desirable element in Unique
Data Specification.
Parsing the result of the Internet research into the Data Classes described in
the Detail
Description, using automatic routines, combined with querying same on the Co-
Reducing
Concept Method has the advantage of producing an order of magnitude increase
in
effectiveness of search engines, on the Internet or elsewhere.
71 ) Method to Create an Any-to-Any Machine in Software - Step 12, Method
used to Query the Data Relation Table based on the User's Specification. The
Content Data Class Field
Because of the relations of Data Components that the user has imposed on a
Data
Relation Table record by giving his order to create an item (thereby selecting
Data
Components to be record on an Any-to-Any basis) the entire item can be
accessed based on
Any combination of Any of the Data Component values in the Data Relation Table
fields.
The operation of querying the Data Relation Table requires standard query
logic that
is well within the state of the art. When the user supplies - for example -
only part of the
above Specification, the items found by that query may, or may not be unique.
If they are not
unique, the Visual Interface can display the items that do match the
Specification so far given.
The user can add Data Class Values to his Specification as necessary -
eventually, for
example, giving the full Specification cited above - and finding 'the unique
item he requires. It
is then only required for logic to fetch the identified content and for the
Visual interface, or
other output device displaying or outputting all the Data Relation Table
fields that are the data
item in correct spatial relationship to one another.
The actual order given in the earlier example was "(Get me the) e-mail about
bananas
I sent to Joe on Friday when I was in Boston and he was in Chicago" The user
states "about
bananas" and does not state the entire content that is recorded in the Content
Field. Users
frequently refer to some part of the Content of an item as one of the Data
Classes values
used to identify that item. If the Language Processor is in full use, all
Content can be
recorded in terms of Data Classes as described in that Any-to-Any machine. If
only a Visual
Interface is in use then Content is recorded in the Content Data Class Table
as a block.
When a Language Processor is not in use, the 'Content' Data Class field
contains
either the entire Content or a pointer to a disk location for that content, or
a standard
Operating System file name - which is a file number assigned by a Field Logic
operating on
215
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the Content field. When a Language processor is in use, the Content Data Class
field
contains the number of the first of the Data Relation Table records, type
'Content' that contain
that content in Data Relation Table format.
A useful method is to record all Content in the form of Data Relation Table
records -
which requires a Stage I1 Language Processor such as the Language Processor.
Recording
Content in a block in the 'Content' Data Class field is to create a One-to-
Many machine - one
field, many Contents, one Content many meanings, and this precludes accurate
Specification
of any item by meanings contained in the Content. Recording Content as a block
still
provides an order of magnitude advantage - if the other aspects of the methods
described
herein are followed - and also provides a commercially interesting
implementation stage.
Whether Content is recorded as a block, unique to this Any-to-Any machine, the
Field
Logic associated with and operating on the Content Data Class field is
provided with a
suitable search engine for the type of Content record in use in that
particular Content Data
Class Field. If the Content concerned is text, as in this case, then a text
search engine is
used.
As will be described in detail laier, the operation of the query logic is
arranged to be
such that the Data Class values for all other Data Classes are processed first
per the Co-
Reducing Concept Method. Searches on the Content Data Class field are then
done only on
those Data Relation Table records that have been already been selected by all
other supplied
Data Class Values. Effectively, the query process begins instantly the user
enters the first
Data Class Value. If the query logic has a Content Data Class value to query -
such as
'bananas' as in this instance - then this is processed as soon as available,
but only after
processing all values received for other Data Class, thereby reducing the
number of records
whose Content Data Class fields need to be searched.
In the above example then, the query logic will search the Data Relation Table
for
values supplied by the user for all Data Classes values except the Content
Data Class field of
the Data Relation Tabfe, which will be searched last for the value 'bananas'.
Content
searches can be slow if thousands of items should be searched, and placing the
Content
Data Class search last in the query sequence, and only operating the search on
Data
Relation Table records isolated using the other Data Class values, means that
such searches
can be accomplished very quickly and with no perceptible delay for the user.
72) Method to Create an Any-to-Any Machine in Software - Step 13, Further
Relating Data using the Data Relation Table
The above outlines briefly some of the key principles by which an item can be
Specified to which an Execution is to be done. Note that ordering a computer
to create, or to
'get' an item, or to display an item involves both an Execution and a
Specification.
216
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
It should be noted that a key element of an Any-to-Any system is that Any
number of
Anything can be used with Any number of Anything else, and in the case of a
data handling
system, that Any number. of Anything can be related to Any number of Anything
else. It
should be understood that because something is possible and can be done, it is
not
necessarily sensible to do it. For example, it may not be sensible to place a
metal beam on
top of a mile-high, thin and unsupported lamp wire. However, the freedom to
place Any
object in Any relation to Any other object, also allows the mile of wire to be
wrapped round a
metal beam and make the armature of an electric motor. The outcome of the use
of the Any-
to-Any elements is the responsibility of the programmer and the user. It is
the responsibility
of the Any-to-Any machine to ensure that the freedom exists, with the invented
Components,
to use or relate Any number of Any Components in Any relation to one another.
The fewer
restrictions exist, the greater will be the freedom for the programmer and the
user, and the
greater will be the power of the system.
Turning now to methods by which different data can be related to one another
using
the methods of the Any-to-Any machine, further methods exist in the Any-to-Any
machine
than those previously outlined.
It was stated previously that the Data Relation Table - with few exceptions -
does not
usually contained actual values, but only numerical references to values held
in Data Class
tables. The only exceptions are Data Classes - Data Relation Table fields -
where the values
in the class are themselves numbers, such as the Data Class 'Quantity'. It was
also
mentioned that all Data Relation Table fields are only numbered and not named,
and that
Data Class Tables (and their fields) are also only ever numbered and not
named. This novel
method of creating a database, and of recording data in the Any-to-Any machine
confers
several unique and novel advantages other than those already mentioned, and
each of these
further broadens the Any-to-Any system of the Any-to-Any machine, namely:
1. A Data Relation Table can reference Any type of data in Any field; this
is possible as all Data Relation Table entries are reference numbers the
actual data
type - text, image etc - that is referenced by the number is of no importance
to the
Data Relation Table mechanical restrictions that - for example - may restrict
and
prevent storing an image or a number or a sound file in all in one field.
2. Any Data Relation Table field can reference any other Data Relation
Table record.
3. Any Data Relation Table record can reference any other Data Relation
Table record.
4. Any Data Relation Table field can reference any other Data Relation
Table field.
217
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
5.. Any Data Relation Table record can reference any other Data Relation
Table field.
6. Any Data Relation Table, or its Data Relation Table records, or its Data
Relation Table fields, can reference any other Data Relation Table, its
records or its
fields.
7. Any Data Relation Table field can, each in different records, reference
any number of Data Class Tables and their fields.
It is possible to reference Table, record or field, in any other Table, record
or field,
simple because all references are numbers. Because of this, the Any-to-Any
machine can
uses reference numbers in Data Relation Table fields that are actually a multi-
part numbers,
termed Combined Numbers, so that one part of a number can refer to a specific
Table, or
record or field, while a further part of the Combined number references a
value in that field.
Data Relation Table fields and records can be grouped in a large number of
ways with
the methods of the Any-to-Any machine, and all the grouping methods can be
continued
indefinitely.
Since every word meaning that exists can find a place in one or other Data
Category
and hence in one or another Data Class Table, and any Data Class table value
can be related
to any other Data Class value in the Data Relation Table, all knowledge in the
universe can,
theoretically be condensed to a single reference number in a single Data
Relation Table
record using Data Relation Table records that group other records, and cans
also be infinitely
expanded, for example by a field in a Data Relation Table record referring to
an entire record
in which a field refers to another record.
In addition to being related in this manner, however, absolutely all data
referenced in
the Data Relation Table is however, related between itself. Thus entering a
single datum as
query - for example, the word 'Joe' - will find all Data Relation Table
records containing 'Joe'.
Any one of those records - for example - that is viewed as a result of the
query, is similarly
related to any other record having any characteristic of the viewed record. If
a suitable
Software Module exists, and if the viewed 'Joe' record contains the action
'Jump' clicking on
the field showing 'Jump' can be made to find all other instances of 'Jump'
that occur in other
documents or items.
This ability that is enabled by the Any-to-Any machine to relate Anything to
Anything,
is desirable because humans frequently describe one thing in terms of another.
They do this
by using a selection of Data Category and Data Class values, as the following
examples
(using Data Categories) show:
218
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Specifying a person using Time, Energy, Space and Matter:
The guy I am referring to is: the guy who last week (Time) jumped (Energy)
over an
imaginary chair (Space) into the pool (Matter)
Specifying a Time, using Life, Time, Space and Matter:
The Time I am talking about is: The.time when Joe (Life) jumped (Energy) over
an
imaginary chair (Space) into the pool (Matter)
Specifying an Energy using Life, Time, Space and Matter:
The action I am talking about is: Joe's (Life) last week (Time) with his
imaginary_ chair
(Space) and the pool (Matter).
Specifying Space using Life, Time, Energy and Matter:
The space f am talking about is: the one over which Joe (Life) jumped (Action)
into the
pool (Matter) last week (Time)
Specifying Matter, using Life, Time, Space and Energy
The thing I am talking about is: is the thing in which Joe (Life) landed when
he
jumped (Action) his imaginary chair (Space) last week
(Time).
Data can be related to other data by the Data Relation Table method of the Any-
to-
Any machine in with a variety of methods that between them, enable data to be
related in an
unlimited number of ways - between them, these methods enable Any data to be
related to
Any data, without limit.
73) Methods to Create an Any-to-Any Machine in Software - Step 14, Relating
Specification to Execution
- Any-to-Any machine Teaching concerning Execution Basics
As discussed in the Background, a user with no machine assistance brings all
his
toots to the place where he is doing his work, and this is true whether this
work is office work,
carpentry or farming. In contrast, state of the art software reverses the
normal process and
requires the user to move to the tool, or to the shed where particular types
of tools are stored.
Software will be easier to use if it works in a similar manner to the way the
human normally
works, and hence, if all tools are available at the worksite. Part of this is
that it is axiomatic
that every tool should be available without having to do something else first
in order to use
that tool, just as a user does not expect to open the hood of the car to
connect the brake and
then go somewhere else to use it. In other words, for the best ease of use,
all tools should be
accessible in a non-hierarchical manner.
In the state of the art, all application software tools are only available for
use through
hierarchies. A typical minimum hierarchy is Program X, Open a file (tools not
available until a
file exists), Tool X. Part of the Any-to-Any functioning of a human is that -
like most of a
219
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
human's functioning - it has no hierarchy. Part of an Any-to-Any structure is
also the
absence of hierarchies, because as soon as one exists, Anything can no longer
operate
directly with Anything, only via a portal or channel, and direct relationships
are no longer
possible and an Any-to-Any system no longer exists. The relationship becomes
some variant
of One-to-Many, the One being the head of the hierarchical channel and the
Many being the
braches of the hierarchy. For example, a human neither says "Quantities, type
1, Thing, type
furniture, type chair, Action type existence, type - is, Quality, type
positive, sub-type good" nor
does he go through other hierarchical mental evolutions in order to take and
speak the words
'a chair is good." He picks the tools he wants - in this case, word tools -
accesses them
directly without going through anywhere else to do so, and assembles them in
milliseconds,
and uses them.
In order to track with a human, software needs to make all tools directly
available to
the user without involving any hierarchy. Secondly, in addition to avoiding
involving the user
in any hierarchy in order to use any tool, the software itself should avoid,
in its construction,
having to go through any hierarchy in order to find and activate a tool for
the user. As soon
as tools are distributed over a dozen hierarchies each with - for example -
only ten first level
branches and no second level branches, logic then should track which tool is
in which of the
120 branches. When the user may want to use Any tool in succession with Any
other tool,
providing the logic to do this requires complex programming, if it is possible
at all due to the
number of possible variants, which run into millions.
The Data Relation Table is essentially a mechanism for recording the
relationships of
different data and, as previously described, since its contents are numerical,
it can hold or
record the relationship of Any data to Any other data. Software is in effect
just one type of
data, and in that respect just like any other data needed to be related.
Hence, the Data
Relation Table can and hold specific software Components in relation to one
another, and
that forms the basis of the Any-to-Any machine's method for constructing
software.
Similarly to the manner already described in which the Any-to-Any machine
separates
and then stores separately the Data Component parts of a fetter so that they
can be re-used
on an Any-to-Any basis, the Any-to-Any machine applies the same method to
software, and
similarly, stores specific relationships of software Components in the Data
Relation Table.
In exactly the same manner as separating 'a letter' into its Component parts
greatly
increases flexibility, and enables those parts to be used in an unlimited
variety of Component
assemblies, in the Any-to-Any machine method, software is separated into its
Component
data parts. When these are assembled into user tools, this is done so that no
one tool has
any fixed relationship to any other tool
220
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Hence, the smallest building block into which the Any-to-Any machine separates
software is termed a 'Software Data Component' and is defined as
'Either a number of lines of software code that together perform one
manipulation
on one type of Data Component, and that can not be divided further without
ceasing to
function. This is also termed 'A t_ogic'.
- Method for First Stage Separation of Software into its Component parts
A state of the art software package such as a word processor consists in fact,
of many
Component parts assembled together into an assembly that constitutes a One-to-
Many
machine - One software package, many tools. Beneath this surface layer of One-
to Many
machines lies a second layer of One-to-Many machines. A Tool such as 'Use Font
X n text Y'
itself is a complex of One-to-Many machines. One part of the code, for example
performs a
screen manipulation, changing how the text looks on the screen, while another
part of code
changes the file format.
However any kind of item in the computer - including a 'word processor' is
separated
into its Component parts.
The first step to achieve this, is to break down tried and tested state of the
art
applications such as 'a word processor' into the smallest parts - tools - that
a user might need
in the course of his work. These parts then constitute One-to-Many assemblies
that are built
from Any-to-Any software Data Components. Hence the second step to disassemble
'an
application' into software Data Components, is to take each tool and continue
disassembly
until it exists as software Data Component parts, Which can then be assembled
as required,
and the assemblies that are useful stated in the Data Relation Table as
software 'tools' or
Software Modules - such as 'use Font X n text Y'.
The following is an example of performing this exercise on 'a word processor',
paralleling the example previously given for user data - disassembling 'a
letter' into its
Component parts.
The Components of 'a word processor' can be broken down into software Data
Components and the following is a list of a few of such software Data
Component assemblies
that make up 'a word processor'. The list given below is not exhaustive, but
is intended to be
illustrative of the general principle and application of the teaching of the
Any-to-Any machine
that all items should be separated into and stored as their Component Data
parts. In the case
of 'a word processor' the first disassembly step does not produce software
Data Components
- each item in the following list is itself an assembly of Data Components as
will be shown
and in fact produces a list of groups of Components. These software Data
Component
groups however, are the smallest unit that a normal user would want to have
available, as the
user wants access to a Component assembly that does something useful for him.
A single .
221
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
software Data Component is not normally capable of doing something useful for
the user.
Hence, the first stage disassembly produces a list of groups of software Data
Components,
which are termed 'Software Modules' by the Any-to-Any machine.
A 'Software Module' is defined as:
'Any assembly of self-sufficient software Components that are grouped in Any
manner such that a user can Any number of Any Software Module with Any number
of
Any other Software Module in Any Sequence for Any length, each one of which
can be
accessed directly and non-hierarchically, and can used to perform one single _
manipulation that is useful to the user doing his work.'
Hence, a programmer would want to have available all possible Software
Modules, but
a normal user would not normally want to have available Software Modules used
by
programmers as tools to us in building Software Modules. Any given nornial
user might, or
might want to have available Software Modules with which to tune the
performance of the
underlying computer or operating system.
Disassembling 'a word processor' into the groups of normal user Software
Modules
Components gives a Tong list of Component assemblies, of which the following
are examples
of manipulations to do with manipulating text to give the text letters
particular visual
characteristics:
Font Name
Regular
Bold
Italic
Bold Italic
Font Size
No underline
Single Underline
Underline words only
Double underline
Dotted underline
Thick underline
Dash underline
Dot dash underline
Wave underline
Strikethrough ... etc
In. normal use, any of these may be desirable whenever any kind of text is
being
worked on, regardless of whether this text occurs in 'a word processor' or in
'a graphics
222
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
program' or any 'program' whatsoever that has any text at all in its output.
It is of no
consequence whatsoever to the user whether the text is in what is called - in
the state of the
art - a word processing document, or in a drawing program, or in a
spreadsheet, or in a diary,
or in telephone software, or in a database or in any other program whatsoever.
If text is
present then any of those Software Modules (tools) - as well as every other
Software
Modules in a state of the art word processor - need to be available whenever
text is being
worked on, rio matter whether or not the item being worked is packaged or
named as 'a word
processing document' or not. Similarly, if numbers are present, all Software
Modules (tools)
found - in the state of the art in 'spreadsheet software' - need to be
available. If a drawing is
being worked on, then all drawing tools need to be available, and both
spreadsheet tools and
drawing tools need to be available when text is being worked on etc. (The user
may want to
calculate some of the text, or draw boxes round it or shapes. over or under
it, etc.).
Since it is difficult to predict what a human - who works on an Any-to-Any
basis - will
want to do next, this means in practice, that All tools should be available
All the time.
In creating software that a human can use easily, it is desirable to
differentiate
between what should, and what should not be directly accessible to the user at
all times.
Drawing from comparison with a machine that billions of humans use easily and
with success
- for example a car, or a television - it is clearly acceptable if specialist
user or a specialist
should 'lift up the hood' and service a car or make an adjustment, so that the
brakes work
better. But, is not acceptable if, when the user is driving, the driver should
stop and connect
the brake pedal. In effect, it is not acceptable for the user to have to stop
what he is doing in
order to do any operation, but it is acceptable if the user should stop to
adjust the manner in
which that operation occurs. Hence, while all software should be broken down
into its
smallest possible Data Components per the teaching of the Any-to-Any machine,
and each of
these stored separately, all groups of software Data Components - all Software
Modules -
that perform a given manipulation that a user could want performed, need to be
accessible to
the user at all times, without stopping to 'lift the hood'.
Hence, the question is not whether software should be broken down into
software
Data Components as per the definition of 'Component' in use in this
application, only a
question of visibility and availability of those Components and Component
assemblies -
Software Modules - to the user.
This makes it clear that while all software Data Components should be able to
be
available and visible, those the user normally wants available are groups of
Components that
perform functions he considers useful.
What is accessible and displayed and what is not accessible and displayed, and
for
whom, is the rote of the interface mechanism, but in general, both the
availability and the
223
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
visibility of any given tool needs to be able to switched on or off, and the
Any-to-Any machine
provides for this. It is the role of this Any-to-Any machine to be able to
manipulate any Data
Component and any groups of Components, including software Data Components and
Software Modules that are groups of software Data Components, and to provide
mechanisms
. to manipulate these, including mechanisms to group them in any manner that
any use user
may consider desirable. In the case of software then, the Any-to-Any machine
manipulates
software Data Components and provides mechanisms for grouping these into
groups that are
useful, namely, Software Modules.
- Method for Second Stage Separation of Software into Groups of Component
parts..
In order to build an Any-to-Any system, software itself needs to be separated
into its
Data Components - called software Data Components when the Data Component
refers
specifically to a Data Component used in what is normally called 'software' -
and these should
be stored separately. Hence, it is desirable to further disassemble the
Software Modules -
such as those listed as a result of the first stage disassembly of 'a word
processor' into
classes of software Data Components, as follows:
At its most simple and most basic, any software performing just one single
manipulation consists of - or requires - the following eleven main types of
groups of software
Data Components. Other software Component types that appear to exist are
usually just a
variant of one or other of the following eleven types, or a sub-group composed
of some of the
eleven types. In the state of the art, these .eleven types of groups of
software Components -
or at least those other than user data - are often lumped together and given
the global name
of 'software'.
1. Input Data that is to be manipulated,
2. Conditions that the manipulation requires in order to execute
successfully,
3. Logic that does the Manipulation - code that produces a specific
change in input data, thereby producing Output Data.
4. Output Data that results from the manipulation.
Error Handling - what to do if the data will not execute, or executes with an
error for
some reason - is often treated as separate subject 'error handling' only
consists of the exact
same Components already listed:
Data that is to be manipulated - the error data
Manipulation Conditions (optional)
Logic that does the Manipulation - the logic that does something with
the error such as display it, or shut down the system.
224
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data that is Output as a result of the manipulation - such as the actual
error message or the actual system shutdown command.
As the above list shows, an error output is simply one of the possible outputs
from a
given manipulation and is, in fact, a complete new piece of software that also
performs one
action, and has the same Components and requirements as any other software
manipulation.
Additionally, since software's work may need to be visible, the following may
also be
required:
5. Data Label. Optionally a Label or Labels may be required to inform the
user of the nature of the input or output data, or to tell the user the nature
of the input
data required. A 'Data Label' is considered to be a short, cryptic description
of
something, question about something, or instruction about something.
6. Prompt. Optionally a Prompt may be required to inform the user of the
nature of the input or output data, or to tell the user the nature of the
input data
required. A 'Prompt' is considered as a single sentence, phrase or clause that
is a
description of something, a question about something, or an instruction about
something.
7. Help. Optionally Help may be required to inform the user of the nature
of the input or output data, or to tell the user the nature of the input data
required
'Help' is considered as being a multi-statement description about something,
question
about something, or instruction about something. Help on a single item - for
example,
concerning a single Data Component - is considered as capable of having
infinite
gradients of increasing detail from a couple of sentences, to an entire book
or library.
The difference between Data Labels, Prompts and Help is considered simply a
matter of level of detail. All of them are intended to describe something for
the user,
question the user, or instruct the user to do something. Hence, there is no
intrinsic
categorization of Data Label, Prompt and Help based on function, as any one of
them
can perform any function of which this type of text or illustration is
capable, i.e.
Inform, question, or instruct. The difference between them is the level of
detail for
each one. Simply because they are only different levels of detail, a
particular Data
Label always does have a relationship to a specific Prompt and to specific
Help. The
situation can be likened to a pyramid or cone in which the layer at the base
represents
all knowledge on something, and the layer at the cone represents a label for
that
knowledge, and an infinitely variable detail is available depending on the
height at
which the pyramid or cone is entered.
225
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Labels, Prompt and Help each have certain characteristics of where they can
best be displayed, and how they can best be stored. Thus if a user wants total
detail
on a particular Data Component such as 'First Name' it is hardly convenient to
store
every known book on 'First Names' in one field of one Data Relation Table Help
Record, but these could indeed be stored on disk.
8. Input control, where and how the user can enter data to be manipulated
9. Output control controlling where and how the user can see, or receive
or send or perceive the output resulting from the manipulation.
Finaily, unless the Software Module is to operate in complete isolation, it
requires:
10. Communication Out - a place and a manner to pass instructions or data
to other software
11. Communication In - a place and a manner to receive instructions or
data from other software.
Input and Output data may or may not be user data but is recorded and handled
as
already described for user data. This leaves nine types of software Data
Components that
are specific to software.
74) Methods to Construct an Any-to-Any Machine in Software - Step 15,
Constructing Software using Software Data Components
1. Method for Recording the Nine Different Types of Software Groups of
Component Parts
These nine types of software parts are each assemblies of software Data
Components. Following the methods and teaching of the Any-to-Any machine for
creating an
Any-to-Any machine in software, the method used is to record and manipulate
each these
nine types of software Data Components assemblies separately. This means that
each type
of software Component assembly is separated from the other, has no fixed
relationship to any
other, and is stored separately. The result of doing this is that Any number
of Any one of Any
software Data Component assembly can be used with Any number of Any other of
software
Data Component assembly.
Hence, the method of the Any-to-Any machine is to separate each of these nine
types
of Software Data Component assemblies into assemblies of its own type, and
record each
one separately.
The Any-to-Any machine assembles Software Data Components as follows:
In the same manner that user data is assembled by consulting Data Relation
Table
records that state the reference numbers of the user Data Components and their
relationships
that are to be used in assembling a user data item, the identical method is
used by the Any-
to-Any machine to enable software to be assembled. Hence, the Specification of
which
226
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
software Data Components are to be assembled together and their relationships
within that
assembly is recorded by recording the reference number of the software Data
Component
concerned in a Data Relation Table record of a specific type for that type of
Component
assembly. The Software Data Component itself is stored in a Data Class Table
dedicated to
that type of Component.
Software usually requires a further level of assembly before use in the Data
Relation
Table and this is done in a miniaturized, separate version of the Data
Relation Table, called a
'Data Assembly Table'. A Data Assembly Table is usually given a working name
by adding
the name of the type of thing it assembles, and hence software Components -
Logics - are
often further assembled before use in the Data Relation Table by pre-
assembling them in the
Software Data Assembly Table. Such assemblies are termed Field Logics.
Each of the above nine types of Software Component Data groups is treated as
one
or more Data Relation Table Records of a different type. Each type of Data
Relation Table
records the software Data Components of one type and the relationships between
them.
Each different types of Data Relation Table records the reference numbers of
one type of
software Data Components and their relationships in exactly the same manner as
previously
described for user data. 1 ) Each different type of software Data Component is
stored in the
Data Class Table dedicated to that particular type of software Data Component.
2) A given
relationship of software Data Components is recorded in a Data Relation Table
record or data
Assembly Table record by placing the reference number of the software Data
Component in
its Data Class table in the Data Relation Table field or data Assembly Table
field concerned.
Each Data Class Table dedicated to a particular type of software Data
Component can
contain a 'content' field - and other fields if necessary - where a programmer
can describe
what the software Data Component does or how it does that or when it is
intended to be used.
(As will be covered in the Detailed Description, any Data Class Table can be
expanded and
made into a table that is an exact parallel of the Data Relation Table, and
there is more than
one way of doing this. Such expanded Data Class Table records parallel the
Data Relation
Table format and hence, their records can be kept in the Data Relation Table -
if Software
Modules are arranged to do this. In this manner, all Data Relation Table
fields can be made
available to record data concerning one individual software Data Component.
Such a Data Relation Table record is a Data Relation Table record, type
Module, Sub-
Type Execution, Sub-Sub-Type Data. Expanding a Data Class Table in this manner
allows
further data to be recorded concerning the software Data Component - such as
who wrote it,
where they wrote it, when they wrote it etc. This method for expanding any
Data Class Table
entry is a standard method of the Any-to-Any machine for expanding any Data
Class Table
and can be continued without limit. In the case of Data Class Tables that
contain software
227
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data Components, this method allows unlimited precision of control of even a
single software
Data Component. Any Data Component, not just software Data Components, can be
controlled with unlimited precision with this method. Extrapolated, this
method leads to the
ability to execute an order such as: 'If (unlimited number of Conditions) call
him Joe,
otherwise call him Joseph.'
This method produces numerous advantages, and some of these are:
1. The number of software assemblies that can be created is unlimited,
since any missing Component can be added, and assigned a reference number, and
its reference number used immediately
2. Creating a missing function of feature is a matter of creating a new
assembly of missing Components, and only writing those software Data
Components
that have not been written before.
3. Oniy one actual example of one software Data Component exists. If an
error exists in it, a) it affects all operations in which it participates
similarly and equally
and therefore, can give rise to only two errors:
a. It does not perform correctly when operating on the correct data
type.
b. It does not perform correctly when operating on the wrong data
type.
4. Whichever of these types of error it produces, it either never produces
that error, or always produces that error, but can not produce an error at
some times
and not at other times.
5. There is a strict parallelism between user Data Components and the
software Data Components that act on them. This makes it simpler for the
programmer to keep order and avoid errors in assembling software. While the
user
Data Components in a given Data Relation Table field may be of a number of
several
different sub-types, each sub-type can have a strict correspondence with a sub-
type of
software Data Component that acts on only on that Data Component sub-type.
Due to this parallelism, Any software Data Component can be targeted to
manipulate
Any user Data Component or to manipulate Any output of Any other Software Data
Component. (Whether it makes sense to manipulate a specific Data Component
with a
specific software Data Component in a specific instance is up to the
programmer to decide. A
Boss could order a factory to grind up a mountain and sell it as ice cream in
cold ice cream
cartons. The fact that he could do this does not mean that he should do so or
that is sensible
to do so. The point of the Any-to-Any machine is that it gives the programmer
the freedom to
228
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
manipulate any data in any manner, and does not unnecessarily restrict what a
programmer
or a user can do.
2. Method for Constructing An Execution Record to Perform a Single
Manipulation
A Software Module is an assembly of potentially nine different types of group
of
software Data Components potentially necessary to perform a single
manipulation. Any one
Software Module may or may not be used by a normal user, or by a programmer.
Broadly
speaking, some Software Modules deal with administrative tasks such as
creating new
record, and such administrative tasks are of little interest to the general
user, but are
employed frequently by a programmer. All Software Modules are named and can be
called
by name, and strung together by stringing together their names. Hence, some
applications
can be created simply by stringing existing Software Modules together in a
useful sequence,
and then tailoring or adapting an existing output (controlled by a View
Module) so that it
allows for the required user inputs and shows the output resulting from the
data manipulation
process. Hence, the process of creating a new application involves:
1. New Field Logics can often be created by assembling existing Logics in
a different combination
2. If a particular Logic is required but does not exist, then it is written
and
can then be used in combination with existing Logics
3, New Software Logics can often be created by assembling existing Field
Logics in a different combination
4. If a particular Field Logic is required but does not exist, then it can be
created be assembling existing Logics, and if necessary, the missing Logics
5. New Applications can often be created by assembling existing Software
Modules in a different combination
6. If a particular Software Module is required but does not exist, then it is
assembled from existing Field Logics and if necessary supplemented by writing
additional Logics.
7. New screens, suitable for the new application, are easily created within
days, simply by adapting an existing screen, which is easy to do, as all
screens are
easily 100% controlled by the user, and hence, revising them is even easier
for a
programmer.
The major and novel difference with existing software construction methods, is
that
with existing methods, when a new application is required, it should be
written from scratch
taking months or years. However, if the methods of the Any-to-Any machine is
used, then
creating a new application is mostly the question of re-using existing
Software Modules, Field
229
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Logics and Logics in new combinations, and the amount of code that is actually
missing is
likely to be relatively small - the average Field Logic is about 200 lines of
code and the
average Software Module is about 50K - and writing a few hundred lines of code
takes very
little time. Hence, the Any-to-Any machine methods for creating software
enable a novel
improvement in speed of software creation.
The Component assembly of a Software Module that specifies the references of
the
individual Field Logics Data Component assemblies to be used, and their
relationship is
termed an 'Execution Record'. When a Specific Software Module is called, and
the Run-Time
Assembly method is in use, the Execution Record is translated from Data
Relation Table
references into an actual assembly of Field Logics that are read into memory;
where they
execute per their code. It is in this respect that it useful to extend the
parallelism evident in
the Any-to-Any machine by providing memory chips laid out in the pattern of
the Data
Relation Table, CPU registers that match the Data Relation Table, code
interpreters set up to
translate each field into micro code, and then Execution pipelines for each
Data Relation
Table field. Obviously, a group of Software Modules can be written with the
methods of the
Any-to-Any machine, such that they act on one Data Relation Table record
containing logics
written in a high level language and output another Data Relation Table record
in assembly
language. Another Software Moduie can use the resulting Data Relation Table
record and
write its fields to an appropriate Data Class Table. In this general manner,
the Any-to-Any
machine can be used to increase the Execution speed of software applications
that are built
with the method of the Any-to-Any machine.
An 'Execution Record' is the term used for the Data Relation Table record type
that
contains the reference numbers of Field Logics. An Execution Record contains
up to one
Field Logic per Data Relation Table record field on which it wilt be required
to perform a single
manipulation, andlor need to use in the course of performing a single
manipulation - i.e. there
is a one-to-one correspondence between a single data type and single
manipulation
performed on that one data type. (Data Relation Table records are of many
different types,
each containing a different type of data assembly in their fields.
A 'Field Logic' is a block of code that performs a single manipulation,
normally on one
type of user Data Component whose reference number is recorded in one Data
Relation
Table record field. It may use more than one Data Relation Table record in
order to do this,
but if so, uses the data only in its own field number. Field Logics do not
perform
manipulations on one another's input fields as to do so causes confusion. If a
problem
occurs, rather than the problem arising from something in one particular field
of the Data
Relation Table, the problem can be coming from anywhere. Therefore, the
standard method
of the Any-to-Any machine is that if one Field Logic requires something done
on another field,
230
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
it uses an internal Token to get a Field Logic in the field concerned to do
it. A Token is a
communication from one type of Software Unit to another Software Unit of the
same type.
Preserving the Integrity Principle of Data Classes within the Software Units
is an desirable
method of the Any-to-Any machine for software construction.
It is highly desirable that a Field Logic itself consists internally of only
one operation,
but this is often not possible. When it is not possible, the Any-to-Any
machine has two
methods for maintaining the Any-to-Any machine as an Any-to-Any machine:
Two or more Execution Records are used for the single operation, the
Field Logic in each record performing one part of the manipulation.
2. A type of miniaturized Data Relation Table exists termed a 'Data
Assembly Table'. Just like a full size Data Relation Table, a Data Assembly
Table for
Field Logics contains in the fields of a given record, the reference numbers
for the
Logics - stored in the Logic Data Class table - that make up a Field Logic.
Every Record contains - in an administrative field - a field called the
Controller field
and in an Execution Record, this contains the Controller Field Logic.
Controller field Logics
control the activity of all the Field Logics in a record, and perform all the
communication with
other Execution record using Token that are themselves Data Relation Table
records. Each
record in the Data Relation Table also has a Token In and Token Out field that
is used by
Controller field Logics to communicate between Execution Records - i.e.
between Software
Modules
A Controller Logic coordinates the Execution of the Field Logics referenced in
each of
the fields in the Execution Record and handles communication with other
Controller Logics.
An Execution Record's Controller logic is the boss of the Execution record
'team' of Field
Logics, just as a group of soldiers have a leader.
3. Method of Communication between Execution Records & Software Modules
Controller Logics communicate between one another using a type of Data
Relation
Table record called a 'Token' record. A 'Token record' is defined as:
'A Data Relation Table record containing information and instructions provided
by one Execution Record, for use by another or other Execution records.'
An 'internal Token' is defined as:
A standard, in-memory communication system within a Fieid Logic that
enables it to send and receive information. Every Field Logic is supplied with
code to
enable it to send and receive Internal Tokens, just as every Controller Logic
has code
to enable it to send and receive Token records.
Token records can contain either actual Data Components or references to Data
Components in the standard manner. If they contain actual data, they may have
to be
231
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
constructed in a separate but parallel Data Relation Table of their own, if
the database being
used is not capable of accepting different data types in a single field,
thereby preventing the
Tokens from using the main Data Relation Table..
Typically, at least one field of a Token Records contains the record number of
the first
of the Data Relation Table records containing the data references on which the
next
Execution Record is to act, and may also contain the record number of the
Execution Record
or Software Module that is to act on it. A Token record can also contain the
reference
number of the Execution record or Software Module to which the results of the
manipulation
are to be sent, as well as instructions whether to switch on its display or
not. When using
Tokens the programmer pays attention to preserving the chain of Command so
that when a
Token is received, and later sent on, it is either sent onto another Module
that will return it, or
sent back to the Module it came from. In this manner, the number of Modules
that can call
one another is not limited; further, each Module that calls another to do
something that it
needs, simply waits until it gets the Token back, and then proceeds. This
general procedure
solves the problem described in the background, where Execution either
succeeds or aborts,
because with these methods, if an Execution cannot complete, there is a reason
it cannot
complete and this reason is handled by another Software Module that corrects -
often with
the user - the reason it could not complete. When the original Software Module
receives its
Token back and it can now complete - the~originaf Execution was not aborted.
Similarly,
detection of post-Execution Conditions using Condition records, allows
suitable Software
Modules to re-attempt the Execution in an Alternative fashion, if the first
Execution attempt
failed. In this manner, the ease of use problems caused to the user by the
many error
messages that are needed in the state of the art will be greatly reduced.
Any field in any table can be expanded to be a complete Data Relation Table
record.
Any field of any Data Relation Table record can equally be expanded into a
Data Relation
Table record of its own sub-type. Any field of a Data Relation table record
Sub-Type can
equally be expanded to into a Data Relation Table Sub-Sub-Type record and the
process can
continue indefinitely. Equally, any Data Relation Table field - such as a
field containing a
Token - can point either to an individual Data Relation Table Token record, or
- for example -
to a Data Relation Table record that is a list of Token records, complete with
associated
Execution Records and any other needed Data Relation Table records to decide
which
Token Record or records are to be used. For example, one type of Token Record
could be a
complete statement of the Data Relation Table records on which to act, while
another type of
Token Record could used to specify times at which particular Tokens are valid
etc. The
general principle is that a record - such as a Token record - can be expanded
into an infinite
232
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
number of types that, at the first level of expansion, can state in detail the
entirety of relevant
data concerning a single Data Relation Table field - for example, the Start
Time field.
This generally describes a novel, unique and useful feature that is visible
throughout
the Any-to-Any machine - any data can be infinitely expanded, or, by grouping
it together,
contracted to the point of a single reference number, character, or digit.
Hence, any amount
of data can equally be manipulated by manipulating a single word, character,
or digit_
Because of these features of the Any-to-Any machine, the programmer can create
any
number of different types of Token Records that suit his purpose and thereby
control the
subsequent course of any given Execution as finely as he desires.
- Method for Eliminating Unnecessary User Intervention to handle 'Errors'
In the state of the art, the term 'Error' carries with it the connotation that
a set of
Conditions has occurred that prevents Execution continuing, and therefore,
Execution is
about to abort or has already aborted. This type of situation, commonly termed
an 'error' n
the state of the art, is treated by the method of the Any-to-Any machine as
simply one of
several Conditions that can exist when an Execution is ordered. An 'error' is
simply a type of
Condition that requires further action before the ordered Execution can be
completed
successfully.
For example, typically in the state of the art, software that is ordered to
copy a file X to
a destination Y where it cannot be copied for some reason, will announce an
error message
such as 'File X can not be copied to destination Y'. The software will then
often display a
button such as 'OK' that can be clicked to tell the software that the user has
seen the
message. Frequently, the user is unable to proceed with any other action until
he has clicked
such an 'OK' button. Additionally, when he does click that button lie should
begin the
operation again from the beginning. This common procedure in the state of the
art requires
user intervention that is not really required, and equally does not require
user intervention that
really is required. In doing so, it departs from the normal human manner of
processing such
an error. The human manner of processing a situation such as the above is that
the
secretary, given such an order by her boss will reply 'I can't put file X in
file cabinet Y,
because cabinet Y is locked and Joe has the key. Shall I put it in file
cabinet Z?' The
secretary does not just put the file back on the boss' desk and say 'Can't put
this file in file
cabinet Y. OK?'
However, with the method of the Any-to-Any machine, the situation in this
example -
attempting to copy something to a place where it cannot be copied - is treated
simply as only
one of a number of possible Conditions that can exist prior to Execution. The
general
principle and method of the Any-to-Any machine is that all Executions are
tested for feasibility
before the Execution is attempted, and one of the mechanisms for doing so
(there are others)
233
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
is to compare the Conditions that exist with Conditions stated in Condition
Records. One
outcome of such comparison is that it is now possible to detect - before
Execution occurs - if
the Conditions needed for a potentially successful Execution exist or not. If
the requisite
Conditions do not exist, then various mechanisms - of which Director records
are one - can
launch Software Modules that have the capacity to bring about a correction of
the missing or
Vvrong Condition.
Continuing with this example, when an item ordered to be moved somewhere, two
of
the Conditions that can exist are: 1 ) The item can be moved 2) The item
cannot be moved.
Which of these Conditions exists is checked before Execution. If Condition (1)
exists, then of
course, the Condition Record concerned tests as being matched - and therefore
met - and
the fact of the match states that Execution can complete successfully.
Therefore, the fact of
the match results in the Execution beings launched and the item is moved. If
Condition (2)
exists then a further step is required before Execution:
1. To inform the user that this item cannot be moved to this destination,
2. To inform the user WHY this item cannot be moved to this destination
3. To give user the opportunity to change whatever parameters exist that
prevent the user copying this item to this destination. Amongst these
alternatives is
a. To ask the user for an alternate destination, since it can be
assumed that, if the user gave the order to move the item, he does in fact
want
to move it and therefore, an alternate destination may suit the unknown
purpose that he has in his head when he gave the order to move the item.
b. To ask the user if he wishes to cancel the action. (This
alternative needs to be presented in case the other alternatives do not suit
him).
Supposing that the user changes the parameters preventing the action, or
chooses
an alternate destination, then the actual Execution Logic - which has been
waiting to act on
the data until told to go ahead - receives the data it needs, and therefore
can and does now
execute successfully.
Some of the Conditions that can prevent Execution completing successfully
exist
within the computer and therefore can be handled by a programmer using the
mechanisms
outlined above. Other Conditions that. can also prevent successful Execution
can be
unknown at the time of Execution - for example a fax can be sent to a number
that is
disconnected.
Each Condition that can occur after Execution has been attempted is treated as
a
particular type of Execution Condition that can exist - and such Condition
Records are termed
post-Execution Conditions. A human who is executing an order instinctively
checks to test
234
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
post-Execution Conditions. For example, a secretary wilt glance at the fax
machine from time
to time to see if a fax went through. A secretary using her hand to put a file
into a file drawer
is continually observing post-Execution Conditions. She pushes her hand
containing the file,
and observes, both through feedback from her hand, and by watching the file
with her eyes, if
it slides in between the two other files where she wants to put it. If the
file does not slide in as
expected, she will look, determine the Condition that exists - such as for
example that she is
trying to push it into the middle of another file instead of between two files
- and take
corrective action - which is often in the form of a slightly different, or
another Execution.
Observation of human behavior shows that post-Execution Condition detection
and also post-
Execution correction - i.e. re-Execution with changed parameters - is a close-
knit and
intrinsic, automatic part of all human Execution procedures.
The detection of post-Execution Conditions is a prerequisite to being able to
take
corrective action - if the post Execution Condition is not determined,
corrective action can not
be taken.
fn the state of the art, post-Execution Condition detection is largely
missing. State of
the art software will frequently inform the user whether Execution was
successful or not. In
the(terms of the Any-to-Any machine, it will inform the user of the post-
Execution Status -
Failed, or Succeeded. However, state of the art software seldom detects the
post-Execution
Condition - i.e. it seldom tells the user why the Execution failed, and even
if it does so, this
information is not usually recorded and usually, there is nowhere in the
software where it can
be recorded. Since it is not recorded, it becomes difficult for the builder of
a One-to-Many
software machine to provide mechanisms to handle the various post-Execution
Conditions
that can exist, and hence, in practice, these do not exist in state of the art
software.
In order to operate in a human-like manner, every Execution is tested after
completion
to determine not only the Status - the outcome - but also the Conditions of
each failed
Execution - i.e. why the Execution failed. The mechanisms for doing this are
similar and
parallel to those used to determine the Conditions that exist before Execution
is attempted.
Firstly, every Data Relation Table record contains a field named 'Status'. The
Controller Logic of every Execution Record continually updates this field in
the Data Relation
3p Table data records that contain the order that it is Executing. Typical
examples of entries in
the 'Status' field could be 'Scheduled', 'ln Progress', 'Completed',
'Canceled', 'Failed'.
Every Execution Record, just before it attempts the Execution, launches a
Software
Module termed Failure Detector, which is constructed to determine, and make a
Data
Relation Table Failure Record that determines the Conditions of the failure.
For example, a
Software Module that is responsible for Faxing fax-able items has an
associated Fax Failure
Detector Module. The Failure Detector Module contains an Execution record
containing Field
235
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
l_ogics and also has Condition and Director Records that between them, can
detect all
possible errors - i.e. number rings disconnected, a person answers the phone,
the other fax
does not complete the hand-share protocol ete. Obviously, if these Conditions
are to be
detected and suitable action taken to correct the Failure Condition, the
application
programmer should write one or more suitable Software Modules to detect them
but if he
does so, the handling of failure can be transparent for the user.
Secondly, Condition Records are used to test the Conditions that exist after
Execution.
If 'Failed' is placed in the Status field - a value that is placed there by
the Failure Detector
Module - then the Failure Detector Module calls the associated Failure
Corrector Module.
This Module tests which failure Condition exists using its associated
Condition records,
'Failure Reason' Sub-Type. Each of the Failure Reason Condition Records
contains a pointer
to a Data Relation Table Execution record of a Software Module capable of
correcting the
reason for the failure - for example, by re-launching the original Module so
that it tries again,
or by launching another Module that tries another way of achieving the
objective.
These mechanisms between them create the mechanisms needed to enable a
computer to check and correct Execution in a human-like manner. The mechanisms
now
exist for a computer that sends an e-mail and gets it returned marked 'address-
unknown' to
issue a message to the user such as 'Your e-mail to Mr. X about Y has been
returned as
address unknown. I have searched Internet directories and found these e-mail
addresses
that could perhaps be the e-mail address for Mr. X. Shall I attempt to 1) send
it to one or 2)
to all of them, or 3) would you prefer if I telephoned him on his mobile and
read him the
message? Or 4) Do you want to cancel this communication completely? Just say
'1', '2', '3' or
'4' and I'll do that.'
If an application is correctly built using these methods of the Any-to-Any
machine to
the full, there are only two possible outcomes to every Execution:
1. Either the Execution is successful, or
2. The user decides to cancel the action.
For the user, an 'error' does not exist in the classical, sense. The
difference
compared to state of the art Execution procedures - assuming that the
programmer
concerned creates a handling for each Condition that can exist using the
methods provided
by the Any-to-Any machine - is that a decision to cancel or abort an action is
not made by the
software only by the user. Onfy the user can cancel an action and this places
the power and
control in the user hands, rather than taking it away from him against his
will. Because of this
method created by the Any-to-Any machine for handling Conditions that can
exist, the
problem of 'Errors' as the term is used, and as the term is presented to users
by state the art
236
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
software no longer exists. Such user 'Errors' frequently are simply a
manifestation of
unnecessary limits that are inevitable in.One-to-Many software construction.
Hence, the term 'Error' in software properly written using the methods of the
Any-to-
Any machine is confined to the programmer level, where a programmer can put
Software
Data Components together in an unworkable manner. A programmer could - for
example -
place a Field Logic written to handle text and in such a position that it is
targeted to act on
part of an image. When such an error occurs however, there are relatively few
reasons why
an error can occur, and therefore, such errors are easily found and corrected.
Effectively, these mechanisms enable software to be written that is error-
free, and to
perform in a manner that is human-like and that a human will consider to be
error free, since
the only problems that can occur are those that are outside the control of the
software, and
even these can be handled in a sensible, human-like manner.
The general principle of construction of the code comprising each logic for
each
individual field in an Execution Record, is that Execution proceeds in the
presence of data
meeting the requirements of the Condition Records for that field, and does not
proceed in its
absence or in the presence of incorrect data. Similarly, Conditions are
checked after
Execution as well as before Execution.
The general method of Execution, and hence the general method for removing
those
Conditions that in the state of the art software are described as 'errors' is
summarized as
follows:
One or more Condition Records exist for each Software Module.
2. Each Condition Record states one Condition per field. The Conditions
so stated are the Conditions that a Software Module could encounter in each
field of
the data records it will process. These are stated with no regard as to
whether they
constitute what would be defined as an 'error' in the state of the art.
3. As many Condition Records as needed are used so that all possible
Conditions in each field can be detected and one Condition Record exists for
each
combination of Conditions that can exist.
4. Software Module Field Logics query their field in the Data Relation
Table New Record that is being constructed by the Software Module - all
software
Modules use a New Record created by the New Record Module and then add their
own data to it. Field Logics do this using the entries in individual fields of
Condition
records associated with that Software Module. They do this to determine if the
required Conditions are already met, and if so in which fields. If a Field
Logic finds a
Condition is satisfied, it performs the action it is supposed to do and
reports 'complete'
to its Controlling Logic in the Controlling Logic field together with the
number of the
237
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Condition Record that was found to be satisfied by the data. There can be more
than
one Field Logic per field in an Execution Record, and like all Field Logics,
they contain
code that enables them to talk to one another.
5. A Timing record can state, field, by field, the amount of time that is to
pass before the user intervention is requested or another Software Module is
activated
per the Specification in the Director Record that is associated with the
Condition
record, in the event that a given field, or all fields, fail to obtain any
match between
data in the new Record and the Specification in the Condition Records. A
Timing
Module can be used to handle timing manipulations if required.
6. Each Condition Record can have a Director record associated with it,
and this states in each field, which Software Module is to be called if the
Condition
stated in that field of the associated Condition Record is matched by the
data.
7. A Field Logic, finding a match between a data field and a Condition
Record field can look in the same field of the associated Director record for
the
number of the Software Module to be launched when a match occurs. It passes
this
to its Controlling Logic, which in turn activates the required Software
Module.
8. The Token passed by the Controlling Logic can contain instructions for
the activated Module to return the Token when complete. When the complete
token is
received, the Controlling Logic can initiate a recheck of the data and then
execute if
found to be executable (by comparison with Condition records that state
executable
Conditions). Alternatively, it can assume it now has the correct data and
execute its
function.
With this Standard Operating Procedure, it does not matter how many chains of
Conditions and their handlings occur, or how many times a given Condition
occurs, as
procedures - Software Modules are effectively chained as necessary. As each
Condition is
handled, the preceding Execution can occur, until, eventually, the Execution
that was
originally ordered either can be completed or is aborted by the user.
Because the Any-to-Any construction method of the Any-to-Any machine permits
the
original Execution only to be attempted when it is known that the outcome will
be successful,
and the original Execution remains 'In Progress' until either completed or
aborted, the
problem mentioned in the Background, of software attempting Executions and
aborting when
they fail, na longer exists. Because post Execution Conditions are tested, in
the event of
Execution failure Software Modules can be written to handle them in a
sensible, productive
and human-like manner.
238
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- Method for Discovering and Handling Difficult Orders - Can Do.
A user can give orders such as ordering an audio file to be faxed, or a modem
to be
printed. While a person may occasionally do this perhaps with the intention of
testing the
computer, the more practical concern is that humans do make errors and
accidentally order
6 difficult Executions. Referring to the boss l secretary model, a secretary
receiving an difficult
order will not attempt to execute it but will often suggest a helpful
alternative. In the first
example of ordering an audio file to be faxed she might reply 'Audio files
wont fax, but I can
FTP it if you want.' 'In the case of the second example, she might reply
'Modems can be
printed - I can print the Specification for the modem if you want.'
p The human may not actually remember the order he just gave. In the state of
the art,
software will usually reply something to the effect of 'Can't be done' and
leave it at that. This
leaves the human in a mystery as to why his reasonable order cannot be done,
or perhaps
even wondering what order of his it was that can't be done.
Every type of manipulation can only be performed on certain data types. An
audio file
15 cannot be faxed, a printer cannot print a sound - at least not directly,
and an icon can not be
played on the computer's speakers. This demonstrates that that there should be
a match
between the abilities of the Execution mechanism and the Specification upon
which the
manipulation is to be done. If this match does not exist, it adds complexity
and confusion to
attempt determine if the required Conditions for the order are satisfied or
not and can lead to
20 absurd queries such as 'What is the fax number for the printer?' In other
words, the ability of
a manipulation to act on a Specification is of a higher order of importance
than ensuring that
the remaining Conditions for the Execution are met, and especially so since
the greatest
likelihood is that order contains a major mistake and this should be corrected
before
attempting to execute it.
25 The following Any-to-Any machine methods enable a computer to check for
difficult
orders, and thereby, not attempt to execute them, but rather, to produce the
appropriate
Prompt and/or Help, or to use a Condition/Director record pair that call an
appropriate Module
to handle the problem.
Every Data Relation Table record contains an 'Abilities' field in the Action
Data
30 Category and another in the Matter Data Category. Each one is a pointer to
its own Abilities
Record that is a Sequence type record that lists abilities.
A software Module called 'Can Do' looks up the Abilities List for the type of
Data Item
to be manipulated and the Abilities List for the manipulation - Action -
concerned. If it finds
any match, it simply passes on the Token and terminates. If it finds no match
at all, then it
35 calls a Can't Do Software Module that uses a Help Record to construct a
polite user message
along the Lines of 'item X will not accept by trying to Y- it', would you like
to revise you
239
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
order?'. Alternatively, each Can't Do Module can have a number of associated
Prompt
records, each of which is associated with a Director Record, and depending on
what the user
chooses to do, the appropriate Software Module is launched.
- Method for Constructing Software Modules
The term 'Software Module' is the name for the collection of Component parts
that
together constitute all the Component parts that are needed to perform ONE
distinct
Execution. Each Software Module can be conceived as having one specific
product, not two,
and one specific responsibility not two. Each Software Module does only one
complete action
and not two or more complete actions that can be made independent.
The instant one Software Module does two or more actions - for example, opens
a
new record and dials a number - the machine ceases to be an Any-to-Any machine
and
becomes a One-to-Many machine. If another Software Module now needs to open a
New
Record, there are only two choices. One choice is to attempt to use the Module
with the
'open new record' code in it, without activating its dialing function, and
that leads to potentially
deactivating the dialing function under some, perhaps rare circumstances or
combinations
when it is actually needed. Since such circumstances may exist, all possible
circumstances
have to be tested. The other choice is to re-write the code for opening a New
Record and
amend it to some degree to take account of the new circumstances under which
it is being
used, perhaps again in combination with another action. If many programmers do
the same
thing, this can result in a number of ways of doing a specific action, and
these different ways
are quite likely to impact one another. In case they do, extensive testing is
required, and if an
impact is found, sorting it out can become endlessly complex. The third
alternative is to copy
the previously written code, which is a common habit amongst programmers. If
the 'open
new record' code is later found to have an error, then there may now be 100
instances of the
wrong code, all in different places in the program, and no one person knows
where all the
instances are to be found in the program. Nevertheless, all 100 instances have
to be
corrected. Meanwhile, it is not unlikely that in programming another action,
another
programmer has found that the error - without necessarily being aware that it
was an error.
He simply noticed that the code did not quite do what he needed done and
therefore,
changed the code a little so that it worked for him. If the 100 instances are
now corrected,
most of the 100 instances may work correctly. However, it will not work
correctly in the
instance where the programmer wrote around the error. In order to check that,
all 100
instances have to be tested in every variation, to ensure no new errors have
been introduced
by the correction. Additionally, because any given code is being used to
create a One-to-
Many machine that can perform more than one action, the language in which it
is written
should itself become complex, difficult to learn, prone to error, and in any
cases imposes a
240
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
considerable learning and processing overhead. This gives some idea of the
kind and
magnitude of problems that can occur when a number of One-to-Many machines are
connected together - as is the practice in the state of the art software
construction. For this
reason it is not desirable to create a single Software Module to accomplish a
task that can be
split in to smaller tasks.
A User Software Module is therefore defined as 'A collection of Software
Modules that
perform one single task that is useful to the user."
A Programmer Software Module is therefore defined as 'A single Software Module
that
performs one task that is useful to the programmer.'
Hence the Execution Mechanisms constructed with the methods of the Any-to-Any
machine consist of independent, self-sufficient Software Modules that each
perform only one
function. As an example, separate Software Modules exist for the following
basic actions:
NEW RECORD Creates a new record. Any
Module that needs a new record created, calls this ONE Module
to create the new Record.
FIND Finds records that match Specifications. Any
Module that requires a Specification found, calls this ONE
Module to find the records that match the Specification.
Two alternative methods exist by which a value in a Data Class table can be
referenced:
1. The reference number for a value in a Data Relation Table field does
not contain the number of the Data Class table providing the value. In this
case, Field
Logics are written to'take account of the fact that - for example - reference
numbers
in field number 22 in a Data Relation Table record refer to actual values that
are held
in Data Class Table number 22. This method is used in most cases.
2. Occasionally, more than one Data Class can be referenced in a single
Data Relation Table field and in this case:
a. More than one Data Class Table may be required for that field.
b. The reference number referenced in that field is a Combined
Number in which one part of the number refers to values held in one Data
Class Table and other parts of the number refer to values held in another Data
class Table servicing the same field.
3. Many records are field parallel - i.e. the same field in that record type
refers to a particular Data Class Table. In addition, values in a particular
Data
Relation Table record field can be Aligned or Unaligned. If they are Aligned,
the
241
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
reference number for the field is provided by the Data Ciass table for that
field. If they
are Unaligned, the reference number is provided by a Data Class Table for that
record
type. Records belonging to the Life Data Category particularly are usually
Unaligned
records. Taking the example of a Quality record, any Data Relation Table
record
containing entries in the physical universe Date Categories - Time, Space,
Energy or
Matter - any Data Class in those Data Categories can have an associated
Quality
record that contains a value modifying the value in the data record. Time -
for
example. - can be good or bad - 'a good Wednesday' 'a bad Wednesday' - a
Location
can be good or bad, an action can be good or bad and a thing can be good or
bad.
Consequently, while every value in a Quality record is a Quality and therefore
derives
its value and reference number from the Quality Data Class, it is an Unaligned
record
type. Every field in the Quality record refers to the Quality Data Class
Table, whereas
in an Aligned record, every field refers to the Data Class Table for that
field. However,
a Quality record is field parallel in that the value in a given field, applies
to the value in
the same field of another record
4. When a Data Relation Table record type is Unaligned, it is desirable,
but not essential, that each reference in such a record consists of a Combined
Number, in which the first part of the number states the Data Class Table
Number and
the second part states the record number - and hence the reference to the
value - in
that Data Class Table. It is not essential to do this, because in any case, a
Quality
record will have the number for the Quality record type recorded in the Record
Type
Administration field. However, it can make it easier to search if the Data
Class Table
number in an Unaligned record type, does include the Data Class Table number.
If
that is so, then a search on only one field can find the required value. For
example, if
the number for the Quality Data Class table is 22, and the user wants to know
'have
we ever had a bad Wednesday?' the search can be conducted on the Data Relation
Table field containing values such as Wednesday, to find a Data Relation Table
record that contains the reference number for Wednesday, that has, in the same
field
number of an associated record, a value that begins with the number 22. This
enables a Software Module to answer, colloquially speaking: 'Yes, you said the
12t" of
November 1966 was a bad Wednesday', or 'No we've only had good Wednesdays.'
This method is another of the methods enabling the Any-to-Any machine to
Return
Nearest Truth.
A Condition Record is an Unaligned record type, in that all the values in it
normally
refer to a value in the Condition Data Class Table. A Condition record may be
Field Parallel,
in which case, the Condition stated in a single field is used independently of
any Conditions
242
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
stated in other fields of the Condition Record. In this case, the Condition
record is
accompanied by a Field Parallel Director record, that states in each field,
the number of the
Execution Record of a Software Module that is to be called if the Condition in
that field is
satisfied. Alternatively, a Condition Record may be Table Parallel, in which
case all the
Conditions stated in its fields should be satisfied before the Condition
Record as a whole is
satisfied. A Table Parallel Condition Record contains the Execution record
number of the
Software module to be called if the entire Condition record is satisfied, in
its Director
Administration field.
Taking a Software Module Condition Record as an example of the method used to
construct one of the Software Module record types, and supposing that the
record type
number for a Condition record is 44, the number 'name' of the Data Class Table
will also be
named '44'. Each field in the '44' Data Class Table will contain a single
different Condition
applicable to a single individual Data Relation Table record field. Suppose
now that a
particular Condition in one of the 44 (Condition) Data Class Table records is
number 143.
The complete reference to that Condition for a single field will be 44143.
A 'Condition Record' is then assembled by the application programmer by
selecting
field Conditions, one at a time from the Condition (44) Data Class Table and
entering them
into a New Record to which he gives the record type name 'Module', the Sub-
Type name
'Condition' and the Software Module Name of the name of the Module he is
creating. If he
does not find a suitable Condition, he creates a new entry in the Condition
Data Class Table
(or uses a Module to do so) and then uses it. Thus, a Condition Record may
have in one of
its field - field number 33 - a Condition number 44143. The next field, number
34, may use
the same Condition, number 44143. Field 35 may require no Condition at all, as
it is not used
in the particular Module he is creating and will therefore be blank, and Field
36 may use
Condition number 44199.
In this way, Any Condition Record can be assembled from Any combination of Any
field Conditions, and the smallest Any-to-Any building block for a Condition
record, is a single
Condition for a single field. Hence, the first digits of the reference to an
individual field
Condition in a field of the Condition Record may be begun with the number of
the Data Class
Table that contains its value. Hence, searches on the field concerned can be
done on the
basis of the record type record required - 44 in the case of a Condition
record - thereby
excluding all other, non - 44 records from the search. This eliminates the
necessity to search
once for a record type and then again for the particular value required,
because each field of
each Type of Data Relation Table record states its type number. (This method
can be used if
the database limits on the number of digits a fiield can contain are
sufficient to allowed to
243
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
allow digits to specify record type. If this is not the case, the record type
is in any case
specified in the Record Type and Record Sub-type fields, and so can still be
identified.
All other Software Module Records are assembled in a similar fashion to that
described above. The smallest, and re-usable software building Component being
a single
Logic held in the Logic Data Class Table.
A Data Class Table often contains only two fields, one field - which is also
the record
number - serves as the number reference for the actual value, held in the
second field of the
same record. However, a Data Class Table is actually a full - but junior -
Data Relation -
Table, containing two record types that are used in matched pairs, and is a
Data Relation
Table that has been miniaturized to only one field, and then, instead of say
that each of the
one field records work in pairs, with one of the pair being the translation
for the other of the
pair, the records are placed side by side. Consequently, a Data Class Table
can be
expanded if necessary, up to full Data Relation Table size, where one of the
fields now
becomes one of the record types, and the other field becomes the other record
type in the
junior Data Relation Table. If a Data Class table is expanded in this manner,
then all Data
Relation Table fields become available to state something, or control the
operation of the
Data Component that is held in just ONE of the fields of each record. Because
a Data Class
Table is only a miniaturized Data Relation Table, all Data Relation Table
record types and
mechanisms can be fully available to state things about or control the
operation and use of
just a single Data Component.
This method can be useful, especially in extremely fine control of the
operation and
use of individual Logics, and leads to constructions such as the following
(colloquially stated):
'lf passwords 1,2,3,9 have signed on, and if it is between 9.36 am and 15.00
and if Joe's wife
has sent an e-mail saying 'Yes' then make Field Logic 11917 in active, and
make Field Logic
22131 Active.'
- Method for Operating Software Modules
Software Modules are of different types. One type of Software Module controls
output
- for example, what is seen on the screen - and Software Modules of this type
are termed
'View Software Modules or 'View Modules'. A View Module is a Software Module
that
manipulates spatial relationships an output - such as a screen or projection
display, or e-mail,
FTP, printer or fax output spatial relationships of transmitted material.
Additionally, View
Modules also provide mechanisms for the user (or Software Modules, or the data
itself) to
control any and every aspect of data input and output.
A Software Module that manipulates data is termed an 'Execution Software
Module' or
'Execution Module'. Both View Modules and Execution Modules are types of
Software
Module.
244
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Because Execution Modules and View Modules are independent of one another, Any
View Module (or none) can be used with Any Execution Module. However, at least
one
Execution Module is required for anything to happen at all.
Any View Module can service Any number of Execution Modules. Any Execution
Module can use Any number of Any View Modules, and it may be advantageous to
do so
under certain circumstances. The ability of an Execution Module to use Any
number of View
Modules implies that the number used can be zero, and hence, an Execution
Module can
operate without any View Module at aN, or with the View Module turned off.
This is
advantageous when intermediate steps - that can be lengthy if the application
constructed
with the Any-to-Any machine's methods is given a complex, data-gathering order
- are being
performed, and when the intermediate steps are of no interest to the user.
Because View Modules are assemblies of Software Data Components, each
Component - such as the color of a word - can be controlled separately also
and in a non-
hierarchical manner. Hence, the input and / or output data for a given
Execution can appear
on the screen, or not, in no ways, in two ways, or in a hundred different
ways, depending on
what is required. Hence, Any given data can be viewed in Any way. Because an
Administration field is provided in all Data Relation Table named 'User
Number' Any way of
viewing Anything can be related, using the Data Relation Table to Any user.
Hence, Any
given data may be shown on the screen and looked at or output in a almost
infinite number of
ways by one person and in other, completely different and almost infinite ways
by another
user with different preferences. Because the View and Execution Modules are
separate
entities, changing the view of the data does not either change data, or
require that the data
be changed, nor does it change in any way the manipulation of the data. Hence,
the
Execution Module that manipulates data does also does not require to be
changed if the View
of the data changes, and is completely unaffected by the way the data is
viewed or output.
Consequently, any given manipulation can be input and can also be output in
any
manner that exists to input or output anything. For example, a user can give
an order over
the phone to a set of Voice Input Software Modules that also control Voice
Recognition
software, and thereby create a Data Relation Table record that is an order.
The normal order
Execution mechanisms of the Any-to-Any machine can then (based on the order)
activate a
set of Software Modules that are today labeled as 'spreadsheet actions'. These
'spreadsheet
actions' Software Modules can perform the requisite calculation and create
Output records in
their normal manner. The 'spreadsheet actions' report the completion of the
manipulation to
the Voice Input Software Modules by returning the Token it received from the
Voice Input
Software Modules it received in the first place. Part of the user's order will
contain the
manner in which he wishes to receive the result - or this will be assumed to
be by Voice
245
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Output in the absence of an order to the contrary. Hence, the Voice Input
Software Module
will pass the token to the Voice Output Software Module set. The Voice Output
Software
Module set, that incorporates and controls Text-to-Speech software can then
read back the
result to the user over the phone. Alternatively, any other output can be used
with the given
manipulation, such as outputting the result by e-mail, fax, projector, network
or Internet
connection to the web.
Additionally, the separation of display and output of the data from the
manipulation of
the data, allows the nature of data itself to be used to control the view of
it that is output. For
example, if the content of a letter is small, the output area, parts of the
View Module, can use
Condition records to detect the size of output required in a given field.
Based on the
Condition Record that is matched, the field can be set up to suitably small
visual size and
area, without the user having to order it. For example, if a town name turns
out to have a
large number of characters, as in the case of Welsh villages, the View Module,
detecting this,
can size the display area for the town name accordingly. The ability for a
computer to do this,
solves problems that are evident in the state of the art, where unusually long
data entries
either result in some of the characters not being displayed, or in a refusal
to accept the data
entry at all.
This Any-to-Any construction of Software Modules results in numerous further
advantages, such as enabling the nature of the data to control other aspects
of functioning,
such as the overall display. In real life, a secretary will interrupt her boss
for desirable
matters, but not for less urgent ones and the method of the Any-to-Any machine
- Any-to-Any
construction allowing separation of manipulation from output - enables a
computer to act in a
human-like manner in that respect. For example, an e-mail from the Chairman
marked
'Urgent' can arrive accompanied by a View Module - or call a View Module -
that takes
priority over all other View Modules. Such a View Module could push aside all
other View
Module displays by issuing an order that reduces them to 10% of normal size.
It can then
display its data - the Chairman's e-mail - in large, flashing red letters,
while an identical e-mail
from someone else - perhaps with the identical text - behaves in a normal
manner. In either
case, the Execution Modules that were used to prepare and receive the two e-
mails remain
totally unchanged and act identically despite the different end result.
As described, separating the logic required to perform a data manipulation and
storing
it separately, and separating the manipulation operation from the view of the
manipulation,
allows Any Execution Module to be used with Any View Module or with no View
Module at all.
Thus, the NEW RECORD Module would not normally show on the screen. A FIND
Module would show if the user was trying to find something, and would not show
if another
246
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Module had asked it to find something. However, if FIND was trying to find a
Specification
and failed, that failure can be used to switch on its screen presence and to
display suitable
prompts for the user to handle the problem in the Specification. The Any-to-
Any machine
methods allows user intervention to be obtained when it necessary, and not
requested or
demanded when user intervention is not necessary. In this manner, Software
Execution
Modules can perform similarly to a secretary, who gets on with her work and
only bothers the
boss when she has a problem - for example, he should her to send the file on
bananas to
someone and there is no file on bananas. Thus a FIND Module, when working for
another
Module, completes its work and returns the results to the Module that ordered
it to act, but, if
it has a problem, sorts this out with the user, and then returns its results
to the Module that
ordered it to act. Just like a secretary, the Module that ordered the FIND
Module to find
something, waits until it receives back the Specification of the item found,
before attempting
to act. However, when it does receive back the Specification it needs, the
fact of the
Specification being received back, launches the next stage in its operation
and then it does
act.
Hence, this general procedure emulates the procedure a human uses, and
produces a
computer that, in this respect, manipulates data in a human-like manner.
Because of this One Module, One Manipulation, Any-to-Any machine construction
of
the Any-to-Any machine, Modules do not necessarily act singly, but often actin
groups.
Software Modules called by the user are automatically acting as Senior
Modules. The
method used by the Any-to-Any machine is that any Software Module called by
the user has
the authority to calf other Software Modules, and does so using Tokens. Which
Software
Modules are called to perform the background administrative activities
required, is something
that the programmer decides and arranges. For example, the Module called "FAX"
uses the
following Modules:
FAX
FIND RECORD Checks to see if the exact fax has already been sent
FIND ACTION If a fax has been sent, finds the record to do with that
sending
ACTION STATUS If the fax has been sent, reports to the user what
happened.
CAN DO If not sent, checks that the item ordered to be faxed can
be faxed - that it is not a sound recording for instance.
NEW RECORD Opens a new record to record the action to be done
247
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
FIND If the user has ordered a previously used content to be
faxed to someone now, finds the record with that
content.
FIND NUMBER Finds the (fax) number to be used for that addressee if
this is not included in the order. If it is included in the
order, then instead, another Module is called, named
'ADD NUMBER', that records the new number.
FAX PARAMETER Only if the user wants to change fax parameters, this
Module is called to take care of it - with the user if it is a
Visual Interface, and as instructed by the Language
Processor if a Language processor is in use.
FAX SENDER The Module 'FAX' passes the complete and ready to
send Fax to the Fax sender, together with the number to
send it to.
DIALER FAX SENDER uses the Module called "DIALER" to dial
the number it gives the Module.
FAILURE DETECTOR Acts as previously described to detect failure of the fax
to go through when it is sent..
Note that Software Modules are called if they are needed, and not called if
they are
not needed. This solves one of the problems in the state of art - one of the
symptoms of the
One-to-Many problem - where it is the practice to present the user either with
no Execution
options, or otherwise to present the user with every possible Execution
options every time.
When the latter is the case, the user is presented with a confusion as he
should apparently
accept options that either do not apply at all or options that do not require
change. This non-
human procedure is a problem for uneducated users, who do not understand why
the
machine is asking him if it is OK to proceed with something he has not
changed. At
minimum, it produces delay while the user checks every option 'just in case.'
Each of the above Modules is the only software in the Any-to-Any machine that
does
the named action. Any Software Module in the Any-to-Any machine, that requires
the named
action to be done, calls the appropriate Module to do it. Hence a given type
of action is best
done in one single manner.
Because of this simplicity, tracing errors becomes relatively simple because a
given
error can only come from one place in 'the software' - 'the software' in this
instance, being all
available Software Modules. If a fax does not go through, the error can be
traced to the exact
source. For example, either 'DIALER' received a number or it did not. If it
did not, then 'FIND
NUMBER' is at fault if a valid number existed - etc.
248
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
All Software Modules are Named - and this name is recorded in the 'Software
Module
(name)' field of the Data Relation Table. Each Data Relation Table record that
forms part of a
given Software Module is identically named with that Software Module's name in
the Software
Module Name field of those Data Relation Table records making up the Software
Module.
Methods exist in the Any-to-Any machine enabling a user to change any name of
anything and essentially this is done by setting the user's new name for that
thing as an
equivalent of the default name in the application. Additionally, whenever
something is
renamed in this manner, the re-naming methods include making that re-name
valid only for
that user. Hence, if many users use the same application - all applications
written with the
Any-to-Any machine's methods are intrinsically multi-user - each user can have
their own
name for something if they wish.
Because Software Modules are named - in principle with the word that best
labels
what they actually do - they can be called directly by the user, or by the
programmer, by
name.
Because all Software Modules are Named and can be referred to and called by
name,
Any Module with Any Specification can by chained with Any other Any other
Module and Any
other Specification without limit: Additionally, Software Modules can be
chained simply by
chaining the names as in the following example:
FAX Specification 1, PRINT Specification 2, MAKE appointment per
Specification 3.
Because Any group of Anything can be named by the user, Any Module with Any
Specification that is chained in Any order with Any other Module and Any other
Specification,
can be given Any group name by the user. If the user issues the Software
Module Group
name as an order, the Software Modules he has named will execute in the order
he has
named them. For example, a user might create a Software Module Group Name of '
DEAL
DONE' as follows:
DEAL DONE = FAX Specification 1, PRINT Specification 2, APPOINTMENT
Specification 3.
Because - as will be covered in the Detailed Description - users can create
their own
Conditions simply by stating those Conditions - a user can then give an order
such as:
'If Condition 1,2,3, etc, do DEAL DONE'
In teat fife such an order might be given in the form of this example:
"If my wife calls by 18.00 and says "We did it" do DEAL DONE.'
The user does not have to do anything other that simply impose the
relationship of
Software Modules that he wants and impose the name he wants for the group. The
relationships he imposes are recorded in the Data Relation Table. The
relationship exists and
249
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
is therefore operational from the instant it is created. Because each Software
Module is
independent, and also self-sufficient and complete in itself, Any Software
Module can be used
in Any sequence with Any other Software Module.
This solves a major problem in the state of the art by enabling a user to
program his
computer without knowing how to program.
- Method for Constructing and Operating (Software) Condition Records
Condition Records are of two basic types:
User Conditions. User Conditions are themselves of a number of types that will
be
explained in the Detailed Description, but are basically statements of the
type 'if X happens or
exists, do Y'. Such user Conditions are essentially Data Relation Table
searches that are run
in various manners with various results, such as alerting the user, or
launching one or more
Executions.
Software Conditions Records of the Record Type Software Module, Record Sub-
type
Condition records are records that state Conditions that may exist that are of
importance to
software Execution, both in ensuring that it can occur, and in handling the
results, if
necessary, when it does occur. It is this type of Condition record that will
now be further
described:
A (Software) Condition Record enables the Field Logic held in each field of
the
Execution Record to compare the contents of its own number of field in the
Data Record or
records (containing the Specification on which the Execution Record is to
operate) with the
Condition stated in the same field in the Condition Record. Alternatively,
when many
Conditions exist a specialized 'Condition Tester' Software Module can be used
that contains
Field Logics in each field which compares the contents of a large number of
Data Records
with a the contents of a large number of Condition records.
In practice, the first step of any Execution is testing whether the Condition
exists to
perform the Execution successfully. Hence, a Software Module name, such as
'FAX' is
usually the name for the part of the Module and the Execution Record that
tests whether the
Conditions exist to send a fax successfully and if the appropriate Conditions
are not met, uses
the values in a companion Director Record to get them met. When all necessary
Conditions
are met - i.e. when 'a fax' Content is available to be faxed, a number exists
to fax it to, and
specific hardware exists capable of transmitting 'a fax' - the FAX Module
sends the requisite
information in the form of a Token to a one Software Module that actually
handles and
controls the mechanics of Dialing and thence to another Software Module that
handles the
actual faxing.
An action cannot be performed on a nothing and hence, every Execution of any
kind
actually requires one or more Conditions to be met in order to complete
successfully - at a
250
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
minimum it requires that there is at least some data on which to operate.
Condition Records
enable the Conditions that could exist prior to an Execution to be stated.
Once so stated in a
condition record the remaining parts of the Software Module can check whether
particular
Conditions are met, and take appropriate Action.
Additionally, as already described, (Software) Condition records for a given
Software
Mddule state, between them, all the different Conditions that can exist when a
given
Execution fails, and therefore provide the basis for corrective actions.
- Method for Constructing and Operating Execution Records
Execution Records are the records that either contain or reference the Field
Logics
that actually perform the manipulation for which the particular Software
Module is responsible.
Each field of an Execution Record, with the exception of the field holding the
Software
Module's Name, the field holding its record number and the Token fields, hold
a single logic
called a 'Field Logic' that operates only on its own field. The Controller
Logic field holds the
Controller Logic that controls the behavior of the Field Logics.
j 5 Thee are two ways in general of storing Execution records and the records
comprising
a given Software Module. Which method is chosen depends on the application
being
programmed. In the first method, described below, the Software Data Components
are
stored in the standard manner - Values in Data Class Tables, references to
those values in
Data Relation Table records. In this case, Software Module Records hold number
references
to values, with the same system as used for Data records in the Data Relation
Table that hold
references to values that are held in the Data Class Tables.
The user can control Software Modules using any combination of two different
methods:
Visual Interface in use:
A Visual Interface essentially requires some mechanism or other, which the
user can
activate to cause the manipulation he requires. One of these is an Icon -
called an Action'
button - labeled with the word for the action the user wishes to do such as
'FAX' or 'E-MAIL'.
When a manipulation is activated by the user for example by clicking with the
mouse on a
particular Icon made available by the interface:
1. An executable file, called 'Execution' is called by the Action button,
which supplies the Execution file with its Label (The Label value it uses is
the same as
the name of the Software Module to be activated).
2. The 'Execution' file queries the Data Relation Table for all records of
Records of type Module, with the same Software Module Name as name of the
Action
button the user clicked and which it has received from the Icon.
251
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
3. The Execution file copies all found records into a database table called
the 'Translate' table, and calls an executable file called Translate. It
passes to
'Translate' the name of the Software Module it has read into the 'Translate
Table'
together with the first of the record numbers in that table. (In a multi-user
environment, there could be several instances of a given Software Module in
the
Translate table at any one time, therefore, this mechanism ensures that the
Translate
executable file acts on the right one).
4. The Translate Table is an exact copy of the Data Relation Table, but is
normally empty - it holds only software Modules that are being translated.
5. The Translate executable fife, accesses each record it finds in the
Translate table using the Module name it has received, and looks up the
reference it
finds in each field, in the appropriate Data Class table that that has the
same number
name as the Record Sub-Type it is translating. There is normally one Data
Class
table for each type of Software Module Record. Thus, there is one Data Class
table
i 5 for Software Module Conditions, one for Logics etc. The Translate
executable file
uses the reference in each field in each record of the Module it is
translating, and
either translates and then loads the actual value into memory, or translates
and copies
the actual values found in the appropriate Data Class Table into the
Translated Table.
Which of these methods is used depends on the application. Programmers of
small
applications may prefer to translate directly into memory. Programmers of
large
applications may prefer to use a Translate Table and make suitable
arrangements to
keep translated Modules there on a 'least used, first out' basis, in order to
economize
on translation time. Because of the Any-to-Any nature of the Any-to-Any
machine
however, a particular Software Module that is being translated one way in one
machine can be moved to another machine where translation is set up the other
way.
The Software Module will still operate and requires no change to do so. If a
Translated Table is used, then it is also, like the Translate table, an exact
copy of the
Data Relation Table fields. (If the database being used cannot accept all the
different
data types involved in a given Software Module in a given fields, then one
Translated
Table is required for each Software Module Record type. if that option is
used, the
Translate executable fife is written to take account of this.
6. The Translate executable file sends a token to an executable file called
Delete that deletes every record in the Translate Table that is marked "done"
in its
Status field. Hence, when all records are translated, the Translate file is
empty.
252
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
7. The Translate fife terminates after activating an executable file called
Memory by sending a token to it containing the record number and name of the
Software Module that is to be run.
8. Memory copies the Controller Logics of each Software Module record, .
and all the Logic fields of the Execution Record into memory, where the code
executes.
Language Processor Interface in use:
The Language Processor Interface creates - using the New Record
Module - a new record where it records the users order, in Data Relation Table
p format.
2. An executable file, called 'Execution' is called by the Language
processor, which supplies the Execution file with the Action Name (which is
the same
as the name of the Software Module to be activated).
3. Steps (3) - (9) proceed identically as for the Visual Interface. Note
15 that the change between Visual and Language processor interfaces does not
require
any change in the 'Execution' executable file. This file still receives the
same data, but
from a different source, and a change of source for the data does not require
a
change of the executable file itself. The above forms an example of how the
parts of
an Any-to-Any software machine fit together.
20 Software Module Records hold actual values. This option can save space in
small
applications (for example embedded applications, or an application such as a
telephone
where memory is in short supply. In this option, all Software Modules are
translated as
described above, but the Data Class Tables themselves are not loaded into the
application,
only the Translated table is loaded, containing translated Software Modules.
As already
25 described, in this case the Translated table has the identical field format
to the Data Relation
Table, so that parallelism is preserved between the Software Module records
and the data.
If the 'pre-translation' method is in use, the 'Execution' executable file
that is called by
whichever interface is in use receives the name of the action to be done and
immediately
calls the 'Memory' Software Module step (7) and (8) above using a Token.
30 It should be noticed that two storage options - storage of Software Module
references
or storage of Software Module values) and two interface options (Visual or
Interface) - give
four possible combinations of completely different circumstances, but to
accommodate these
changes requires only one change in one small file, the 'Execution' Executable
Module.
Additionally - and providing that two hardware platforms are compatible of the
Software
35 Module is written in a language that is compatible with both platforms - no
additional change
is required to move a Software Module that is running on one computer with one
method, to
253
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
another computer running another method. This also highlights how a programmer
can easily
fall into what can be a mistake. In the example above, where Software Modules
are pre-
translated, the only action required of the Execution executable file is to
call the Memory
executable file. Therefore, it could be argued that the 'Execution' executable
file serves no
real purpose, and that therefore, the interface should call the 'Memory'
executable file directly.
This leads rapidly to the idea that each Action button should perhaps have its
own version of
the 'Execution' executable file. However, as soon as these changes are made,
fixed
relationships have been established and a One-to-Many machine created. Equally
obviously,
as soon as this is the case, one application can no longer be moved or copied
into the space
of other applications, and operate successfully. Hence, logic is now required
to tie the two
One-to-Many machines together, etc.
A small application using the Any-to-Any machine methods can be built by using
a full
size application of the Any-to-Any machine to do build it because the smaller
application will
use fewer Data Relation Table fields than the larger one, and consequently,
the application
can be built in the larger application, using only those fields that will be
actually used in the
smaller application. If parallelism of both format and procedure is
maintained, the small
application can be transferred into the machine in which it is to operate once
it has been built
and is running correctly. If some operation fails, the small application can
be transferred back
and errors found easily. Updates or revisions can be handled in the same
manner, including
automatic downloading from one machine to another. However, if parallelism of
structure and
functioning is not maintained, this interoperability no longer possible.
Therefore it is a teaching of the Any-to-Any machine that when writing small
applications, the procedures required in larger applications should not be
short-circuited, but
should at all times remain compatible. This method of maintaining
interoperability is termed
the 'Parallelism of Structure and Function Maintenance Method.'
The above is an outline of the flexibility and simplicity produced by the Any-
to-Any -
machine's Any-to-Any software construction. In this example, only four simple
Modules, in
this case executable files, are required to accommodate two different types of
input - Visual
or language processor - and two different types of Software Module storage.
Only one code
change is needed - involving a few lines of code - in the Execution file - to
accommodate all
variations and this too can be accommodated by providing two differently named
versions of
the Execution file, together with a Module and its Condition records to detect
which one to
use.
254
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- Method for Constructing Input and Output Mechanisms - View Records versus
Classic Systems
View Data Relation Table records are records that are needed by the interface
to
control the input/output for the screen, printers, projectors, e-mail, fax,
telephone etc.
In the state of the art there is normally a One-to-Many, fixed relationship in
any given
software package between the parts of the software that manipulate the data,
and the parts of
the software that state how it is to be displayed. This is coupled to another
One-to-Many
construction - the Operating System input output mechanisms using One-to-Many
strict
protocols and complex software One-to-Many constructions. These mechanisms are
then
coupled to the physical device by further One-to-Many mechanisms.
In software packages written for popular operating systems, the programmer
decides
how this display shall look and creates a number of programmatically fixed
relationships that
may provide a few different displays tailored to display or output the result
of manipulation in a
few, fixed ways. The display instructions are then communicated to the
operating system
using a One-to-Many communication protocol to control the screen display -
many programs,
using one protocol. All these are variants of the One-to-Many theme, and like
all such
systems, require expert knowledge to create and expert knowledge to change.
Very Tittle
about any one display screen is controllable either by the user, or even by
the program itself.
In other words, the program cannot change EVERY aspect of its look or when and
how it
outputs depending on -for example - the amount or importance of the data to be
displayed.
The potential combinations - each of which require special programming -
become too
complex programmatically and too complex to use, and therefore, are not done.
Such a state of the art input/output systems can be used by an application
written with
the methods of the Any-to-Any machine, but, if the application is something
other than a small
embedded application, then its ability to manipulate data exceeds the ability
of state of the art
inputloutput system either to supply it with data or to display the results of
manipulation and
the application is severely hampered if coupled to a state of the art display
control
mechanism. In an office suite application of the Any-to-Any machine, there are
approximately
100 fields to choose from, all of which display different aspects of the same
item or items.
The greatest difficulty arises when attempting to display relationships of
groups of things, as a
human uses grouping as a data manipulation tool in a very extensive manner,
and an
application built with the methods of the Any-to-Any machine can track with
this, but, in
practice, it proves difficult to display all the possible resulting
relationships using state of the
art, One-to-Many input/output mechanisms.
Even a combination of - say - 20 records, each with 100 fields, gives an
almost
unimaginable number of possible combinations. The reason for this is when
displaying data
255
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Components, it is not just a question of whether that data appears or not -
i.e. a simple
combination - but also where that data appears in the sequence. Supposing
three records
exist with three fields each, then there are nine combinations, but these
simple combinations
take account only of whether or not a specific field appears, not where that
field appears, how
many times it appears as a field can appear more than once 'the good good
Wednesday', and
the fact that when a field does not appear at all, with data manipulation, the
non appearance
of a value is also significant. Thus, when considering the combinations that
can be produced
by 3 records each with three fields, the possible combinations are not 9 but
sixty and the
possible combinations increase exponentially as the numbers of records and
fields increase.
Consequently, 20 records with 100 fields yields not 3,000 combinations but
millions of
combinations and a state of the art interface is not capable of adequate
display in practice, as
enormous numbers of programmer-created screens would be required to display
every
possible combination, and devising a manner for the user to choose which
screen he wants
would be equally impractical. Hence the absence of the ability in the state of
the art, for the
data and the user to be able to control the display, means that only a few
screens can be
provided by a programmer, and these should be learned by the user, and
anything the user
should learn before he can do, creates an ease of use problem.
In other words, an application built with the methods of the Any-to-Any
machine can
manipulate the data in a manner extremely useful to the user, but displaying
it requires the
ability to set up the display to show - for example 180 fields out of 3,600
possible fields in few
records and show them in a specific order, in a specific place on the screen.
Not only does it
require the ability to set up the display in this manner, it also requires the
ability to do so
based on the mere fact of the user issuing the order to do so.
While 100 or so fields may be available in the application for a small, 1
record item, it
is physically difficult to display a list of items on a screen and show 100
fields for each item.
Nor is it even desirable to do so, as if the user wants to see 5 aspects of
each item - i.e. 5
fields from each item, he actively does not want to see the other 95. This
means the user
should be able to state which 5 he wants to see, and thereby, eliminate the
other 95. fn fact,
the situation is worse than this, since many Data Relation Table records -
especially records
of communications - are in fact used in pairs with one record pertaining to
the 'this side' or the
person using the machine, and another record pertaining to the other person
involved. Hence
a complete record for many items and for all transmitted items, consists of at
least two Data
Relation Table records, or potentially of 200 fields. Then, a user may want to
see perhaps
one field of the 5 fields he chooses as large as possible - i.e, full screen -
because this field
contains the Content and he wants to see more of it. The number of possible
display
combinations and other output combinations rapidly approach infinity.
z5s
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
If for example, a user may ask: "Show me the names and telephone numbers and
birth dates and our last communication date for everyone who communicated to
us about
bananas, and show me what they said and the last communication destination" -
this request
can be processed by the Data Relation Table and require columns to be
displayed for:
Name Telephone N° Birth date Last Comm. Date Content
Location
In the state of the art, if this particular combination of columns has not
been
programmed, it cannot be displayed with user intervention, and the user's
order may be _
processed correctly by the application written with the methods of this Any-to-
Any machine,
but the order overall will be considered by the user to have failed, because
he cannot see or
output the result. Effectively, the computer then becomes labeled as
'unreliable'_because the
user cannot predict which of his orders will succeed and which ones will fail -
as far as he is
concerned. The application will be considered a failure, because no one will
use a machine
or software that they consider unreliable. As discussed in the background, the
mere fact that
an order may fail when it should not, is in fact a type of limit, and
introduces complexity and
confusion.
The above example makes it clear the display of the data should be able to be
controlled by the user himself and potentially by the data itself. If a
Language Processor
Interface is used the fields to be displayed have to be able to be controlled
by the user's order
itself. If the user asks for data that occurs in fields 1,9,14,23,99, then
fields 1,9,14,23,99,
should be displayed in the order he requested.
View Records are the Any-to-Any mechanism of the Any-to-Any machine, working
in
cooperation with the Interface, used to achieve this.
Not all applications will require this level of interface flexibility. In very
small
embedded applications, such as in a telephone for example, where the Data
Relation Table
will be very small, it may be possible to provide adequate functionality using
classic interface
methods. If the Interface is not used; then the programmer should create the
screens he
feels are needed to display the Data Relation Table field that he feels are
desirable to his
application. He can do so by building the Specification of the View into the
Data Relation
Table as will be described in the Detail Description.
- Method for Constructing View Records
Methods to build and input/output interface that is also an Any-to-Any machine
are
described below. When the methods are used, the screen is taken over by the
Interface
Model application and used to display a particular selection of Data Relation
Table fields.
Each Data Relation Table field is by a type of screen object called an 'Active
Element'. Each
Active Element services-one Data Relation Table field at any one time.
Similarly to all
257
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
construction methods throughout this Any-to-Any machine, only one of any one
particular
Active element exists if the computer is not turned on, but if it is turned
on, any number of
copies of any one Active Element can be employed and in use.
A 'View' - which comprises the entire screen - consists of Sub-Views, and each
Sub-
View is a combination composed entirely of a particular assortment of Active
Elements.
There is nothing on the screen that is not an Active Element. Most Active
Element can
display the contents of Any Data Relation Table field although specialist
Active Elements do
exist for some purposes.. Every Active Element displays the contents of only
one user data
field. Another copy of the same Active Element can be used to display another
user data field
- and in this case, each Active Element can be controlled independently of any
other Active
Element. Active Elements can also be controlled as a group.
A Sub-view can display data from one Data Relation Table record, or from many
Data
Relation Table records, or both simultaneously.
Active Elements are able to launch a Software module when clicked with a
mouse, or
touched with a touch screen, or when so ordered through the Language
Processor.
Most Active Elements have the ability to:
1. Display Any user data for the Data Relation Table
field it is servicing
2. Accept Any Input of user data for the Data Relation
Table field it is servicing
3. Display Any label for the Data Relation Table field
it is servicing
4. Display Any Prompt for the Data Relation Table
field it is servicing
5. Display Any Help for the Data Relation Tabfe field
it is servicing
6. Display at Any size
7. Assume any visual appearance
8. Display text in any format (i.e. any font, any color etc)
9. Perform Any filter.
10. Perform Any sort order.
11. Assume any visual aspect, including transparent
12. Display any behavior-for example, reducing in size, or turning edge-on or
turning sideways and this behavior can be controlled by the user or by any
Condition - for
example by another Active Element if the other Active Element requires more
space and has
priority.
Visually, Active Elements can look the same as state of the art icons and are
then
called Action buttons, as they have considerably more capabilities than an
Icon and the term
Action Button is used to distinguish them from icons. Active Elements can be
made to look
like icons and grouped to look like menus. When an Active Element is being a
menu button,
the label it displays is the name of the Software Module that it activates
when clicked. If the
258
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
user re-names the icon for his own convenience, then this name he uses is set
as a
translation of the original name, and points to the original name. The Any-to-
Any machine
includes mechanisms allowing any user to name anything any way he wants,
without that also
changing the name the software uses for the item.
Thus, one part oflthe screen - in fact a Sub-View - can look like a menu bar
while
another part - another Sub-View - looks like a letter. Still a third part can
look like a
spreadsheet. A fourth Sub-View can look like a list of communications and a
fifth looks like a
selection area where the user chooses what to display in the list, what
Boolean operators to
use, and which sort order to use. All values displayed by Active Elements or
used by them to
control how they look or behave are stored as Data Relation Table records.
Normally the experienced user's starting point is a particular default view
called "Battle
Manager". In a Battle Manager View the screen is split into Sub-views,
consisting of a
general-purpose menu, and areas listing in tabular format Time Past, Present
Time and
Future Time. Past Present and Future areas display, for each area, items he
has done, items
he has scheduled to do today including items that are started but not
completed, and items he
has scheduled for the future. The use of the Any-to-Any machine enables
everything that
concerns the user to be assembled on one screen. This has not so far been
achieved in the
state of the art, where many Personal Information Managers assemble some
things and leave
out others, giving the user an incomplete picture of his day. For example,
'tasks' and
'meeting' may be shown but 'phone messages received' will not be shown,
'incomplete
spreadsheet X' will not be shown, unless someone specifically enters these
things. The
absence of Start Time, Finish Time and Time Used - fields that are found in
all Data Relation
Table records - does not permit the software to add up the time required for
planned
activities. Thus, the user does not have the information he needs readily
available to move
his planned items around by priority so that he can make what he should do fit
with the time
he has available. This gives one example of the usefulness of the ability to
choose any Data
Relation Table field and display it with any other Data Relation Table field.
A single Active Element can, when started, display a prompt, in its display
area, and
then re-use that same physical area for data entry, and then re-use the same
physical area
for displaying the result of the data entry.
In effect, with the Interface, the entire screen is itself a menu, as
everything on the
screen, with few exceptions, does something. Any Software Module can be
attached to Any
Active Element and activated by it when clicked. Hence, a Interface screen is
referred to as
an 'Active Screen' because it is composed of Active Elements all of which can
be active in the
sense that when they are clicked, they do something - i.e. launch a Software
Module.
259
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
One Active Screen - a particular selection of Active Elements - can be used to
select
Data Relation Table records for display, and any number of Active Screens can
be used to
display the results of that selection or look at in different ways. These
different ways can be
recorded for future use or not, as the user chooses.
Hence a 'View Record' as previously referred to, is not a single record but is
in fact
several Software Modules each composed of a number of Data Relation Table
records. The
Data Relation Table records that make up a View Module and how a View Module
operates is
described in the Detailed Description.
The programmer provides the user with at least two default Views for each
Software
Module that could require any display. It is useful for each View to be
created is one of a pair
- one view showing an entire item, and another showing a list of those items,
and that menu
buttons are provided to enable the user to change between them, and to display
both at once.
The programmer selects and arranges Active Elements to make a View. Thereafter
the user can change the default View in any manner he wishes. If he does so,
then his
revised version is saved as a new View by mechanisms to be covered in the
Detailed
Description. The result is that a given user can have his own View - or Views -
of any data,
while other users can create their own Views of that same data. This is
achieved partly by
using the 'User' field that exists in every Data Relation Table record - the
particular View is
saved and related to that particular user.
A Software Module can control whether the View Module that it works with turns
on -
and therefore displays - or is not turned on, and therefore, does not display.
In this manner,
complex commands given by the user can be executed without displaying - unless
they hit an
error - while the user does something else on the screen. Additionally, a
Software Module
can turn on the entire View, or simply turn on parts of it. Any Module can use
Any View, and
hence it can change Views depending on the data it finds. This enables Views
to be adapted
to the abilities of the user. For a Non-User, the Software Module can be made
to feed
Prompts one at a time, while for an experienced user, the screen can be made
to look like -
and behave like - any state of the art software program if that is what he
wants.
- Method for Constructing Label Records; Method for converting a One-to-Many
database into an Any-to-Any machine
Most state of the art databases will not accept Any and all data types in any
one single
field . Few state of the art databases can record every data type - text, or
an actual image, or
a single spreadsheet cell etc - in a single field, which is in already in use
for one of those
types. A database in the state of the art, like all other state of the art
software, is intrinsically
a One-to-Many machine - One field has a fixed relationship to One type of data
in that field -
either to text, or to numbers,. or to YeslNo, or to... etc - and Many
different values (but only
260
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
values of the designated type) can now be entered in the field. The Any-to-Any
machine
method of using reference numbers in the Data Relation Table instead of actual
values,
fundamentally changes a state of the art database. In affect, the Any-to-Any
machine
disassembles the intrinsic One-to-Many relationship described above and
enables any field to
accept any value by using the method of entering the reference to the value
rather than the
value itself. The Any-to-Any machine contains fundamental methods and
teachings that
enable an Any-to-Any machine to be constructed using state of the art database
tools. The
first of these is that as soon as every value is only recorded in a Data
Relation Table as a
reference number, then any database, and any Data Relation Table field is
enabled to record
any Data Component type or any combination of Data Component types. A given
number in
a given Data Relation Table field can then be the reference number for text,
an image, or a
spreadsheet assembly and any field.
Most state of the art databases incorporate other One-ta-Many relationships
that
should also be disassembled in order to re-use them as an Any-to-Any machine.
One of
these is the One-to-Many relationship that is normally established between a
database field
and its field name. The Any-to-Any machine contains methods that - effectively
- remove
this One-to-Many relationship and convert it into an Any-to-Any relationship
between the
contents of the field and the 'name' for the field, as follows.
As described previously, a teaching of the Any-to-Any machine is that all
tables and
fields - including the Data Relation Table and its fields - are not named with
words and
instead are named with numbers. This method results in a subtle but
fundamental change,
since the 'field name' is now no longer necessarily the name that is displayed
for that field -
i.e. the field name now has no fixed relation with a particular label for that
field - a single
'name' for the many values in the field. Instead the number 'name' can now be
used only as
one name for the table itself, or for the field itself, as opposed to being a
name for the all the
many contents of the table or all the many contents field.
If the Interface is in use, these number 'field names' or number 'table names'
are not
displayed except for a person who wishes to program an application. Using only
numbers to
name a tables or field enables that number for a field (or a table) to be
incorporated as part of
any other number, and particularly as part of any reference number. A
reference number can
then be created that is a Combined Number that combines one reference number
designating
a value with another that designates a table andlor a field. This is made more
flexible with the
near-future availability of 64 and 132 bit numbers. The availability of large
numbers, together
with naming all structures with numbers, gives the possibility to combine a
number of
relationships within a single number. For example, if it was desired to record
a relationship
pointing to record 22 in a certain table, and to field 24 in that record, the
reference number for
261
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
could then be 2224. If it was desired to refer to table 3, record 22, field
24, then the
combined reference number becomes 32224. If the programmer chooses to
establish
relationships in this manner, then corresponding Field Logics are written
appropriately. Such
appropriately written Field Logics, seeing this number, can correctly
interpret the number, and
hence correctly interpret the relationships stated by the number. Thus,
referring to the above
example of a Combined relational reference Number, if is required to find all
Specifications
that contain any field 24 value, logic looks for xxx24. If all field 24s in
table 3 are required,
then the query is for 3xx24 and so on.
The further method of the Any-to-Any machine that - effectively - removes the
One-
to-Many fixed relationship that is normally built into a database and concerts
a database into
an Any-to-Any structure is the Any-to-Any machine method for disconnecting the
field name
that is displayed from the field, itself, as follows.
If the methods described below are used to build the interface then the
interface is
able to display any Label for Any field. Essentially, the database in use to
construct the Any-
to-Any machine is not allowed to display itself at all, since if it is allowed
to do so, it imposes
its One-to-Many relationships between data labels and screen display and
prevents the Any-
to-Any machine from acting as an Any-to-Any machine in that respect. Instead
of the
database displaying its field names, the equivalent function is performed by
Active Elements
that display 'Labels' for data.
'Labels' for data are stated in a type of Data Relation Table record termed a
':Label
Record'. Every Active Element can display data provided by a Data Relation
Table Label
record type. Since any ability of an Active Element can be used in combination
with any other
ability of an Active Element - or none, an Active Element can display the
contents of a Label
record field as its own Label. Or, it can display the Label and be otherwise
invisible, and
thereby be used simply to put text on some area of the screen.
In addition to containing a reference number to a value in a Data Class Table,
any
field in any Data Relation Table record can contain a pointer that is a
reference to any other
table and/or any other record and/or any other field with the method described
above. Hence,
a Data Relation Table Label record type can either contain a reference to a
value held in the
Label Data Class Table, or contain a reference number that is a pointer to any
tablelrecordlfield and hence can contain a reference number that points to a
particular field in
a Data Relation Table data record. This method of the Any-to-Any machine
enables a
computer to display Any Name for Any data, or for no data at all. .
The following are two examples of the usefulness that results from this
ability:
Example 1: A Data Relation Table user data record could contain in one its
fields a
reference that is a reference for text characters that say 'Furniture' and the
next field contains
262
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
a reference for what is in fact the sub-type of the previous field and
contains a reference to
the text 'chair'. Now suppose that the similarly, another Data Relation Table
user data record
could contain in the exact same first field as the other record, a reference
to the text 'Photo'
and in the second, sub-type field, contains a reference to an image such as a
photograph.
Suppose now that Label Records are constructed to go with each of these, and
that the first
Label Record contains in 'one of its fields a pointer to the Data Relation
Table user data
record containing the reference to the value 'furniture'. Suppose further that
the reference in
the Label Record field is a compound reference part of which points to the
'furniture' and the
other part of which points to a value in the Label Data Class Table which is '
space) Type'.
This enables one Active Element to display the Label 'Furniture Type' together
with the value
obtained from the user data record 'Chair'. A second Active Element can then
display, in any
desired spatial relationships to the first Active element, the image, which is
a photograph of a
chair.
These aspects of the Any-to-Any method of the Any-to-Any machine enable a
computer to display Any label for Any data. As this example shows, the data
itself can
provide its own label.
The combination of the one ability - to record (the reference to) any data in
any given
field - with a second ability - to give any Label to that data - effectively
means that a computer
is enabled to contain and use any data that has existed, exists now, or ever
will exist. This
unique ability is has not been possible in the state of the art.
Example 2: The same type of Data Component - i.e. the same Data Class of Data
in
a given Data Relation Table - may be called different things under different
circumstances.
For example:
A reference code for a product is called a UPC Code
A reference code for a bank account is called an Account Number
A reference code for a machine on which one talks is called a Telephone Number
A ref. code for a machine to which one sends documents is a Fax number
A reference code for an e-mail destination is called an E-mail address
Remembering the teaching of the Any-to-Any machine that data is classified
based on
the type of its meaning, each of the above have a type of meaning that is more
similar to one
another, than their meanings are similar to any other type of meanings - i.e.
they meet the
definition for a Data Class. Their common meanings could be roughly expressed
as 'a
assembly of characters that is a designator for something.' Thus, a UPC Code
is not a
product itself, it is not a name for a product as such, but it does designate
particular
Specification of one product. An Account number is not the account itself, it
is a designator of
on account. Similarly,,a telephone number is not a telephone, but a designator
of one
263
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
particular telephone. An e-mail address is not the electronic post box itself,
but a designator
of that post box. Any one of the above Reference Codes could, theoretically,
be detached
from the thing it is now applied to and be re-applied to another thing - for
example to another
thing of the same type.
Reference codes frequently contain both digits and characters. Some telephone
numbers are expressed and transmitted between people as combinations of
letters and
characters - for example '1-800 CAR - HIRE'. Hence, the fact that a reference
'code' is
actually a number, or a character, or a symbol, or any combination of these,
does not change
its meaning. Data Classes classify data by type of meaning not by grammatical
constructions, since only then can items be accessed based on meaning. The
meaning of a
reference code essentially is 'an assembly of characters used to uniquely
identify something
or group of things'. The location of the something being identified may, or
may not change,
but in either case, is not essential. It may or may not be known where a
mobile telephone is
exactly or where an e-mail address is physically. However, both are reference
codes and
their usefulness derives from the fact that both of them have a relationship
with Mr. X. Thus,
both of them have the similarity of being a communication channel to a person,
and in fact are
simply different types of communication channel, with corresponding different
types of
reference code.
For example:
Name of this Kind Subtype Reference Ref Number
Of
Product Ketchup 12133455 UPC Code
Bank Account Savings 121-0000-313-Account Number
000
Communication Telephone 1 212 222 Telephone Number
2212
Communication Fax 1 212 222 Fax Number
2211
Communication Post Box E-mail Address
Referring to the example above of Reference codes, the Label to be displayed
with a
given value in the Reference Number Field can be taken by the Active Element
from the
contents Ref Number Type field of Data that is to be displayed. Thus a label
for a Reference
code that is a phone number can display 'Telephone number'. However, if the
reference code
of a product is to be displayed, then the label displayed will be 'UPC Code'.
The ability to use
the Type of something as the Label for the that thing provided by the Any-to-
Any machine
methods of disassembling a state of the ari database field name from the
field, and
264
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
disassembling the display from the database, is one of the novel methods that
enables what
would be a single field in a normal database, to record an unlimited number of
different values
of the same type, when a state of the art database would require one field for
each different
value type. Not only this, but it enables such an application to answer a very
typical human
query as "do you have reference number for that?", something that a state of
the art
application could not do reliably.
When all reference codes are kept in a Data Class Field that has the generic
working
name of 'Reference Code' then queries such as 'what is this number?' 'What
methods exist to
communicate to Mr. X?" can be answered easily, without requiring complex logic
to do so.
However the advantages of this method are more fundamental than this, as
follows:
For the above reasons, all names of Data Classes and Data Relation Table
fields
used in this description are generic working names for data with a particular
meaning in
common - i.e. a Data Class of data. One Label Record in the Data Relation
Table contains
the Generic Name for each Data Class in the Table.
The ability to record dissimilar types of data in a single field, and the
ability to label any
given data with any label, enables data with the same type of meaning to be
stored in a single
field for data with that common meaning. In the case of this example, the
methods enable all
reference codes of any types whatsoever - Model numbers, Series numbers, part
numbers
etc, as well as the examples previously mentioned - to be stored in a single
data base field.
The advantage of this method is that it enables the vast mass of data that
exists in the
world, to be broken down into Data Classes arid when so classed, the number of
classes that
can be found to exist is relatively view. For example, every material thing
that exists
anywhere whatsoever, falls into the Data Category of Matter. There is not one
material thing
anywhere that does not fall into the Data Category of Matter. From then on, it
is simply a
question of the degree to which it is useful to continue dividing the types of
that data into
Classes and Sub-Classes. In effect, a Data Class is a type of something within
a Data
Category and a Type of something in a Data Category can be expressed as a Data
Class.
Thus the number of Data Classes and Sub-Classes in a given application is a
question of the
mass of data to be recorded. If the mass of data is large, then it is
advisable to divide a Data
Category into as many Data Classes and Data Sub-Classes and Data Sub-Sub-
Classes as
possible. Doing so 'widens' the Data Relation Table and has the effect of
increasing the
number of fields than can be queried simultaneously in a 'parallel query'
operation. (A parallel
query' is defined as 'a query in which many Data Classes are queried at the
same time, using
the Co-Reducing Concept Method, so that each query only operates on the subset
of all data
already found by any other query so far '), if the application is relatively
small, then instead of
making an entire Data,Sub-Class out of one type of data, a field is provided
for 'Type' or 'Sub-
265
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
type' and instead of making each of one type into a Data Sub-Class with a
corresponding
Data Relation Table field, those types are entered into the 'Type' or 'Sub-
Type field and in this
manner, the Data Relation Table can be contracted or expanded as necessary, in
an
interchangeable manner if suitable Software Modules are provided to convert
between one
Data Relation Table and another.
Where the type of Data in a Data Class X or Data Sub-Class Y etc is subject to
being
called different things under different circumstances, the Data Class should
have a sub-Class
called 'Type' or Sub-Type, or A Sub-Sub-Type (etc) - as needed for the
application in
question - in which the type or Sub-Type or Sub-Sub-Type (etc) of data is
recorded.
A Label (serving the function that was previously served in the state of the
art by a
field name) can be displayed or not, following the Any-to-Any principle. Very
often, with the
Interface, a Label (field name) is not required and is not displayed at all,
as once data is
entered, it is often self-evident what that data is. For example, an address
display, 'Mr. Joe
Doe, 24 Technical Terrace' does not require a label to label Joe as first name
and Doe as last
15. name - that is evident from their physical positioning in relation to one
another and a Label is
both superfluous and consumes screen space which is at a premium. When data is
to be
entered, a Label is also unnecessary, as then the Prompt itself can state what
type of data is
to be displayed. In an Active Screen, usually the Prompt record value displays
in the data
entry area, and when over-written by entering data, disappears and if the data
is re-moved,
the Prompt again re-appears in the Data entry area. Once the data is entered,
it is frequently
self-evident what that data is, but when it is not, a Label can be used, and
this Label can
depend on whatever data the Active Element is displaying.
The main requirement for Labels (field names) in the Interface is for use as
column
headings and to label particular areas of the screen to that it is clear that
the area - rather
than a specific field - contains data about something. But on the Any-to-Any
principle, a
Column heading can be provided by any field value - for example by a User
(name) field, a
Prompt record, or even a Help record as each Active Element can display any
field value in
any of its display areas..
Any number of Label Records can be used in constructing a screen, on the basis
of
one per Active Element used. If a field in a Label record is used to Label a
screen area, then
it is displayed by an Active Element in the View that displays the actual
value of the reference
contained in the Label Data Class Table. If a Label Record field is used to
Label data, then it
can associated with an appropriate data record type and consequently, if there
are many Data
Relation Table record types for user data each displaying a different type of
data, each one of
those types may have their own Label records. Alternately, the reference
displayed by an
266
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Active Element Label field display area can point to whatever value is
contained in the Data
Class sub-type "Type" field, and hence display the type of the data as a label
for the data.
Label Records, like all other display or output-related record types, are
associated with
groups of types of data items, and/or with individual members of a data group,
and/or with
individual users and hence the particular Label displayed can be individual to
that user. Thus,
Any user can display Any data labeled in Any manner, and each user can modify
default
arrangements - provided by the programmer - to whatever arrangement suits him
best.
Because of this method - termed 'The Interchangeabifity Principle of Data Type
and
Class' - the data of a small application with a small Data Relation Table can
be automatically
converted - i.e. 'uploaded' or 'read' - by a much larger application with a
much larger Data
Relation Table. Conversely, any data in an application with a urge Data
Relation Table can
be automatically converted - i.e. 'downloaded' or 'read' - by an application
with a small Data
Relation Table. Colloquially, any and all the data in a fat short Data
Relation Table can be
converted into a thin long Data Relation Table and vice versa. The further
implication, is that
any one Data Relation Table built with this method can query any other Data
Relation Table,
and suitable Modules can be constructed to transmit, and receive. and
seamlessly incorporate
its data.
The ability to hold all data of any type, and the inter-convertibility between
different
sizes of applications created with the Any-to-Any machine is a further unique
advantage of
the Any-to-Any machine when compared to the state of the art.
In the state of the art, one type of reference code requires one field. This
is due to the
fact that a database used in the state of the art manner is a One-to-Many
machine. Because
of this, one of the rigid fixed relationships it imposes is between 1) the
Label for a field, 2) the
data in that field. The result of this One-to-Many arrangement is that, if
three million types of
reference code exist in the world, each with their own name, then three
million database fields
are required to hold them. Because of this, reference codes will have to split
across a
number of databases. No matter how many types of fields exist to hold
reference numbers,
no matter how many databases are programmed to hold those reference codes,
there will still
be new types of reference numbers invented daily and hence an unending stead
of new
databases required to hold them. Worse still, each of these databases does not
recognize
that the reference code it is holding and calling a UPC code is in fact, a
reference code, and
therefore there is no compatibility of any kind between these databases. This
requires a user
to hunt over the entire world to try and find a database that knows what the
UPC codes are,
and hence, what is the UPC code for product X.
267
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Evidence of the magnitude of the problems that these methods of the Any-to-Any
machine remove is the $2 billion a year industry that exists to solve the
problems involved in
enabling connectivity between databases.
In summary, the problem results from the state of the art practice to create
fixed, One-
to-Many relationships between:
1. The contents of a database field (Many)
2. The Name of the Field (One)
3. The Label displayed for the data in the field by the interface. (One).
The Any-to-Any teaching of the Any-to-Any machine is that each of these three
types
of thing are individual Components, and therefore, may have no fixed
relationship, but should
be treated as separate Components and should be stored separately. Doing this,
then allows
Any number of Any one of them to be able to be related to Any number of Any
other of them.
Hence, in this Any-to-Any machine, the three items above are handled as
follows:
The number reference of Any field record or table or combination of these can
be
stored in Any Data Relation Table field, and therefore related in that Data
Relation Table
record, to Any number of Any other data or Component.
The number 'Name' of a field, record or table is not related to the contents
in any fixed
manner.
Any Label can be displayed for any data in any field, and the label displayed
is not
related to the number 'Name' of the field.
Additionally, on the Any-to-Any principle, a Label may be displayed quite on
its own,
without having to be related to any data at all. (i.e. the number of relations
of a Label to user
data fields displayed can be zero).
Any Software Module can be associated with Any number of Views, that
themselves
use Any number of any Label Records. A Label Record can be composed of Any
field value.
A Label record - like all other Data Relation Table records - and as will be
explained in more
detail later - can be assembled from Any selection of individual Labels.
- Method for Constructing Records irivolved in Displaying Formats
A considerable number of record types exist in the Any-to-Any machine to
control the
format of data output by Active Elements, and these are described in detail in
the Detailed
Description.
Each field of a Format-type Record, similarly to a Label Record, contains data
that is
associated with a particular field in the Data Relation Table, and with a
particular Active
Element, that displays that data. A different Format-type record may exist for
each aspect of
formatting that is in use - for example, one for font name, one for font
style, one for font size,
one for Underline, one for color etc. Alternately, although each of these
values should be
268
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
stored separately in order to presence the Any-to-Any machine as an Any-to-Any
machine,
any or many of them may be combined into a Combined Number reference number,
where
one part of the number refers to font name, one part to font style etc.
Note that when a Combined Number is in use, logic handles it as a Combined
Number, and not as just one big number. This means that logic treats each
group of digits in
the number as a single entity. Hence a Combined Number composed of four
references, is
not one number, but four numbers. Thus digits 2 to 5 are reference A, digits.
6 to 9 are
reference B, digits 10 to 14 are reference C, and digits 15 to 20 are
reference D, for example.
Hence, if one machine is handling 128 bit numbers and another is using 64 bit
numbers, the
larger machine will require a Software Module that splits the records down
into Component
Combined Numbers for the smaller number machine.
If all aspects of formatting that are in use can be combined into a single
Combined
Number format reference number, then only one type of Format record is
required. if all
aspects of formatting in use are too many to combine into a single compound
reference
number, then the aspects of formatting in use should be broken up into groups,
and the
groups assembled in appropriate and different types of Format records, that
View logic is
written to handle, although a useful method is that each format control has
its own record.
This illustrates one basic principle of Any-to-Any software of the Any-to-Any
machine - that
while any data in any part of the system should be broken into all its
Component parts for
storage and subsequent assembly, references to such Component parts may be
combined in
any manner that is practical and useful.
Because Data Components - in this case, of data format Components - are stored
separately, and therefore, each has its own individual reference, that
Component can be
individually accessed and, because it can be accessed individually and non-
hierarchically, it
can be modified individually- i.e., controlled individually, by the user, or
by the programmer
- Method for Constructing Prompt Records; User Equivalency Tables. Adapting
to the User
A Prompt record is similar to a Label Record, except that it serves the
purpose of
prompting - i.e. asks the user a question - and it therefore preferably does
so in a manner
that phrases the Prompt as a human might phrase the same question - for
example: 'Enter
Telephone Number ....HERE....??'. (It is desirable to guide the user by using
certain
conventions for screen messages).
When used with a Data Relation Table data entry Active Element, a Prompt
record
normally displays in the space provided for data entry, thereby a) economizing
on screen
space and b) showing the user exactly where to put the data. If so used,
Active Element logic
269
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
is such that the Prompt vanishes when the user begins data entry, and re-
appears if the user
removes the data from the field.
Prompt Records are also related to the type of data to be entered. The type of
data
that is to entered is related to the particular type of data entry the user
has requested. Thus if
the user is entering an address, the Prompt Record for the Reference Code
field discussed
above could usefully be: Enter Telephone Number ....HERE....??', while the
label for that
data, if required to be displayed at all, would be 'Telephone Number'.
'Telephone Number' is
in fact the Label for a Reference Code Data Class field when it is being used
to store a
telephone number.
Hence, a 'Label' is further defined as:
'A Short statement of the type of data displayed'
While a 'Prompt' is defined as
'The statement of the type of data to be entered, expressed as a question.'
A Label with this method says to the user "This is the type of data this is'
while a
Prompt says to the user 'Do you want to enter this type of data?
Hence a Prompt is in reality the Label rephrased as a question. Hence, the
Label for
a given data, being in Any-to-Any Component form, can be used as a Component
of its
opposite number Prompt.
Hence, Prompt records can reference data stored in the prompt Data Class;
equally,
Prompts can be constructed by as records containing Field Logics which create
a Prompt by
executing the following steps:
Take Prompt Data Class record 4 (-'....ENTER')
Add to this whatever the Label record for this data is (i.e. 'Telephone
Number')
Add to this Prompt Data Class record 6(='.....HERE....??')
And in this manner constructing the Prompt
ENTER Telephone Number ....HERE....??',
This method is particularly useful in an application that may contain many
different
sub-types of a given Data Class, and ensures that if the Label mechanism is
correct - i.e.
points to the correct field - then the Prompt will be also.
Equally, this method allows the user to create his own Prompts if he wishes to
do so.
In the same manner that he can create his own Labels if he wishes to do that
as follows:
When an application written with the Any-to-Any machine is intended to allow
each
user to redefine anything he wants to redefine - such as a Prompt or Label,
then each Data
Class Table is accompanied with what is termed a 'User Equivalency Table',
containing three
fields 1 ) User Number, 2) User Data Ref, 3) Standard Data Ref. In the above
example, if the
user over-writes 'Enter Telephone Number ....HERE....??' with 'Put Phone here
OK?'
270
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Referring now, for simplicity of this explanation, only to the part of the
over-written data
concerning Prompt Data Class records 4 (-'....ENTER') and 6: (-
'.....HERE....??'). The
user has over-written (-'....ENTER') with 'Put' and this gets entered as a
number value in the
Prompt Data Class table as number 138. The user over-wrote '.....HERE....??'
with 'here
OK?' and this gets entered in the Prompt Data Class table as number 139, by
the Prompt
Overwrite Software Module which was activated by the user over-writing the
Prompt or
otherwise indicating he wished to change it. Supposing that the user's number
is 1113, then
the Prompt Overwrite Enters values into the User Equivalency Table as follows:
User Number User Data Ref Standard Data Ref
1113 138 4
1113 139 6
A Translate In Data executable file is am executable file or Software Module
that
receives data entered by the user into an Active Element and translates it -
using the
appropriate Data Class Table - into Data Class Table reference numbers and
then enters
these reference numbers into the New Record being created. (A New Record is
created for
each and every action that is done).
A Translate Out Data executable file is an executable file or Software Module
that
takes Data Class reference numbers in a record that is to be output anywhere
(except to
another, local or distant application written using the Any-to-Any machine).
1t looks up these
reference numbers - using the appropriate Data Class Table - and transfers the
corresponding values to an Output buffer in Data Relation Table format, from
which the Active
Elements involved in the output collect it.
Enabling an application to adapt to a user's preferences in this manner
requires the
following steps:
1. Providing Overwrite Modules or their equivalent, for each Data Class
for which the user is to be allowed the freedom to change existing entries.
(New
entries may require a definition - and the procedure for this will be
described later.
But an equivalent of something cannot be set until there is something for it
to be
equivalent to).
2. Providing User Equivalency Tables for each Data Class.
3. Writing a new Translate executable files or Software Modules, so that
data to go into the Data Relation Table results in the value given by the user
being
looked up in the User Equivalency Table, finding from that Standard Data
Reference,
271
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
and using that value in the Data Relation Table as Standard Data References
are the
only reference numbers used in the Data Relation Table. In this~manner, any
user can
have his own equivalency for a Standard Data Reference.
Disabling this type of user adaptation only requires replacing the Translate
In Data
and Translate Out Data executable files with similar files that omit the User
Equivalency Table
translation step.
Because of the nature of this method, a value entered in a Data Class by a
programmer, or, in the absence.of such a value, any new value entered for the
first time by a
user is the default or Standard value and its reference is the Standard Data
Reference for
that value. Any value entered by a user as an Equivalent of a Standard data
Reference is not
placed in the Data Relation Table unless a special record type is created to
record this type of
value. In this manner, data is held in the Data Relation Table is recorded in
a standard
manner, but if there are 100 different users, then each of them can use his
own terms as he
wishes. When a number of different users look at given data, each will see it
in his own terms
- in the manner that is easy for him to use and understand.
This method of the Any-to-Any machine is of only limited usefulness in the
example
given above for changing a Prompt. However, it becomes desirable when
Qualities are
concerned, where variably is considerable, and different people use different
terms for the
same thing. Thus, User number 1 may use the words 'Top Rush' for something
that is of the
highest urgency, and 'Urgent' for an item that is less urgent than 'Top Rush'.
However, User
number 1 will use 'Urgent' as his word for highest urgency, and 'Rush' for an
item that is less
urgent than 'Urgent.'
User Equivalency Tables allow - as one example - each user to designate at
installation time,. which words he uses to indicate the highest urgency. As a
result, if an item
is that has the highest urgency is looked at by User 1, the words 'Top Rush'
will be displayed
but the word 'Urgent' will be displayed if user 2 looks at the same time.
Words of Quality can
cause considerable confusion in a business, but this method of the Any-to-Any
machine
removes that confusion, as well as enabling any user to adapt his display and
output and
express it in terms that are most real to him.
- Method for Constructing Help Records
The state of the art actual practice is that one size of Help fits all -
virtually all state of
the art programs are provided with one text on any one topic. This idealized
text, presumably
designed for a non-existent idealized person, in fact suits no one exactly,
and is a particularly
harmful problem where low education, completely new users are concerned.
Investigation
shows that that such users, for example in underdeveloped countries where
great market
potential exists, are simply incapable of understanding the 'Help' in a state
of the art software
272
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
package. Such persons have to be hand taught by a teacher, and frequently,
neither
teaching facilities nor funds exist to provide the necessary assistance.
Such state of the art Help can not span and be satisfactory to the entirety of
the range
of understanding, from that of a young child or un-educated person in a low-
income country
up to the most expert computer programmer. Not only that, but the knowledge
and
understanding of a human is not necessarily the same on one particular topic
as his
understanding on another, closely associated topic. Thus, he can need Help at
almost child-
level on one part of an application and highly expert help on another part.
Furthermore,
confusions about the meanings of words are common, leading to such phenomena
as a
sentence that most people can understand, but some people cannot understand.
The human
solution to this problem is to re-state the same concept using different words
but state of the
art software does not do this, effectively leaving means of its Help readers
in as much
mystery after reading Help as they were before - and this alone is a
considerable problem
and barrier to ease of use.
Any application - collection of Software Modules with a common objective can
be
expected to have a wide range of users, with their correspondingly wide range
of knowledge,
experience and ability to understand.
In order to provide the users described above with Help that is suited to each
of them,
each and every individual item that can appear on the screen actually needs to
have its own
explanation - its own Help - and not only that, but the Help that is give
should be suitable for
the user concerned. For example, a field that, in the state of the art,
displays a field label
'Telephone number' and a blank space, may be a simple problem for an educated
user but
may leave low education new users completely puzzled and asking questions such
as 'Will it
give me a telephone number if I wait?' 'What telephone number goes in there,
if one should
go in there?' 'How do I put a telephone number in there?' 'What do I do?'
Practical
experiments have shown that providing even one level of help - approximately
10 written lines
- per database field produces a dramatic improvement in a database
application, to the point
that an application shown to one person, becomes self-propagating thereafter,
and requires
no special training.
However, one level of Help per Data Relation Table field is inadequate to
cover all the
possible levels of understanding that may exist in an application's users.
Hence, as with Label Records, a Help system written with the methods of the
Any-to-
Any machine is able to be tailored - by the user himself or by the user's
responses - not only
to the data being displayed, but also to the user's knowledge level.
This is achieved by providing a type of Data Relation Table record termed a
"Help'
Record.
273
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Like all other Data Relation Table records, Data Relation Table Help Records
are
assemblies of references to Help values held in a 'Help' Data Class Table.
Individual field
entries in the 'Help' Data Class Table contain either the Hefp message itself,
or a disk
reference to the Help text, at the choice of the programmer.
Because Any number of Help Records can be used with Any other record, it then
becomes possible to write Software Modules that manage Help, so that each
given item is
accompanied by a number of Help Records that between them, give an explanation
tailored
to all levels of expertise that are likely to be encountered. Because a Help
Record is
constructed as an Any-to-Any construction, Any Help Message can be used in Any
Help
record field of Any Active Element. This permits Help to be tailored field-by-
field, and to be
tailored dynamically - for example, by placing two buttons in each Help
message (buttons
that are actually Active Elements visually lying over the top of the Help
Message) with
associated Labels provided by an associate Label Record, titled 'More Detail'
and 'Less
Detail'. Clicking on either of these can have the results of exchanging the
Help value either in
for that field only, or in changing the entire Help record being displayed.
The effect for the
user is that Any amount of detail of Help - more detail, or less detail - is
available at Any time
on Any data.
All Data Relation Table records provide administrative fields for counting the
use of
any records, and this can be extended to counting the use of any fields.
Averaging
mechanisms, or other mechanisms - for example, related to student responses -
can be
used to predict the level of detail - and hence the Help Record or Help field
to be displayed for
associated topics and methods are included in the Detailed Description for
adjusting the level
of detail of Help provided to suit the individual user's requirements.
Similarly, as will be
described in the Detailed Description, in any situation where a choice exists -
for example as
in this case, where the software implements a number of levels of records with
increasing
detail for given data - mechanisms exist to track this, and display the right
level for that user.
Similarly, methods exist to ensure that the Help displayed is appropriate to
the data
being displayed, with the similar effect to that described for Label records,
where the Label
displayed is appropriate to the data displayed.
In effect, because of the Any-to-Any construction method for Help, a computer
is
enabled to provide Help to one user at one level of detail in an area where he
is expert, and at
a more detailed level in another area where he is less expert. Additionally,
the same Help or
different Help records can be used by other users using the same application
to provide the
level of details they need for each item. The effect is similar to a
supermarket for Help, where
each buy picks the Help product that suits him.
- Method to Provide Unlimited Data Depth
274
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
As described previously, Data Relation Table records can be related to one
another in
a number of ways and thereby relate the data they reference. Data Relation
Table fields can
also be related to Data Relation Table records as previously described.
Further, Any Data
Relation Table Data Category can have its own Data Relation Table record type.
Further, any
Data Relation Table field can have its own Data Relation Table record sub-
type. For
example, the Data Relation Table field 'First Name' (type User data) can have
a Data Relation
Table record sub-type 'First Name' record. The Data Relation Table field (Data
Class) can
have its own Data Relation Table record sub-type 'Relation' record.
Every Data Relation Table record contains all Data Relation Table fields.
Consequently, a 'First Name' record type contains a 'First Name' field in
addition to all other
Data Relation Table fields, and a Data Relation Table 'Relation' type record
contains a
'Relation' field, in addition to all other Data Relation Table fields.
This Method and principle of the Any-to-Any machine in this respect is similar
to The
Interchangeability Principle of Data Type and Class previously described and
is referred to as
'The Interchangeability Principle & Method of Data Field and Record'. Together
with the first
Interchangeability principle, it implies the Interchangeability of Data Type,
Data Class, Data
Field and Data Record.
The following are examples of the power and utility of this method:
A concomitant sub-type of Data Relation Table record, type Data Class Data, is
a
Data Relation Table record, Data Category type such as a 'Space' (Location)
record. A Data
Category type records essentially relates the entirety of the data it contains
or points to, to the
entirety of the entry Data Category of the mother record that points to it.
Hence, a Space
(Location record) can contain any description of a given location that is
required. For
example, this enables a phrase such as the following to be expressed as Data
Relation Table
records.
'The area 'was full of smoke' (record 1).
'It (the area) was hot, humid and unlivable' (record 2, a Location Data
Category
Record).
The Language Processor, in recording this, ensures that record 1 points to
record 2.
At least two methods can be used to do this.
Record 1, in its Location Type field, points to record 2. Several ways, not
previously
discussed, also exist for doing this.
Each Data Category has a 'Content, Description' field and this field is used
to point to
the description that is record 2. This mechanism is typically used when the
entirety of a Data
Category is to be described.
275
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
When a Data Class Field within a Data Category is to be described only, then
the field
to be further described can contain as a reference number, the number of
another Data
Relation Table that contains the description.
All Data Relation Table records contain an 'AND' (next record number is) field
and an
"AND WAS' (-And previous record was) fields. Hence the 'And' field can contain
a reference
to record 2. Additionally, since each Data Category has its own number, any
record pointer in
an 'AND' field can point to multiple Data Category type records. Additionally,
any given fieid,
can point to a Serial record that lists a number of Data Relation Table
records that state data
about, or are used to control the field to which they are related.
Additionally, since the 'AND' as well as the 'AND WAS' fields can again have a
Data
Relation Table record of their own type, the entry in an 'AND' field or an
'AND WAS' field can
point to a record of their own type and through this method point to any
number of succeeding
records - i.e. data branches.
These general methods of expanding a given field or field value can continue
without
any limit other than the physical capacities of the storage mechanism used,
and the ability of
the machine to process it, and the ability of the programmer to write Software
Modules whose
logics handle the relationships correctly.
Record 1, can be paralleled with by any number of other Data Relation Table
records
of a type termed a Data Relation Table record, 'Relatiori' type. A Relation
record is a record
that is the Data Relation Table record extension of the Relation Data Relation
Table Relation
field. In this type of record each of its fields contain a pointer to another
field, or record. In
the example given above the accompanying Relation record would contain, in the
same field
as the data record contains the word 'area' a pointer to record 2.
More than one relation record can accompany any data record or group of data
records, and if so, a Sequence record can be used to list them. Sequence
records
themselves can be strung together indefinitely using the AND and AND WAS
fields.
While it may be argued that these methods are capable recording a considerable
complexity of relationships, it should be noted that a human is capable of
relating Any Data to
Any other Data. In terms of this Any-to-Any machine, a human is capable of
relating a single
Data Component to:
Another Data Component, (which can be a single Data Relation Table
field),
2. To a Category of Components (to a data category in a Data Relation
Table record)
3. To a group of Data Components (a Data Relation Table record)
276
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
4. To a group of a group of any of the above (Grouping mechanisms exist
in the Any-to-Any machine and will be described in the Detailed Description).
5. Additionally, Any number of the above to Any number of the above
A human is capable of constructing extremely complex data relationships, and
hence,
the Any-to-Any machine has mechanisms capable of tracking and recording every
type of
data relationship a human is capable of creating. Consequently, the
relationships that can be
created with the Any-to-Any machine are as complex as the data relationships a
human is
capable of creating. Attempting to provide visual mechanisms allowing a human
to specify
the complexity of relationships that he is' capable of creating, while
possible using the visual
interface is laborious and it is only here that a Stage II Language Processor
becomes
especially useful. This is because it is a lot quicker and faster for a human
to express the
data relationships he wants to establish using language, than using any more
solid material
means such as a Visual Interface.
However, the relation methods themselves are desirable because the software
should
be capable of processing data in a human like manner, whether the source is a
Visual
Interface or a Language Processor.
Particular and unique advantages of the methods described above are that they
enable a computer to process data in a similar manner to one desirable aspect
of human data
processing:
A human who receives a query from another human such as "Where is Joe?" may
know enough about Joe to talk on the subject of Joe for several days without
stopping.
However, when asked the question "Where is Joe?" the human does not then
produce all
known data about Joe, and after 24 hours of issuing all known data about Joe,
add that the
Joe described is in Chicago. Instead, the human may reply "Joe? Oh he is the
guy who went
to Chicago." However, if asked, the human will immediately and without delay
amplify any or
all aspects of Joe. This illustrates that 1 ) depth of available data and 2)
depth of access of
that data are two corppletely different things.
A human who is asked for further data concerning something about which he
knows a
great deal, will ask for a selection Specification for the data required. If
he is asked 'Tell me
about Joe,' he is likely to reply with 'what do you want to know?' - i.e. a
data Specification is
requested, and then usually given - 'Well, what does Joe do?'
Hence, an initial query Specification, requires the computer to Return Nearest
Truth
and nothing more, i.e., in terms, of the example above, 'Where is Joe?' - to
return the
appropriate Data Relation Table field value, i.e. 'Chicago.' However, any such
data that is
returned in response to a human query and is then given to the human, may then
instantly
lead to a further query such as 'tell me about Joe' and this may require logic
to access the
277
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
pointers in or associated with a field or fields of the accessed record. Since
pointers to other
fields or records in. a Data Class field or record are recognizably different
to - not the same as
- value references, accessing the one (for example the value 'Chicago') does
not imply being
forced to automatically access the other-the pointer. The effect is that the
computer can
return the data requested - i.e. answer the question 'where is Joe?' with
'Chicago' - without
swamping the user with all known facts about Joe: However, having accessed the
value
'Chicago' it already has available the pointers needed to amplify the data
about Joe and
Chicago, if requested to do so. Having accessed the data about Joe and
Chicago, it also has
the Reference numbers for both of these, and is ready to find and locate
anything else that
exists to do with Joe, and anything else that exists to do with Chicago.
Similar to a human,
the software is ready to talk and tell you all it knows about the subject
under discussed, but
will not do so, unless specifically requested to do so.
This method presents a significant advance over the state of the art data
handling,
where, ~ivhen a database is queried, it either produces nothing at all, or
produces all known
instances that match the query. In effect, in the state of the art, the
computer intrinsically
answers a query about Joe and Chicago, by producing everything it knows about
Joe and
everything it knows about Chicago, and Boolean operators are one of the
mechanisms used
to attempt to tame this intrinsic operating basis. As Internet search engines
show when they
produce several hundred thousand hits to a given query, these mechanisms do
not solve the
problem in the state of the art, while the above method of the Any-to-Any
machine is part of
the solution to such problems.
This also illustrates what the word 'know' really means in computer terms and
hence,
what the word 'know' means in relation to the Any-to-Any machine. Describing a
human's
data processing in terms of the Any-to-Any machine, a human 'knows' something
if he has
recorded a relationship between the Data Components that state what it is he
'knows'.
If a human made the following statement: 'In 1892, Army A beat army B' he
would be
said to 'know' that - 'in 1892 Army A beat Army B'. In terms of the Any-to-Any
machine,
therefore, a computer will 'know' what a human knows, if it is capable of
correctly recording
the relationships between the Data Components '1892', 'Army A' and 'Army B.'
Hence the
Any-to-Any machine enables a computer to copy a human ability that humans
label with the
word 'know'.
- Method Fundamentally Enabling Any Data to be Related to Any (other) Data in
a Computer.
In summary, any data may be related to any other data in a computer are as
follows:
1. Data of all and every type is stored as Data Components
278
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2. Any number of Data Components can be assembled together in a data
assembly.
3. These data assemblies may be further assembled with other Data
Components or with other data assemblies or both
4. There is no limit to the extent to which the assembly process can
continue.
5. The assembly plan of Any data assembly can be recorded using the
Data Relation Table and other tables in the Any-to-Any machine.
6. Any data assembly that is recorded can be given any name by the user
- for example it can be called 'an address' or 'a field logic'
7. Only a user imposes hierarchies.
8. Any recorded data assembly can be recorded in a manner that is
hierarchical but there is no obligation on the user to do so.
9. If a data assembly is recorded in a hierarchical manner, it can still also
be recorded as a member of an unlimited number of other hierarchies. It can
still also
be use in a non-hierarchical manner.
10. Particular assemblies of data that have not been recorded previously,
can be recorded at any time.
11. Software data assemblies (Software Modules are recorded by a
Programmer deciding what he wishes the Software Module to do, and then by
assembling - or first writing and then assembling - suitable Data Components
to
accomplish what he wants the Software Module to do.
12. A user data creates a user data assembly from user Data Components
using Software Modules that locate and assemble the required user Data
Components, in the process, record any user Data Components not previously
recorded.
13. Any user data assembly a user creates or finds is recorded by the
Software Module that created it or that found it.
14. User data assemblies are found by Software Modules that locate data
assemblies containing the particular combination of Data Components the user
specifies. User Data assemblies that have been found may then be manipulated,
including their further assembly with any user Data Components and/or with any
user
Data Component assembly.
15. Any user data assembly is intrinsically related to every other user data
assembly, with which it has at least one user Data Component in common. This
279
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
intrinsic relationship may or may not be known to the user but can be found by
Software Modules designed to find commonality of user Data Components.
16. Any user data assembly may be named and when named, may
subsequently be found by name.
In real life, any two or more of anything are related ifi:
1. A person says states that they are related
2. They have any one aspect in common. This relationship may, or may
not, be known - i.e. may or may not be recorded.
The Any-to-Any machine methods enable a computer to copy or emulate these two
fundamental methods of relating data. The first method of relating data - 1 )
above - is
essentially a method that is implemented in the Any-to-Any machine using logic
- Software
Modules. A user essentially states 'this' is related to 'that', when he says
so, by stating to a
suitable Software Module 'this' is related to 'that' - the Software Module
then creates a Data
Relation Table record that by the referenced values it contains, states 'this'
is related to 'that'.
The second method of relating data - 2) above - is essentially a method that
is
implemented in the Any-to-Any machine using structure - the Data Relation
Table and other
tables of the Any-to-Any machine. The structures hold Data Components in such
a manner
that commonality of Data Components and Data Component patters and
combinations is
detectable.
Hence, the Any-to-Any machine methods that enable any data to be related to
any
(other) data are neither wholly structural not wholly logical, but a
combination of both, Hence,
also, when a programmer uses a particular type of structural relationship - a
particular kind of
Data Relation Table records - he should necessarily write Software Modules
that take
account and are written for the structure he decides to use.
The fundamental, unique, non-obvious and novel differences between the Any-to-
Any
machine methods of relating data and state of the art methods of relating data
in a computer
then, are:
1. State of the art software does not usually provide for recording and
assembling Data Components, but instead provide for and record only assemblies
of
Data Components.
2. Words themselves are assemblies of Data Components because each
word has more than one meaning. Because the Any-to-Any machine separates words
into Data Components in which each meaning has one symbol or symbol
combination,
and then records and uses these, it can manipulate meanings by manipulating
the
symbols for those meanings. However, state of the art software does not use
this
method as a concrete and all-pervading fundamental method and process. It rnay
280
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
occasionally treat a word as a Data Component, but even then, the Data
Component
is not available individually but only as a software imposed pre-assembly with
other
words. Consequently, state of the art software cannot manipulate meanings,
while the
Any-to-Any machine processes and methods can do so.
- Method to Implement Specific Types of Applications with the Any-to-Any
machine
DATABASE, ADDRESS BOOK, AGENDA
These applications are intrinsic parts of any software implemented with the
Any-to-Any
machine. An 'Address Record' or 'Address Book' is a particular assembly of
various fields in
different Data Relation Table records and will be explained in detail in the
Detailed
Description.
An Agenda item is any item where the 'Start Time' Data Relation Table field is
marked
with a future time and the Execute By field is marked for the user as opposed
to for a
Software Module. Any item whatsoever, whether classed as Agenda or not, can
have any
number of alarms and deadlines set for it using the Remind field in the Time
Data Category,
and appropriate Software Modules perform the Execution
GENERAL DOCUMENTS. LETTERS, MEMOS, NOTES, E-MAIL, FAXES, REPORTS AND
PUBLISHING AND WORD-PROCESSING DOCUMENTS IN GENERAL
These documents are different combinations of document names, formats and
outputs appearances and are all produced and handled by the methods of the Any-
to-Any
machine. A programmer can provide a variety of templates for such items for
different
purposes,.and any item - not just a word processing program can be made into a
Template.
Effectively a 'template' is defined in the Any-to-Any machine as a specific
arrangement of
Data Class fields, without values in them, and these are saved as named item
type, along
with a Software Module to create that item type. Modifying one type of item to
make it into
another, and then giving the new type a name is something that can be done by
the user
changing any existing document type. The Software module that created the
previous item
type is saved again as the Module to create the new item type.
Any document can contain Anything, and hence, a word processing document can
contain a video, sound clip, photo or other image or drawing, though, with the
methods of the
Any-to-Any machine, an item does not as such 'contain' anything. Instead,
different data that
are 'contained' in the item are simply displayed or output with a specific
spatial relationship to
one another, but are stored as separate Component Assemblies together with the
assembly
plan - Data Relation Table records stating how the item is assembled. Because
nothing is
'inside' anything else, mechanisms to place one document type inside another -
such as
Object Linking and Embedding.etc - are not required. Items, of any kind,
containing
281
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
anything, are simply assembled and the assembly is displayed by the Visual
interface, which
is capable of displaying any assembly with the parts in any relationship to
one another.
All items are, or can be assemblies of specific Data Class fields output by
one or more
Active Elements each of which obtain their data from a specific Data Relation
Table record's
field. The Active Elements for items such as sound clips and videos can play
their contents
when clicked, and like any other Active Element, can be resized by their
content to occupy the
whole screen while playing, if necessary. If names are required for such
Active Elements,
they are displayed and considered as Labels. Alternatively, another Active
Element can
display their Label. Active Elements can display written Content that has been
recorded as a
block, or convert speech to text dynamically as another item is played.
Publishing programs
essentially require only a few additional Software Modules, and Active Element
types that are
enabled to flow Content Data Relation Table entries from one to another, and
can thereby be
used as columns and boxes.
DRAWING
Following the method of lnterchangeability of Fields and Records, every Data
Relation
Table record can have a 'Content, Drawing' field and this field can be
extended as a Data
Relation Table record, Data Type, Drawing Sub-Type, and various Sub-Sub-Types.
All of the
Format sub-type Data Relation Table records that have been created for use
with the
applications can be available and used when 'drawing', together with the View
software
Modules that input or output them. Thus, applications already installed would
be likely to
include records containing Specifications for colors of fields and text, all
text formats, etc. In
effect, the principal additions required to expand the ability of software
built with the Any-to-
Any machine that already containing all the features of a major state of the
art word processor
are:
1. One method is to add a 'Shapes' Data Class, containing (or pointing to
the disk location of) shape-construction Specifications that the logic of a
Drawing type
of Active Element can use to display a shapes. Since any Active element can be
any
size, the Active Element scales the object. An Alternative method is to use
Active
Elements themselves. Since Active Elements can be any shape, and can display
their
outline - or not as required - many shapes are simply specifically shaped
Active
Elements displaying their outlines and may, or may not use fill colors,
different borders
etc.
2. Additional Software Modules to take care of specialized drawing
functions such as shadowing, rotating an Active Element that is otherwise
transparent
(thereby giving the effect of rotating the shape), etc. Once such Software
Modules are
282
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
created they then become available for use with any other data - such as for
rotating
a photograph or video.
As described elsewhere, templates - pre-assemblies of Active Elements - can be
created in unlimited variety.
PRESENTATION
'A presentation'; or 'a slide' is viewed in the Any-to-Any machine as a
variant of a
general document, a variant that is normally displayed landscape, uses larger
text letters and
drawing tools described above. 'A slide show' is a series of different
'slides' - items - shown
one after the other usirig a Timing Record. An accompanying Sequence Content
record, in
which each field matches the 'a slide' being shown can, if coupled with text
to speech
software, produce a narration, while another Sequence Content record contains
speaker
notes, and another one, music - etc. Animation effects can be achieved by
using a Timing
Record and a type of Interface Control records that control suitably
constructed Active
Elements to display various Behaviors- the equivalent of ' Animations'. If
such Active
Elements are installed then any data in the Data Relation Table records can be
animated,
from 'spreadsheets' to 'databases' to 'an address book', or any parts of any
items.
VIDEO
While a specialist Active Element can display the contents of a Data Relation
Table
Video Content field at any size, Videos can also be constructed with the
application by
creating what is in effect 'A presentation' and accompanying it with a timing
record that
displays the required number of Data Relation Table records per second to
produce the
desired 'frame rate.' Morphing tools that exist in the state of the art, can
be written as
Software Module used to take two ' slides' and produce a number of
intermediate slides and
once such Software modules are installed, can morph any data type. Outputting
these
intermediate slides rapidly effectively creates a video. A Sound track can be
created by
storing sound files in order in a Sequence Record and then using an
accompanying Sound
Execution record to play the sounds per the same Timing Record used by for
video output.
Slowing or speeding up a video or sound is a question of a percentage
reduction or increase
in Timing Record values. Similarly, a video can be captured and stored as one
Data Relation
Table per frame, and thereafter annotated using the Content field to record
notes, or
calculated using Calculate type records as described for a spreadsheet below.
Hence, a
'Video' can be created from any data stored in the computer whatsoever, from
'address'
displays to letters to spreadsheets - etc.
SPREADSHEET
A spreadsheet as implemented in the Any-to-Any machine not as special type of
application, but only a particular visual arrangement of Data Relation Table
records and a
283
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
particular assembly of Data Relation Table types and Software Modules. The
Data Relation
Table record types summarized below are not reserved to the type of visual
display that is
called 'a spreadsheet' in the state of the art but once installed, can be used
as part of any
item. These Data Relation Table record types are available for use with any
item in the
computer and are of particular use performing calculations on Data Relation
Table selections
of different types - i.e. 'database calculations'.
As per the standard method of the Any-to-Any machine, the Components of a 'a
spreadsheet' are found by disassembling a state of the art spreadsheet into
its Components,
and then providing for the re-assembly and suitable Software modules using the
methods of
the Any-to-Any machine.
'A spreadsheet' may be iniplemented as a block of Data Relation Table records
of the
type called 'Number' records, with various sub-types, and may also use of any
of the types
previously described. Following the standard method of the Any-to-Any machine,
whereby
any existing application data or software is broken down into its smallest
Data Components
and then reassembled, stored and used by type, 'a spreadsheet' breaks down
into various
sub-types of Number records. These are best visualized as a number of blocks
of
spreadsheet cells composed of sheets of cells, with each sheet being composed
of a different
type of record. These sheets lie one behind the other like sheets in a block
of paper, and on
top of all the sheets is the Visual interface sheet composed of a sheet of
cells each one of
which is an Active Element, that is receiving and displaying data from the
sheets lying behind
it. If the user chooses to look at any of the other 'sheet's composed of
different record types
that go to make up the result, each one has its own Visual Interface 'sheet.'
In this
construction, what was a 'cell' in 'a spreadsheet' is one Data Relation Table
field in the Any-
to-Any machine. The main record sub types are.
View Record View Records are made up already summarized.
Interface Control. A number of different sub-sub-type records hold different
aspects of formatting such as colors, fonts, number of decimal places, leading
or trailing
signs, currency type, data format, column and cell widths etc
Condition Record The Conditions 'sheet' is composed of User Condition Records
where the user can state Conditions to be met, and actions to be taken on the
overall display
when those Conditions are met. Like all record types in the Any-to-Any
machine, any number
of Condition record 'sheets' can be used.
Alignment. These records are a member of the 'Format' sub-group and state the
alignment of the data in each field (cell).
Border 'Border' records are a member of the Interface Control sub-group and
state the border for each field (cell).
284
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Number Record. These are the records that hold the numbers entered by the
user or calculated by the formulas
Number Type. These records hold the type of the number (currency etc) for
their display Active Element.
Fixed Values. This type of record is not actually a sheet but simply one or
more Data Relation Table records whose contained values may be used by many
items
besides spreadsheets in the application. They contain values that do not
change and are
used in calculations - such as daily currency 'rates, constants, etc. Fixed
Value records are
independent records not necessarily used by any one spreadsheet but available
to all
'spreadsheets' and other items. Fixed Value records consist of more than one
record type;
some of these contain values, others contain references to specific records
and field, and
others contain Labels.
Formula Formula Records hold the formulas entered by the user - and these
can be entered in the same manner as entered in a normal spreadsheet.
Condition Some Condition Records check that the Conditions for a given formula
and are used by logic to ensure the formula is executable. Interface Control
Condition
records change aspects of the display or output based on the Conditions
specified in them
being met.
Label, Prompt & Help these records contain values for each field. Label values
are
entered by the user. Prompt & Help records are selected and displayed based on
the
matching the formula the user is entering with Help Condition Records
Content Content records allow the user to enter whatever text he wants held in
relation to a field. Each field of the Content records can contain Content.
Calculate Module This type of Software Module Execution record actually
performs the calculation based on the formula entered by the user. Each
different calculation
type is performed by a Software Module, and is a type of Software Module that
only works on
a single field, termed a Software Field Module.
Although generally in business use, the vast majority of spreadsheets are
relatively
small 'A spreadsheet' in the Any-to-Any machine is not limited in size and can
be very small
or infinitely large, and a area of the workspace that looks like and performs
like spreadsheet
can exist 'in' any document or item. It is not 'inserted' into a document or
linked to a
document as in the state of the art practice that is also prone to failure.
Everything in a
document built with the Any-to-Any machine is a Data Relation Table field, and
spreadsheet-
like visual arrangements are just more Data Relation Table fields and as much
part of the
document or item as any of the other Data Relation Table field in it,
including those showing
photographs or text or those that play sounds.
285
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
If the spreadsheet width has more columns than there are fields existing in
the Data
Relation Table, then a new block of fields (cells) is added on using the AND
and AND WAS
fields as previously described. Adding.more rows of cells is a question of
adding more Data
Relation Table records.
These methods of the Any-to-Any machine for handling calculations allow
calculations
to be performed on Data Relation Table records without requiring any prior
data manipulation
in order to do so. A number of Data Relation Table records contain numeric
fields, for
example, one Data Relation Table Matter Category field named 'Cost' and
another named
'Quantity'. While 'a spreadsheet' in the Any-to-Any machine, as described
above, may.
contain the types of Data Relation Table records listed, 'a spreadsheet' may
'contain' any
Data Relation Table record whatsoever. 'A spreadsheet' is a group of Data
Relation Table
records used together as a group and given a group name to identify them.
Hence, 'a
spreadsheet' can contain a Data Relation Table data record that recorded 'a
letter' to a
company to purchase an object at a named price, for example. A Visual
interface can display
this record with the other 'a spreadsheet' records so that they are visually
associated. Hence,
the 'spreadsheet' type of record named above can be used to perform
calculations on
anything in the 'a letter' Data Relation Table records that can be calculated.
In this light, it is
useful for a programmer to provide Software Modules that perform calculations
on individual
fields of whichever Data Relation Table records have been selected. One such
Module could
be termed 'Total (the) Selection' and if 334 records were selected could total
the 'Company
Name' field as 334 if each record had a Company Name. The same 'Total
Selection'
Software Module applied to the 'Cost' Field could total the cost or the Time
Used field. .
A one line 'spreadsheet' applied to the above could calculate Cost per Client
by
dividing one figure by the other.
User Condition Records can be useful to perform a sub-selection on a
selection.
Suppose that a selection of Data Relation Table record is made, of clients who
bought
bananas and the field for the town of their address is shown in the display. A
number of
Condition Records can be made and placed visually below the 'Town' Field, one
showing New
York, one showing Boston etc. A 'spreadsheet' type field can be placed below
each of these
Condition Records and a Software Module called 'Total for Selection &
Condition' can total
the records meeting the stated Condition. 'In this manner, totals can be made
for the number
of clients in New York, the number of clients in Boston etc. In the same
'spreadsheet' record
set, the total number of selected records can also be totaled. A further
'spreadsheet' record
can calculate one as a percentage of the other - i.e. essentially answering
the query ' what
percentage of our clients who bought bananas are based in New York, and what
percentage
in Boston?'
286
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Fixed value records have particular uses in accounting. As one example of
this, it is
state of the art international accounting practice, that 'because it is too
complicated' profits
are almost never calculated on a sale-by sale basis. One reason is that, in
the state of the art
One-to-Many accounting packages it becomes too complex to do so, and
particularly too
complex to apply exchange rates on a daily or hourly basis. Because of this,
the standard
practice is for accountants to apply a 'middle (exchange) rate' for a month.
However, such a
middle rate assumes that sales values and costs are evenly distributed
throughout the month.
If 90% of items are bought or sold at a high rate for example, in the first
week.of the month,
and rates subsequently drop, the 'middle rate' in fact can show that the items
sold made a
1 D good profit when in reality they made a bad loss. These inaccuracies are
then patched, by
adding end of year or end of month figures termed 'a currency adjustment'. As
a review of
any financial newspaper shows, these result in reports of millions and even
hundreds of
billions of adjustment, some of which are unpredicted and unexpected losses.
Accounting
practices in the state of the art, which date from the days when complex
calculations were too
time consuming to be possible, use many such fictional estimates. The
cumulative results of
these many unrealistic estimates results in the financial world being startled
with
announcement of billions of dollars of losses by the world's most respectable
companies.
Further, while management needs to know what is happening financially today,
accounting in
the state of the art and in the largest and most respected software packages,
is unable to
provide this information and can only tell management what did happen, too
late for
management to correct the problem before the problem causes million dollar
losses.
This problem traces to the inability, in One-to-Many accounting packages to
calculate
what is happening as it happens. Real-time accounting applications can be
constructed with
the Any-to-Any machine, solving these problems. One element of this is
provided by Fixed
Rate records, allowing Any number of different Fixed Rates to be applied to
Any Data
Relation Table records and changed as frequently as needed, even on a minute
by minute
basis and such records and the spreadsheet methods of the Any-to-Any machine
provide the
basis for calculating profit or loss on any and all individual transactions.
A major element in accounting is termed double-entry bookkeeping, in which the
addition or removal of something from one account should result in the entry
or removal of an
equivalent opposite amount in one or more other accounts. Part of the
fundamental
construction of the Any-to-Any machine is that Data Relation Table records can
be natively
used in pairs using the AND, and, AND WAS method previously described. Many
activities
require two sides. For example, in a communication, there are two sides - the
sender and
the received, and many of the Data Relation Table field values are different
for the two sides.
There is one sending fax number and another receiving fax number, one sender's
time and
287
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
another- potentially completely different time zone time for the receiver,
etc. With the
exception of e-mail programs, much of state of the art software ignores
recording data
concerning the originator of something. Further, in the Any-to-Any machine, a
record forming
a AND WAS record to an AND record can act as the AND WAS record for another
AND
record.
This ability of the Any-to-Any machine forms a further underlying requirement
for
accounting applications to be written with the Any-to-Any machine methods. All
Data Relation
Table records contain a 'Calculate' field and a 'Result Calculated' field. The
extension of the
'Calculate' field is the 'Calculate' record types described above. The -
'Calculate' Field in a
given record can contain a reference to a formula - a Calculate Field Logic -
that performs an
action, and places the result in the Calculate Result Field. If so, the
Calculate field can have
in association with it any of the record types described as being part of the
Any-to-Any
machine implementation of 'a spreadsheet', which contain the appropriate Data
Components
just for the field being calculated.
Alternatively, the Calculate Field can point to a one or a set of Calculate
records ('a
spreadsheet'), in which detailed calculations are performed, and the result
can be placed in
the 'Result Calculated' field. In this manner, for example, a Data Relation
Table record that is
part of 'an invoice' can calculate the profit on each individual item in the
invoice. Obviously 'a
spreadsheet' can include any number of fields that are part of any number of
other 'a
spreadsheets' and consequently data is not linked from one spreadsheet to
another but is in
both. Sequence records can be used to state the sequence in which many 'a
spreadsheets'
are to be calculated.
As an example, suppose that a particular assembly of Data Relation Table
records is
created and named a 'customer invoice'. An associated Find Module, working
with the
Invoice Module, looks up prices for items when a user enters the name. A
Number record,
that is displayed with its fields either side of the data record displaying
the product name,
calculates the cost of the quantity of the ordered item. Another Data Relation
Table record,
which is not displayed as part of the invoice, is nonetheless joined to it as
a pair using the
AND, AND WAS method. The Calculate field in this record points to a
spreadsheet that
performs a detailed calculation to arrive at the profit on the sale in the
displayed (invoice
record). The spreadsheet places the result of its lengthy and detailed
calculation in the
Calculation results field of the undisplayed record. Hence, as the invoice is
filled out by an
order clerk or a customer over the Internet, the instant the sale is
confirmed, the profit on that
sale, is recorded line by line, and the - undisplayed - total profit on the
same is also totaled
by another - undisplayed - Number record. Further Software Modules, acting on
the
undisplayed records, can calculate profits by item, by customer, for any
period and other
288
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Modules, acting on this and other data, can prepare a Profit and Loss Account
and Balance
sheet for any period, within minutes of being requested to do so. If
applications in different
are connected by Internet, then suitable Modules can produce consolidated
international
figures just as quickly. Losses can be alerted to the appropriate staff
automatically by
Modules using Condition records. Losses, when they occur, can be stopped
within seconds,
and corrected within minutes. In outline, these are the kind of benefits that
can be provided
by real-time accounting, creating using the methods of the Any-to-Any machine
and
eliminating the problems caused by the state of the art accounting practice
creating historic
financial documents by 'posting' or entering financial documents in batches
from time to time,
which ensures that the information the computer can present is not accurate
unless
everything has been 'posted'. These practices in the state of the art, lead to
accountings
being 'posted' once a month and then 'closed'. After being 'closed' the month
is calculated,
mainly by 'posting' amounts between accounts, and management is then informed
what
happened. Because the Any-to-Any machine can be used to create real-time
accounting
packages, it can enable the world wide practice of accounting to be turned
from what its
practitioners admit is an art - with the consequent liabilities of an art -
into a science that
results in increased business profits due to the increased accuracy and
timeliness of
information provided to managers
The requirement in the state of the art to begin a specific kind of data
manipulation
from a specific place does not exist in the Any-to-Any machine. 'a
spreadsheet' can be begun
starting from a data record, or, interchangeably, 'a spreadsheet' can be begun
and the result
or parts of it placed in a data record.
All data in 'a spreadsheet' is seamlessly integrated into the whole of the
recorded data
and can be found and used in the same manner as any other data. Thus, for
example, a
Data Relation Table field that is visually 'in' a letter, photograph of video
can have an entire 'a
spreadsheet' behind it, or manipulated output of any combination of any Data
Relation Table
fields producing the result displayed.
- Method for Incorporating Existing Applications
Existing applications can be incorporated into software designed with the Any-
to-Any
machine as follows:
Theoretically, connections could be made between each of the 'software
modules'
within an existing application and a Software Module name as described above.
In this
manner a users order could be processed by the Any-to-Any machine, the
Specification
created and then the Action specified in the order used to launch a particular
action in the
existing software. However, existing software packages are already so complex,
that this
method is likely to be self-defeating. Essentially, the process of connecting
the Any-to-Any
289
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
machine of the Any-to-Any machine with the nested complex of One-to-Many
machines that
is state of the art software is likely to be impossibly difficult and more
difficulty than
constructing the Software Modules for an application with the methods of the
Any-to-Any
machine. About the only advantage of doing this is to prolong the life of an
existing package
and save the work of disassembling it, and then reassembling it using one of
the following
options:
Provide 'Find' facility for existing software that assembles all data that is
already available when an item is created with an existing package, and then
use the
Co-reducing Concept Method to enable a user to find things easily. This
requires only
a very small Data Relation Table containing actual values, and no Data Class
fields
and can be done with very little effort and still provide an order of
magnitude
improvement in the 'Find' function. When an item is found in this manner,
clicking on
it launches it, using the normal procedures that exist in some operating
systems. To
this can be added Visual Basic Macros that automatically save the content of
the given
item to the Content field of the reduced Data Relation Table in a generic
format such
as a print file or ASCI. This generic format text can then be incorporated and
used in
Co-Reducing Concept Method searches, and is also available for re-used in any
applications written for the Any-to-Any machine. In this manner, any existing
software
can be used and some functionality can be added to it.
2. Create the full application per the methods of the Any-to-Any machine,
and provide a Data Class for Software Type that enables the Brand Name of the
existing software to be recorded. If the user wishes to create an item with an
existing
package, then the action is started from the application, which records the
available
data in a Data Relation Table as usual, and then launches the existing
package. The
File name the user uses when saving the file is captured and recorded in one
Data
Class field, while the disk address is captured and record in another Data
Class field,
both in the Matter Data Category. Visual Basic or other routines convert the
saved
text into ASCI or another generic format used by the application and record it
in the
Content field transparently for the user. With this method, the benefits of
the
application available, while enabling a user to continue using a package which
he
likes.
3. The above method can be supplemented by Conversion Modules, that
go through data recorded by previous packages, at a time when the computer is
otherwise idle, and parse it into Data Relation Table records, thereby
enabling the
data recorded with the previous packages to be incorporated into the
application.
290
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- Method for Increasing the Functionality of the Any-to-Any machine using Some
Types of Existing Software
VOICE RECOGNITION
The addition of Voice Recognition that works reliably, to the application
constructed
with the methods of the Any-to-Any machine can enable the mouse to be
particularly or
entirely replaced. For example, the ability to state Specifications - for
example of a
paragraph - enables existing Voice Recognition control abilities - to make
something Bold for
example - to be used easily, since the Specification to be acted on can be
identified in human
terms. This is most effective if at least a rudimentary Stage II Language
Processor is
installed. If a full Stage II Language Processor is installed, this enables
the Any-to-Any
machine to process verbal orders from any human - for example users, or
customers -
whether received at a terminal or by telephone.
TEXT TO SPEECH
Combining Voice Recognition with Text to Speech software, whether the Voice
Recognition and Text to Speech software are written with the methods of the
Any-to-Any
machine or not, enables a computer, with or without a Language Processor, to
carry on
conversations with users or customers. This results in a computer being
enabled - if
software is written with the Any-to-Any machine teachings and methods - to
perform tasks
such as acting as call forwarder or message taker, or acting as a dispatcher
for a taxi
company, that takes calls and dispatches taxis, or acting as an air traffic
controller, and, as
previously described, preparations of accounts etc can be fully automatic. The
Any-to-Any
machine enables Conditions to be stated easily. If the programmer provides a
method for
detecting any possible Conditions or a set of Conditions, then any Execution
can be related to
that Condition, including reading pre-recorded messages over phone or radio.
The
programmer can also provide that a Condition record is included that the
Condition of no
other Condition Record being matched, and this no matching Condition,
Condition Record is
related to the Execution of calling a human operator and stating the Condition
for which there
was no match. The Any-to-Any machine already includes methods whereby the user
can
create new Conditions and relate them to Executions. If the Programmer helps
the user by
providing a View that enables the user to view the unmatched Condition
himself, then the
user himself can continually 'teach' the application by relating appropriate
Executions -
Software Modules - to the previously unmatched Condition, so that fewer and
fewer
unmatched Conditions occur and fewer and fewer human interventions are
necessary. The
above can be achieved using very little Language Processing. If full Language
processing is
also installed, then applications written with the Any-to-Any machine can have
the ability to
291
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
'understand' complex and unusual phrasings and to phrase their own replies,
enabling the
application to carry on a natural conversation with its user.
MECHANICAL PERIPHERALS - GENERAL
The Any-to-Any machine intrinsically has the ability to relate words and
meanings to
anything, and hence, the ability to relate words to sounds, images and
electronic. input. It also
has the intrinsic abilities to relate Space - Locations - to one another in a
manner that
replicates their real word relationships. The Detailed Description of the
Space - Location -
category will show the manner in which the Any-to-Any machine records spatial
relationships
of matter.
Space Category Data Relation Table fields provide for recording coordinates
such as
geographical coordinates and relating these to any other data including words
and including
names. This enables a set of coordinates X to be related to a particular word,
words or
names, and to be related to words and names concerning Locations such as 'The
House'. If
Global Position System ('GPS') hardware is added to the computer then suitable
Software
Modules can enter the data into Data Relation Table records in such a manner
that these are
entered as geographical coordinates. By matching the entered records with the
recorded
geographical coordinates of locations the computer can 'know' where it is, and
can also tell
the human where it is in terms the human can understand. Such a computer can
be queried
with 'Where are you?' and the computer is enabled to reply to the query 'At
the House.'
A map, or any parts of a map can be entered into a Data Relation Table as a
Data
Class Content field, Sub-Class Map and this can be related in the same Data
Relation Table
record to geographical coordinates (in the Space Category) and to description.
In additional,
a map can also be entered into the Data Relation Table in the form of Data
Relation Table
records, where each point of note on the map is entered as geographical
coordinates plus the
name of the coordinate set using the Space fields, and a description using the
Content field.
Using a Software Module to match map coordinates recorded as Data Relation
Table records,
the computer can identify where it is even when it has not been there before.
A computer with such peripherals, Voice technology and the power of movement
can
be told to go to a location and will be enabled to do so.
A computer can be provided with ranging peripherals such as ultrasonic ranging
and/or stereoscopic ranging and coupled to peripherals that can detect the
spherical
coordinates of the range provided by the ranging equipment. This combination
enables the
location of any point in space to stated and this can be stated in terms of a
Data Relation
Table record. Any object can be stated as a proportion of a pattern of points
with respect to
an orientation, which is often with respect to gravity - water moving
vertically is a waterfall;
water moving horizontally has a variety of other names such as river or
stream. Such
292
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
patterns of points can be stated as Data Relation Table tables and can be
related to the
words for them, such as 'chair', or 'light switch'.
Patterns of points - objects - expressed as Data Relation Table records can be
related to locations of the same objects using the GPS and ranging
technologies previously
discussed. Hence, a computer can recognize where it is by a) recognizing the
objects where
it is b) querying Data Relation Table records to find the objects recorded as
existing at a given
location. Hence, the computer can recognize where it is even if the objects
have been moved
since it last 'saw' them - i.e. by matching their pattern, finding the type of
object, finding its
recorded characteristics (color etc) and then recording the new locations of
these in space.
Collision avoidance does not have to specifically programmed into a computer
whose
peripherals make it mobile, but can be expressed simply as a Law.
A 'Law' is a statement of a Condition - i.e. a Condition record or records -
in which
particular Data Relation Table fields are used to state when the Condition
applies. If the
Condition can Never be allowed to be met, or should be checked and met, then
such a
Condition is termed a 'Law'.
Hence the Data Relation Table can contain a) a description of the computer's
'body' in
terms of coordinates b) A Law that states 'You may never move any coordinate
of your body
inside the coordinates of the space occupied by any other object.'
In effect it will be seen that with suitable peripherals, a computer can be
made to
control a 'robot' with an extremely wide range of abilities, especially if it
is able to
communicate by radio. In effect it becomes possible for robots to do many
common tasks
and for one person to operate an unlimited number of robot bodies either
individually or in
consort as a remote army.
It will be noticed that the ability to relate Any data to Any other data is
the key method
and technology that makes the above possible.
MECHANICAL PERIPHERALS - CONTROL OF MOVEMENT
Any movement - for example walking - is made up of a number of other movements
that are themselves assemblies of Software Data Components, in this instance,
Movement
Data Components
The smallest movement - for example of a single muscle - can itself be broken
down
into its movement Data Components and these Components can be stated in terms
of the
Data Categories to which they belong. Stating the movement of a single muscle,
or the
activity of an electric motor that is doing the same work as a muscle, in
these terms gives:
Life, Sense (Positive, negative) In a muscle, expansion in or contraction,
In a motor direction of rotation
Time, Start, Time Stop . The duration of the of the Action
293
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Space: Distance The Distance to be covered in the time
In a muscle the amount of shorting or
lengthening
In a motor, the number of rotations
Energy The amount of power to be applied
Matter The designation of the material thing - a muscle
or a motor to which the Data Relation Table
record applies.
Hence, a muscle movement, or the activity of an electric motor serving the
function of
a muscle, can be stated in terms of Data Relation Table records. When
incorporated in a
Software Module, any field of any record by modified by any other record type.
For example,
the Power field in the Energy Data Category in the can be an initial setting,
and a further
Percentage Record combined with a Timing Record can state how the power is to
be
modified with time. A Transition record can state how the nature of the
transition between
one power setting and another - linear, logarithmic etc. Similar records can
apply to the
Distance Parameter. Alternatively:
A Timing record can use all fields to set each transition time that occurs in
any other
record in the set.
A Percentage record can be used to enlarge or contract those transition times
A Speed record can control Rotation speed
A Power record can control the power to be applied
Condition records and Percentage records can be used with any of the above.
For
example, if a Condition record states that if speed falls, Power is to be
increased to maintain
speed, and vice versa - if speed rises, power is to be reduced. The effect is
that only the
power needed to perform given work is applied.
Any of these can be grouped and then, as previously described, related to a
name
such as 'Walk' or 'Pick up' (an object).
Stating a complex movement such as 'Walk' in Data Relation Table terms would
be a
laborious process. However:
A robot body can be created in which various motors serve to perform the
individual
movements of which another body-for example, a human body is capable.
Following the Parallelism method, a body suit can be created for a human
operator
that supplies one distance measurement for the length of the movement that is
the length to
be produced by the robot body.
A Software Module is created that records the length and time parameters as
Data
Relation Table records sets, one for each motor.
294
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
These Data Relation Table records, are used by another Software Module that
uses
records similar to the above to supply the necessary parameters to the robot
body, and at the
same time record the power found to be desirable.
The resulting Data Relation Table records can be named with a suitable name
such as
'Walk.'
In this manner, a robot body can be made to mimic the movement of a human
operator inside such a movement transmission suit. This method enables a
movement to be
recorded in terms of Data Relation Table records without the necessity of
manually stating
each parameter. Movements such as 'Walk' can be strung together in the manner
previously
described for any Software Module and named, and eventually result in a robot
being able to
execute commands such as "Make me some coffee.'
The added advantage of the Any-to-Any machine in this respect is that,
especially if
Data Relation Tables in different locations are connected together in any of
the manners
described, then only one Data Relation Table should be 'taught' in this
manner. Something
that is 'learned' by one Data Relation Table can be known to other Data
Relation Tables in
Any other locations in the time it takes to transmit the records. When
different physical
bodies are constructed to the same motorization plan but with different
Components with
different ratings, a calibration process producing percentage modifications in
the parameters
recorded in Data Relation Table records can enable the same movement = the
same
Software Modules - to be Executed in different sized bodies, from
microscopically small, to
gigantically large.
By using the 'Emotion' field that is present in each Data Relation Table
record,
movements can be modified - for example facial 'muscle' motor movement - with
variations
in Data Relation Table parameter records of the types above, and related to
the names of
different emotions. Conditions that are detected by Condition Records~can be
related to the
same emotion names. Through the Any-to-Any machine enabling any data to be
related to
any other data, the detection of a Condition can result in the robot body
'smiling', 'crying' or
'laughing'.
75) Methods Enabling Some Confusions to be Removed for New Users; State
of the art "files' and 'directories'
It should be noticed that in this Any-to-Any machine, there is no such thing
for the user
as a 'File' as this the term is used in state of the art software. For the
user, File names as
used in the state of the art, do not exist, nor to disk locations of files in
terms of disk
pathways. As far as a programmer is concerned, the file name of the database
itself exists,
and larger Data Class entries that it is not practical to keep in the database
can exist as disk
files, but when this is so, a Software Module called 'Disk It' assigns the
next available number
295
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
and saves the file with that number. In the Any-to-Any machine, files are
assigned number
'names' and not alphabetic character names, as such numbers can then be
manipulated in
the normal framework of the rest of the Any-to-Any machine and 'the Data
Relation Table in
particular. Similarly, disks are assigned numbers not letters and, if desired,
a conversion
table is created to achieve this. If the programmer requires names, he can
create a User
Equivalency Table, showing in one field the number of the file on disk and in
another any
name he wants to give the file and write the 'Disk It' Software Module to
update this User
Equivalency Table and prompt him for a file name.
The fact that a reference number is a reference number to a value that is held
as a
disk file is indicated by the second digit in every reference number (the
first digit is reserved
for stringing numbers together). Accessing such a reference activates a
Software Module
called 'Undisk It' which looks up the reference number in the Disk Location
Data Class Table
in which is recorded the Location and number of the disk on which that file is
stored.
As far as a user is concerned, the Any-to-Any machine eliminates the
distortion and
confusion and hence the problems introduced by the computer community by
misusing the
term 'file' to mean something different from the way the majority of the world
understands the
term. The term 'file' reverts to the use that vast majority of people in the
world are used to,
and means 'a collection of items with one or more names.'
A user can give Any name to Any item and can assign Any item to Any number of
files. 'Files' in this Any-to-Any machine are comparable to paper files - i.e.
they are a
grouping of items going under a common name for the group. As far as the user
is
concerned, Software Modules take care of storing Data transparently, just as a
secretary
takes care of the storage of data for her boss. Where exactly data is stored
on the disk, or
even on which disk, is no longer a problem the user should handle and is
comparable to the
fact that where a particular page on the Internet exists physically is of no
interest to the user.
The term 'Folder' in the Any-to-Any machine becomes synonymous with the term
'File'. The term 'Directory' is discarded as used in the state of the art, and
returns to its
widest use as 'Something that serves to direct, a guide, especially a book of
rules or
directions.'
The Any-to-Any machine method of removing these uses of the terms eliminates a
considerable source of problems for many users, and certainly for
inexperienced users and
particularly for low-education users. A Visual Interface can presents fists of
'File Names' but,
if using the method of the Any-to-Any machine, these are names of groups of
documents or
items. Individual items can be named by the user, just as he has previously
been forced to
name a file, however, he is no longer obliged to do so, as adequate means now
exist to
identify any item without requiring user to.understand what a computer file
is. The state of the
296
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
art use of the computer term 'a file' remains as a term to do with computer
storage mechanics
of interest to programmers.
Further, it should be noted that items such as a 'Letter' 'an Address Record'
are no
longer recorded in the manner that is customary in state of the art, but do
exist as names of
types of items that user can specify. This Any-to-Any machine treats such
items as
assemblies of Data Component values from one or more Data Classes and from one
or more
Data Relation Table records. It further treats them as assemblies that should
be correctly
displayed or output in correct spatial relationship to one another at output
time - whether the
output is to the screen, to a printer or elsewhere. The Data Class values
composing the item
0 are stored in their own fields in their own Data Class Tables or on disk.
The relationships
between the entries in Data Class Tables that are the Data Components of 'a
letter' or of 'an
address' are stored in the Data Relation Table. Whereas, in the state of the
art, 100 letters to
the same person will store his name and address 100 times, in the Any-to-Any
machine the
name and address is only ever stored once. But Anything can be related to that
one name
and address, including 100 letters. Thus although data is only ever stored
once, tens,
hundreds, millions or billions or unlimited relationships between that data
and Any other data
can be stored in the Data Relation Table. Hence, data storage requirements
that are present
in the state of the decrease, and this applies to software data - software -
also. However,
storage requirements for relationships - which, in the state of the art is
close to non-
existence, does increase.
76) Methods to Optimize the Any-to-Any machine
A considerable number of largely self-evident optimizations are possible with
the Any-
to-Any machine and will be apparent to those skilled in the state of the art.
However, the
most useful and effectiveness of these, will be a database constructed to
provide the few
services required by the Any-to-Any machine but provide them in such a manner
that they are
accomplished very rapidly. Additionally it will be beneficial if a specialized
tabular storage
mechanism is created, thereby removing the bulk of software in a state of the
art database
that is no longer needed, and the storage mechanism is provided with search
capabilities
using Software Modules. Other than this mention, optimizations are ignored in
this
description in order to keep the description as straightforward as possible.
77) Method to Visualize the Relationship between Data, Software and
Humans
The following is a verbal description of a visual model of the Any-to-Any
machine. The
Any-to-Any machine as a whole does not obey physical universe laws - data can
be related in
the Any-to-Any machine in a manner that data cannot be related in the physical
universe. For
example, physical universe laws - quantum physics statements apart - state
that the material
297
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
part of one object cannot occupy the same space as the any material part of
another object.
Thus the physical Empire Slate Building can not, at the same time occupy a
space that is
already occupied by the, Chrysler building; and any attempt to make two
physical objects
occupy the same space causes damage to one or both. However, the Any-to-Any
machine
does not obey these physical universe laws just as a human in his data
handling does not
obey them either. In the Any-to-Any machine, it can be stated that the Empire
State Building
and the Chrysler building do occupy the same space - the Any-to-Any machine
can obey
physical universe laws if required but does not intrinsically do so any more
than a human
does.
Because of this phenomenon, the visual model of the Any-to-Any machine cannot
readily by drawn on paper, but can best be visualized based on the following
description:
The result the methods of the Any-to-Any machine is to produce a data relation
machine that can be visualized as a structure that presents a cross section of
a borderless
cylinder and hence the borderless cylinder can extend infinitely and any one
point on its
circumference can be at any radius. This borderless cylinder can be further
visualized as
consisting in general of data that extends infinitely far back in time and
infinitely far forward in
time, so making an infinitely long, infinitely large borderless data space
extending backwards
and forwards through time. Threads - relations - potentially run through this
borderless mass
and potentially connect any one instance of any Data Component with any and
every other
instance of the same Data Component, and thereby potentially connect all data
assemblies of
which that Component is a member. Observing any one Data Component shows that
it is the
center of a structure of the same kind, where any one Data Component in that
further
structure has a threads relating it to all other instances of that sama Data
Component in the
previous structure. While the Data Components themselves do exist only a few
of the
possible relation 'threads' are visible. The relation 'threads' mostly appear
and disappear like
lighted filaments that wink on and off, under the control of logic - software
Modules - that
exist in an identical structure to the data structure described above and in
its same space.
Some threads exist for a time in the data structure and these are
relationships that the user
imposes and then wishes to keep, and therefore records.
Unlimited numbers of humans surround these structures and move in and out of
it and
through it at will. They are not constrained by time but can move backwards
and forwards in
time viewing all data from anywhere in the structure. These humans address
their orders to
the software structure and the software dynarnicalfy creates relationship
threads for an instant
of time or for a long time. The Data Components that the threads connect are
visible to the
human ordering the connection. Each thread shines in the color of the human
who ordered
its creation; and any human can ask for, be shown and use any thread created
by another.
298
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Threads, other than those that can exist between the same Data Component and
between
the same types of Data Components, can be created by searching for particular
patterns' of
Data Components. The software itself can - when the processor is not otherwise
occupied -
look through the data structure for any of these that exist, and discover by
itself those
patterns that no human has so far discovered. Equally, finding no permanent
thread exists
showing that a human has recorded a similar pattern of Data Components,
software can look
for other instances of the same pattern. It can also alert any human who has
notified it that
he wants to know about any thread discovered by another, including by the
software,
-containing any particular Data Component or any particular pattern of Data
Components in
any one or more data structures.
A human or the software can use any thread, and the human can change any
thread
and thereby make the changed thread his own, or, he or the software can create
a thread that
has not existed before. Anyone of adequate competence in the software
structure can add to
it at any time by creating relation threads between software Data Components
and adding
any software Components required to create the relationship thread he wishes
to create. If
part of the software structure is a Language Processor, the human can address
the software
directly, but if not, then each human has a control panel that is wired to
each of the software
structures and causes them to act. The software structure holds in the data
structure the
information needed to control the appearance and activity of each human's
control panel and
also of his screen and other outputs he uses.
Both structures consist only of numbers and examination of any one area of
either
structure shows it is composed of numbers that are the numbers of Data
Components. Each
type of Component than can be held in its own bottomless bins off to one side,
or in the data
structure itself, if the holding structure - a database in the implementation
described - permits
any actual value to be held in any field.
An alternative statement of the difference between state of the art software
and the
Any-to-Any machine, and hence of the Any-to-Any machine's advantages, is that
in
conventional software most relationships between data are hard-wired by the
programmer,
and therefore only those relationships that have been hard wired are available
for the user.
All relationships that actually do exist - all the threads that could exist -
are not seen and
used by any user because, all possible threads that could exist have been
excluded by the
simple fact that a programmer has not programmed that thread. In the Any-to-
Any machine
the programmer hard-wires software that has the task of creating and
destroying - at the
demand of the user - any thread the user wants - i.e. relationships between
data.
This visual summary description of the Any-to-Any machine shows the following
additional and novel advantages of the Any-to-Any machine.
299
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
In the state of the art, the ideal of the paperless office has proven an
elusive objective
and a problem of its own, principally through the difficulty of finding the
required data quickly
using state of the art methods. This results in a degree of disinterest in
entering non-
electronic data into a computer through scanners, as the data often becomes
more difficult to
find and use than if the data remains in paper form. Additionally it has been
advantageous to
keep data in multiple locations in a network, and disadvantageous to keep data
in a central
place as this increases the effort required from the individual to record it
and also increases
his difficulty of locating data -without presenting any compensating
advantage.
The Any-to-Any machine removes these problems. Physical storage locations are
no
longer a problem for the user, any more than the physical storage locations of
Internet data
are a problem for him. Data can now be found more easily with a computer than
it can be
found without one. The further advantage exists for the user that now
correfations between
data are found simply by asking if they exist, and further, he can now view
any data in any
manner and output any data in any manner and can also view data from the
viewpoint of any
recorded time, or any recorded location, or any recorded action.
78) Advantages Arising from the Any-to-Any Construction Method of the Any-
to-Any machine.
The visualization described above also shows particular advantages for
management
and for success of group activity. Successes and failures in the activities of
a group are
virtually predictable in advance, but in reality, many predictions fail
(discouraging methodical
prediction) and hence, the activities resulting from those predictions fail
also. Management
that enters predictions into software created with the Any-to-Any machine can
of course see
whether those predictions prove correct or not. However, in the state of the
art it is difficult -
and a problem - for management to determine precisely why a prediction failed
and hence,
improve predictions - and thereby group success - in the future. The process
is difficult
because all data is not in one place and even if it is, searching for
relations in it - i.e.
relations of data that did indeed predict the failure or the success - is
extremely difficult as
data stored in one place or manner cannot be related to data stored in another
place or in
another file format. Further, because each data has its own format, data
cannot be related at
all without specialized data mining techniques that prevent relations being
found in real time.
The process is made even more difficult because, as described above, the
paperless office is
a chimera and hence, key data is often not in the computer at all, but may be
sitting in paper
letters or paper files in somebody's desk drawer. The Any-to-Any machine
solves these
problems because all relations between data that exist can be found. Because
all data in the
Any-to-Any machine is related to time, the Any-to-Any machine enables
management to view
data from the viewpoint of any past time (prior to date X') and from any
further time. Starting
300
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
from a past time, management can search for relations between data that
existed but were
not perceived at the previous time, or were perceived but thought to be of no
consequence.
For example, management can issue a command such as 'Give me all changes made
to
sales procedures prior to Date X'
The further unique advantage of the Any-to-Any machine to the task of managing
organizations, is that in any organization such as a company, all failures can
be attributed to
only two sources 1) either to action the company failed to take when it should
have taken
action, or 2) to action it did take that it should not have taken. Successes
that subsequently
collapse are frequently often due to someone in the organization changing a
procedure that
worked and was at the root of the success, without realizing, and sometimes
even when
realizing, the negative repercussions that the change would cause in overall
performance.
Such changes,are also difficult to find in the state of the art. However,
intelligently structured
queries such as: 'Give me all changes made to sales procedures prior to Date
X' are likely to
find such instances also, and being brought to light, can be corrected.
Finally, as will be described in the Detailed Description, the Any-to-Any
machine
enables management to integrate planning and track planning Execution as
simply one part
of overall data. In addition to enabling management to be provided with
accurate real-time
financial data - something which is of immense value to management - the Any-
to-Any
machine enables any relationship between data to be found, and by enabling it
to be found,
also enables the numbers of anything that exist in the relationship to be
counted, Hence, it
will be described how the Any-to-Any machine enables management to have a real
time
overview of organization function by providing real-time statistics of any
functioning desired by
management, much as a real-time view of functioning is given by the dials in a
power station
control room. This has the advantage of enabling management to avoid many of
the
organizational Chernobyls that abound in today's businesses.
Throughout this summary, mention has been made of alternative methods by which
a
given objective can be reached using the Any-to-Any machine. A feature and
novel
advantage of the Any-to-Any machine is that:
1. There is no particular preference for one method using the Any-to-Any
machine over another, since one method may suit a particular purpose or
application
better than another, and
2. Data that is handled with one method in one application can be
converted automatically - using suitable Converter Software Modules - and then
used
interchangeably with data that was handled with the other method.
The Any-to-Any coding system of life described in the background consists of 1
)
Components, i.e, the four bases that can fit together on an Any-to-Any basis.
The Any-to-
301
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Any machine equivalent of this is Data Components. Further, the life system
consists of a
method by which the four bases can fit together on an Any-to-Any basis. The
Any-to-Any
machine equivalent of this is Data Relation Tables. The Any-to-Any life coding
system
generates an almost unimaginable array of different machines - life forms -
using different
methods, all of which, however, are based on the same Any-to-Any system at
their root.
Further, all life forms fit together as a homogeneous whole. Similarly, the
Any-to-Any
machine Components and methods of functioning can be used with any method that
produces a desirable software 'life form' - provided only that the Any-to-Any
methods that are
the root of the Any-to-Any machine are followed. Similarly, to the result with
the Any-to-Any
life coding system, all such software 'life forms' fit together as a
homogeneous whole.
Because of the parallelism between the relations of All software Module in
Data
Relation Table form, and All data which is also in Data Relation Table form,
both of which are
stored as Data Components that can be assembled on an Any-to-Any basis, the
following
several unique and novel advantages arise that between them solve different
problems in the
state of the art:
1. The Any-to-Any machine enables a computer to identify items based on
a human's Specification of the item and thereby solves the problems, in the
state of
the art, caused by the inability of a computer to identify a an item based on
a human's
Specification of the item.
2. The Any-to-Any machine enables a computer to store a user's orders
and to store them in relation to Execution, by providing the Data Relation
Table as a
place to store orders. The Any-to-Any machine thereby solves the problems, in
the
state of the art, caused by the absence of anywhere to store user orders in a
computer and to store them in relation to Execution by the computer.
3. The Any-to-Any machine, by providing the Data Relation Table, enables
a computer to allow a human to record easily any Conditions for an Execution
to
occur, and thereby solves the problems, in the state of the art, caused by the
absence
of any way for a human to easily state Conditions to a computer for an
Execution to
occur.
4. The Any-to-Any machine enables a computer to record all Executions -
in the Data Relation Table - and thereby solves the problems, in the state of
the art,
caused by the inability and failure of a computer to record all Executions.
5. The Any-to-Any machine enables a computer to alert the user to any
new item that matches his Specification, thereby solving the problems, in the
state of
the art, caused by the inability of a computer to alert the user to any new
item that
matches his Specification.
302
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
6. The Any-to-Any machine enables a human to string together, in any
order, any Execution with any Specification and for that Execution to execute
based
on any Condition. The Any-to-Any machine thereby solves the problems, in the
state
of the art, caused by the inability of a computer to allow a human to string
together, in
any order, any Execution with any Specification and for that Execution to
execute
based on any Condition.
7. The Any-to-Any machine enables a human to construct in it,
Specifications using an Any-to-Any construction system and thereby solves the
_
problems, in the state of the art, caused by the inability of a computer to
allow a
human to construct in it, Specifications using an Any-to-Any construction
system.
8. The Any-to-Any machine enables a computer to determine whether any
Specification can be executed or not and thereby solves the problems, in the
state of
the art, caused by the inability of a computer to determine whether any
Specification
can be executed or not.
9. The Any-to-Any machine enables a computer to lay aside Execution
while a Specification is completed or corrected and thereby solves the
problems, in the
state of the art, caused by the inability of a computer to lay aside Execution
while a
Specification is completed or corrected.
10. The Any-to-Any machine enables a computer to do Dynamic Execution
Interaction - to interact with a user attempting to do or find something by
showing him
what is done or found so far. The Any-to-Any machine thereby solves the
problems,
in the state of the art, caused by the inability of a computer do Dynamic
Execution
Interaction - to interact with a user attempting to do or find something by
showing him
what is done or found so far.
11. The Any-to-Any machine enables a computer to Return nearest Truth
and thereby solves the problems, in the state of the art, caused by the
inability of a
computer to Return Nearest Truth.
12. The Any-to-Any machine enables a computer to have and to use
Execution Related memory and thereby solves the problems, in the state of the
art,
caused by the inability of a computer to have and to use Execution Related
Memory.
13. The Any-to-Any machine enables a computer to accept data and to act
in such a manner that its only apparent limits are physical limits, solves the
problems,
in the state of the art, caused by the inability of a computer to act and
accept data and
to act in such a manner that its only apparent limits are physical limits.
303
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
14. The Any-to-Any machine enables a computer to act in an Any-to-Any
manner and thereby solves the problems, in the state of the art, caused by the
computer acting in a One-to-Many manner
In addition to solving the above problems in the state of the art described in
the
Background to the Any-to-Any machine, the Any-to-Any machine also enables
other novel
and unique advantages that do not exist in the state of the art, and whose
absence causes
various problems
15. Any Software Module can act on Any data. The state of the art
problem of incompatibility between data produced by different software types
within a
software package no longer exists.
16. Any Software Module is intrinsically compatible with any other Module,
and the question of 'integration' - a major problem in the state of the art -
does not
arise.
17. Any Condition, Any View, Any Field Name, Any Prompt, Any Hefp, and
Any error Handling can be used with Any data. (Again, whether it is sensible
to do so
or not, is up to the software builder, but the programmer and the user have
that
freedom if they requires it). This provides a programmer and the user with an
unprecedented flexibility in constructing applications, a flexibility whose
absence is a
problem for programmers and users in the state of the art.
18. Any number of Any of these can be used in Any combination. A
programmer may chose to use one Condition record, or 2 or a 100 for a given
Execution. He may choose to use one Help Record with one Help text per field,
or 2
or 100, in steps of increasing level of detail for different age groups and
experiences.
Again, this provides a programmer with unprecedented flexibility.
19. Any new type of Software Module record can be created to suite the
purpose with the methods of the Any-to-Any machine to achieve any task of
which
software is capable. Although seven types of basic Software Module record are
listed,
a programmer may create Any type of Module record - or data record - that
suits his
purpose for a particular application. For example, if he is creating a
teaching program,
he may want to create a number of Condition records that he names as a
Condition
Record Sub-type of 'Student Response' each of which holds a particular
potential
response from a student to a test question. His Software Module Execution
record
could display test questions using Any number of Any 'Prompt' records, and
then
compare what the student does or says to Any Number of Student Response
Records, and then use the appropriate Director record that is a Companion
record to
the Student Response Record to activate Any other Module based on the
student's
304
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
response. He could create other types of records to count student responses,
and
then use the percentage of correct responses to choose the Help Record, and/or
Prompt records to use. As a further example, if a programmer wishes to use
Multiple
levels of a Help record he can create a new type of Software Module Execution
record
which he could call a 'Help Manager' to manage the different Help records. In
effect,
the software house that can be built with the system of the Any-to-Any machine
is
limited only by the imagination of the builder. The only real risk arises
through
different programmers assigning the same identifying number to a specific type
and
Name of record (provision exists for two fields in the Administrative area of
each Data
Relation Table record for such identifying numbers). There is no solution
internal to
the Any-to-Any machine that can handle this, and the most practical handling
is an
international registry similar to the UPC barcode system, where anyone who
wants an
identifying number can be assigned one. Again, this provides a programmer with
unprecedented flexibility.
20. State of the art software has considerable problems with correcting
errors due to its almost unimaginable complexity. For example, one major
operating
system consists of 40 million lines of code distributed over some 4000 files -
each of
which averages 150 pages - in which each line is a part of the code - i.e. a
total of
600,000 pages. A review showed some 3,000 errors requiring correction in just
part
of the code. Because of the One-to-Many construction philosophy - in this case
one
operating system - many functions are rigidly related to one another by
programming:
a. Finding an error is a problem
b. Correcting any error may cause untold other problems as it is
difficult to predict how one correction may affect the remaining code; thus
even
the smallest correction requires extensive testing
c. Updating users with a correction is a problem that requires
extremely large files to be transmitted at considerable expense for even the
smallest correction. Consequently, corrections are not frequent and this
causes further problems to users.
The Any-to-Any construction philosophy gives the unique and novel
advantages that:
a. Any error can be traced relatively easily to an individual field and
Field Logic in an individual Data Relation Table record field, or to an
individual
field in one of the records used by that logic.
305
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
b. The error in the field can be corrected without that correction
affecting anything else, other than potentially its own Controller Logic,
which
can also be corrected easily.
c. Correcting the error only requires transmitting by Internet the
few lines of corrected code - perhaps 100 or 200 a lines of code.
d. Corrections can occur dynamically without a system re-start.
The Any-to-Any machine is an Unlimited, Any-to-Any, data manipulation machine
that
is not intrinsically hierarchical and thereby enables software built with the
Any-to-Any machine
method to manipulate data in the same manner as a human manipulates that data
with all the
concomitant advantages of doing so. In so doing, the Any-to-Any machine solves
the
problems that are caused by the One-to-Many construction methods of state of
the art
software.
1. METHODS TO ENABLE A COMPUTER TO ACT AS AN ANY-TO-ANY
MACHINE: GENERAL CONSTRUCTION METHODS
~ Key Teachings of the Any-to-Any machine
1. General Principles and Methods for Constructing an Any-to-Any Data Machine
- Components
The word 'machine' supposes that there is a construction that causes change on
something that is the subject of that change. A computer, in its functioning,
only deals with
data in various forms, and nothing else. A 'Data Machine' or 'data engine' in
relation to a
computer then, is a construction such that software causes changes to occur on
data.
Hence, the two principle parts of a the Any-to-Any machine, which is a Data
Machine
construction method, are:
1. The structures for the recording and storage of data supplied, in one
manner or another by humans, who either supply the data directly, or create
mechanisms that supply data according to their order. This structure is
composed of
the Data Relation Table and miniaturized versions of Data Relation Tables
named
Data Class Tables and Data Assembly Tables. Humans supply data, or cause data
to
be supplied, in the form of Components and hence, the data structure stores
Components. (It will be shown that while words do not meet the definition of a
Component when words are stated in isolation, humans have a manner of using
words
that transforms them into Components in actual use).
2. Software that acts on the data in the data.
In this description, the word 'Data Engine' is defined as being the assembly
consisting
of (1 ) and (2) above.
306
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
It is axiomatic, that if data is to be stored as Components, then data should
first be
made into Component form.
In order for a computer to manipulate data in the same manner that one human
expects and anticipates another human will manipulate that same data, the
computer should
manipulate data in an Any-to-Any manner that is not intrinsically hierarchical
and is
intrinsically unlimited. The fundamental method of the Any-to-Any machine that
enables this
objective to be achieved is to disassemble all data ('data' includes the data
that makes up
software also) into separate Components, meeting the definition of a
'Component', and to
store the resulting Components in such a manner that the Components are not
intrinsically
related to one another. Because Components are not intrinsically related to
one another,
Components can be assembled in any relationship that is useful. A phenomenon
that is
applicable to Data Components stored in a computer but is not applicable to
physical
Components such as buts and bolts, is that, in a computer, it is not necessary
to have
multiple examples of a given Component, but instead it is possible to use
copies of a
Component. Further, if the copy of a given Component is in the form of a
reference to that
Component, then a correction to one single Component has the effect of
correcting all
instances of that Component, each of which exist as references to the
Component itself.
In the case of data, the basic Component is not a word (which has multiple
meanings
and so is not a Component) but a single meaning of that word. This method, and
the systems
and methods invented to implement it, enable copies of the Components to be
assembled in
the similar and parallel manner to the manner in which a human assembles them.
(Observably, a human can relate any number of any one meaning to any number of
any other
meaning, in a manner that is not intrinsically hierarchical and is
intrinsically unlimited). A
computer that can record the same Data Component assemblies that a human can
assemble,
is intrinsically capable - with suitable mechanisms - to record data as a
human specifies it.
As described in the summary, problems arise in the state of the art, not
through the
inability to write Executions in software that copy the Executions a human
would perform, but
in the inability to relate such Executions both to an unlimited number of
human-stated
Conditions under which the human specifies that the Execution is to occur, and
in the ability
to relate these to an equally unlimited number of Specifications of items on
which the
Execution is to be performed. The method of the Any-to-Any machine, by
enabling any
meaning Component to be assembled with any other meaning Component, enables
any
Condition and any Specification given by a human for an Execution, to be
recorded. Since
such Condition and Specification assemblies are not intrinsically related to
one another by the
Any-to-Any machine methods - for example by a hierarchy in which they occur -
any
Condition can then be assembled with Any Execution and these can be further
assembled
307
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
with any Specification. With suitable mechanisms that will be described, this
assembly can
be performed when the human orders it. In effect, the computer can now 'track
with' the
human = i.e. emulate the results of a human's handling of the same data.
While this teaching is described by describing the Any-to-Any machine methods
to
enable a computer to emulate human data manipulation, the exact same method
can enable
a computer to emulate any other data manipulation system also, since any data
system at all
can be created, and hence emulated, by assembly of Components that are true
Data
Components. .
The Any-to-Any machine consists of two closely parallel systems:
1. Data Storage Structures for recording all and any data - the Data
Relation Table, Data Assembly Tables and Data Classes tables. This structure
is
closely paralleled by:
2. The software system. Software is simply a type of data that, when
loaded into memory and executed, has a particular class of effects. Since
recorded
software is data also, it can also be recorded in the same Data Storage
Structures as
the data on which it is to act.
The result is that a strict and close parallelism can be maintained between
the data
and the software, and this is a parallelism that is similar to that between a
transistor, that can
exist in any of two states (on or off), that is controlled by binary notation
that can exist in any
of two states (zero or one). In the case of the Any-to-Any machine, a given
data type can
exist in any state, but then, the software that acts on that data can also be
written to act on
any state. Thus the Any-to-Any machine can also be described as a transistor
(data storage
structure) that can exist not in two states but in any state and a control
system to control it
(software) that can also exist in any matching state.
The fundamental requirements to create an Any-to-Any machine are defined as:
Any number of Anything should be able to be directly related and able to be
unrelated to Any number of Anything else, in a manner that is not
intrinsically
hierarchical but which is intrinsically unlimited.
A computer only handles data, represented by electronic impulses, and hence
the
creation of an Any-to-Any data manipulation machine in a computer should meet
the following
definition:
Any number of any Data Component should be able to be related to any
number of any other Data Component in a manner that is not intrinsically
hierarchical
and is intrinsically unlimited.
The corollary teachings to the above are:
308
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The ability to relate Any number of Anything, has the corollary that the
number or
quantity of that thing that is related to Any other can also be zero - in
other words, a specific
thing or Data Component is not automatically related to any other. For that to
be possible,
one thing - one Data Component - can not have a fixed relationship with any
other thing or
Data Component whatsoever. Obviously, if thing A has a fixed relationship to
thing B, then if
B is used, A is used also and it is no longer possible the quantity of A to be
zero, as if B is
present, A should be present also.
Hence, it is an desirable Any-to-Any machine to ensure an Any-to-Any machine
is
created, to implement the above definitions in their purest-possible form and
to ensure that no
smallest part from which the machine is built is built with even one single
fixed relationship
with any other part, for as soon as any part is given a fixed relationship, it
is no longer
possible to relate that part to Any other part, and the machine is no longer a
fully Any-to-Any
machine.
Further basic teachings are:
1. Any relationships that are established, should also be able to be
destroyed, without limit.
2. Any number of anything that is visible to the user, or used by the user,
should be able to directly related, or-unrelated, by the user simply by
ordering the
relationship to exist or to be destroyed.
3. No intermediate step, other than supply of the minimum data needed
for the Execution of an order, may ever be required of a user in order for an
Execution
to occur, because if it is so required, a fixed relationship has been
established that is
hierarchical, and the machine is longer an non-hierarchical, Any-to-Any
machine.
4. Any relationships that are established between parts in order to perform
a specific Execution should be able to be destroyed, or changed or exchanged
with
another part of the same type, without affecting any other part.
5. The freedom to Relate Any Number of Anything to Any number of
Anything else, implies the corollary freedom not to relate Any number of
Anything to
Any number of Anything else.
6. Hence, in an Any-to-Any machine, restrictions are created by specifying
Any number of Anything that may NOT be related to Any number of Anything else
Where the characteristics of the mechanisms used to record the data structure
of the
Any-to-Any machine (Data Relation Table etc) itself imposes limits to which a
human is not
subject - for example, no more than X tables per database - logical mechanisms
need to be
created to join two or more such structures together logically, so that the
limit is effectively
removed. Failure to do this prevents the Any-to-Any machine from implementing
'intrinsically
309
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
unlimited' part of the definition of an Any-to-Any machine given above,
prevents the Any-to-
Any machine from emulating the 'intrinsically unlimited' part of the
definition of human Any-to-
Any data manipulation, hence, imposes limits, hence requiring the human to
learn those limits
with consequent difficulty of use, and hence, the resulting machine is unable
to fully emulate
human data manipulation.
- Method To Enable Software to be treated as Data Components
Stored software is treated simply as a specific type of data that is otherwise
subject to
the entirety of the methods of the Any-to-Any machine for storing data. In the
state of the art,
'a piece of software' is a complex structure containing numerous functions or
uses. Referring
to the definition of 'a component':
"The smallest part into which an item of data can be separated or
disassembled and still retain one - but no more than one - of its original
meanings or
uses".
In the case of software, a Software Data Component is therefore defined as:
"The smallest part into which an item of software can be separated or
disassembled and still retain one - but no more than one - of its original
functions".
For ease of reference, a 'Software Data Component" is termed "a Logic".
Existing software can either be disassembled into Logics, and then used in the
Any-to-
Any machine, or Logics can be written newly and used in the Any-to-Any
machine, and in
order to perform any function at all, at least a few lines of code are
required. It is these few
lines of code that perform a single function that is defined as 'a Logic.'
If existing software is disassembled, a point will eventually arrives at which
removing
further lines of code results in code that will do nothing at all. Hence, a
'Logic' is also a
number of lines of code, such that, if anything further is removed from the
code, the code is
unable to perform any useful function at all - i.e. it is no longer able to
manipulate anything.
Any Logic written to perform an action should not perform more than one
action, as
otherwise, the machine is no longer an Any-to-Any machine, because a fixed
relationship has
been established between two actions by writing them as a single block of code
- a 'Logic'
being also defined as
"A piece of code in a given computer language that performs one and only one
action"
Logics, each of which perform a single action, can subsequently be related to
one
another before use, using any of the methods of the Any-to-Any machine for
relating one
Component to another, so that any number of Logics, each of which perform only
one action,
can be assembled in any manner for a specific purpose. One typical way of
doing so is to
assemble Logics into a Field Logic that acts on a given type of data in a
given Data Relation
310
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Table field. Logics are assembled with one another, by assembling their
references. While
this stows the very first Execution of a given Logic assembly, once assembled,
it does not
have to be re-assembled each time it is used, only each time any one Logic is
changed. The.
advantage however, is that there is only ever one instance of each single
Logic, and a single
correction to that Logic corrects all instances of the use of that Logic).
- Method of Storing Data as Components Enables Construction and Location of
Accurate Specifications
In manipulating data, is. just as desirable to be able exclude ALL OF that
which does
not EXACTLY match that which is required, as it is include ALL OF that which
is exactly
required. As an illustration of this, if the language only contain a term for
'week' and did not
contain any terms to describe the smaller divisions of time in a week, one
human, wishing to
tell another to do something on what we know of as Tuesday, would be forced to
include all
the other days of the week as well. In other words, it would not be possible
to exclude the
time the human did not want. Equally, if the language did not contain any
terms at all for
numbers, only the terms 'ALL' or 'none' the human would simply have no method
to
communicate 'four Tuesdays'. He would be forced into communicating either ' a
week' - and
thereby not including all the Tuesdays he wanted - or 'all weeks' and thereby
including all the
Tuesdays he did not want. In these examples, words that comparable to
components are
considered not to exist, and the only form in which something is accessible is
effectively,
comparable to an assembly of components.
While these examples appear to be so completely ridiculous as to be absurd,
they
accurately reflect the daily situation in the state of the art. For example,
as previously stated,
a word, used in isolation is an assembly of Components the Components being
the different
meanings of the word 'letter' - such as a letter of an alphabetic, a letter as
in something sent
through the post etc. The word, used in isolation, is a Component Assembly.
Consequently,
when used in this manner - as an isolated word - in an Internet search for
example, it finds
every instance of the word 'letter' no matter which of its meaning Components
are in use.
Similarly to the example of the word 'week' given above, the search fails to
exclude the
particular Components of the word 'letter' that the person does not want, and
consequently
his search finds many items that are not the items he wants. Equally
similarly, since it is nor
normally possible to specify a number - i.e. to search one's computer for a
'four letters from
Joe in August' the user is forced to specify either all letters, or no
letters, and the example
that is absurd when applied to the language, is similarly absurd - yet
commonplace and the
norm - in the state of the art in software.
The key understanding and teaching then, is that, in the method of the Any-to-
Any
machine, data of all and every type, is disassembled into Components and
stored as
311
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Components, enables Components to be assembled together. An assembly of
Components
intrinsically consists of reference in some manner to the specific Components
that constitute
it. Because the specific Components constituting a Component assembly can be
identified,
any specific Component assembly can be both specified and hence found based on
the
particular Components it contains. Once a data assembly can be located based
on any
Component or Components it contains, it can be related to any other Component
or
Component Assembly containing that Component or a specific Component
combination.
Because any Component Assembly can be identified based on a single Component
or a
specific combination of Components, it is now possibly to identify exactly
that Component
assembly containing the specified Component or Component combination, and
exclude from
the identification any Component Assembly that does not contain that exact
component or
Component combination.
- Method for Assembling Components into Component Assemblies
Humans assemble Components using a specific method to do so. In effect humans
assemble Data Components by relating to them one other, most usually by
stating a spatial
relationship between the things to be related. (Oxford English Dictionary:
'Relate: To recount,
narrate, tell'). Stating the Components 'John' and 'Brown' one after the other
and one next to
the other, states and creates a relationship - i.e. a Component Assembly of
'John' and
'Brown.' Hence, if a data engine is to parallel a human's data manipulation,
the subject of
assembly of Components is the subject of creating relationships between
Components.
Hence a data engine, while there is no necessity for it to use the same method
as humans do
to create relationships, does need to produce the same result using its own
methods. Le. if
the human relates two Components 'John' and 'Brown' by stating them next to
one another,
then the data engine should also be able to create a relationship in its own
manner between
'John' and 'Brown' that mimics the relationship created by the human using
spatial methods,
and should be able to output the relationship in a manner that the human will
correctly
interpret the relationship - i.e. it should be able to spatially relate
Components at output time,
no matter what method it may use to record them. In fact, it does not appear
to be possible
to assemble anything, without creating a relationship between Components and
hence, the
subject of 'assembly' is the subject of creation of relationships.
Hence the subject of manipulation of data is the subject of creation of
relationships
between Components, their subsequent recording (in the case of a human
'knowing' or
remembering') and the manipulation of Components and Component Assemblies. In
the Any-
to-Any machine method, the human creates the relationships between Components
thereby
creating Component Assemblies, the Data Relation Table record Components and
312
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Component Assemblies, and the Any-to-Any machines software manipulates
Components
and Component assemblies.
Hence a first prime requirement is to disassemble data into Components,
including
disassembling human input so that it is in translated into Component form, but
a second
subject of equal importance is the subsequent manner of assembly of Components
into
Component Assemblies. If for example, all data is disassembled into
Components, and then
subsequently re-assembled only into a single entity, then the only choices
that can exist are
either to use a single component or to use the single entity, which is not
useful. This
demonstrates that over-assembly-that is assembling 'too many' Components into
a single
entity - produces the same problem as failing to disassemble data in the first
place, namely,
the individual Component Assemblies comprising the 'aver-assembled' entity can
not be
accessed or used without also accessing or using the remainder of the assembly
with which it
is 'over-assembled'. Over-assembly of Components defines the situation in
state of the art
software, where for example, a specific Component Assembly such as code that
makes text
bold, is assembled into a piece of software such as a 'Word processor'
containing several
hundred other Component Assemblies. Because the 'Bold' code has been over-
assembled in
a Component Assembly termed a 'Word Processor' it can now no longer be
accessed and
used individually, for example to make a piece of text bold in a database for
example, without
also accessing and activating the entirety of the 'word processor' Component
Assembly.
Consequently, code to make text bold should be re-written for the database,
and for every
other application where is may be required to make text bold. Since, in
effect, every ability is
required in every application, code to do each specific action should be re-
written as many
times as there are applications, and this manifests itself in state of the art
'office' applications
where the separate packages included in the 'office' either duplicate one
another's functions,
or take complex steps to 'borrow' or use code from another part of the
package.
Hence it is desirable to define what should constitute a separate assembly of
Components.
Referring to the boss-secretary model, it can be understood that humans, in
handling
data, assemble any number of any one Component meaning with any number of any
other
Component meaning so that the resulting Component Assembly is useful, and
'usefulness' is
the criteria of what Component Assemblies should be available in data engine,
out of all
Component Assemblies that are possible.
As an example, the word 'John' - which, on its own is a symbol for the package
of
understanding that is 'John' - and the word 'Brown' - which is the symbol for
another package
of understanding - are assembled together to create 'John Brown'. This
assembly is useful,
as it now designates all John Browns, and these are a distinct group and may
need to be
313
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
handled by the human as a group ' send any e-mail to everyone we know called
John Brown.'
The 'John Brown' assembly may then be further assembled as 'John Brown,
employee' and
this now designates a particular John Brown and is also useful by adding the
Components
'employee'. Note however, that not every possible Component assembly is
useful. For
example 'John Brown %+*//~\\\433##' is not very likely ever to be a useful
Component
Assembly. Under normal circumstances, adding '%+*///1\\\433##' is not, of
itself, useful and
does not designate anything more than was designated by the component Assembly
'John
Brown'.
Other data may also be assembled as another Component Assembly, for example:
'Jill Brown, employee' and this too is useful. Subsequently the word
'employee' may be used
in a further Assembly 'The employees are going on vacation.' 'Employee' in the
above
instances is_ used as a Component, and because it is itself related to the
Component
Assemblies 'John Brown' and 'Jill Green', the Component Assembly 'are going on
vacation' is
related to 'John Brown' and 'Jill Green' through their common relationship to
with the
Component 'employee.'
This demonstrated that the criteria for a Component Assembly is as follows and
is the
reciprocal or opposite side of the coin to the definition of a Component:
"One or more Components that has a specific relationship one or more other
Components that has more than one useful meaning or more than one use".
It should be noted that, when the user gives data to the computer, the user
creates his
own Component Assemblies, and it is only preferable for the software to
identify these as
Component Assemblies, and store them appropriately. In the case of software
however, the
first stages of Component Assembly cannot be performed by a normal user and
therefore
should be performed for him by a specialist, namely a programmer.
Component Assemblies generally can be of two types:
1. Component Assemblies where the relationship of Components are fixed by
someone other than the user - for example by a programmer - in such a manner
that the
relationship between Components or Component Assemblies is not accessible to
the
user, or which cannot be changed by the user in a single step. Such a
relationship is a
fixed relationship as far as the user is concerned, because he is effectively
unable to
change it.
2. Component Assemblies where the relationship of Components are not fixed by
someone other than the user, and the relationship between Components or
Component
Assemblies can be created or changed by the user in a single step. In this
case, the user
is free to establish the relationships he wishes to establish, and thereby
create the
Component Assemblies he wishes to create
314
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
By extension, Software Component Assemblies - i.e. assemblies of Logics, or
Component Assemblies chat are themselves composed of Component Assemblies that
are
composed of Logics - can also be of two types.
1. Software Component Assemblies where the relationship of Components or
Component Assemblies are fixed by someone other than the user - for example by
a
programmer - by writing specific code as a block, or by relating specific
blocks of code to
one another in a such manner that the result is inaccessible to the user, or
cannot be
changed by the user in a single step. Such Component Assemblies in fact One-to-
Many
machines, in that the relationship of one thing to another or (more than one
others, i.e.
many) has been created by someone. In this case, the relationship is a fixed
relationship
as far as the user is concerned, because he is effectively unable to change
it. An
example of such a fixed relationship One-to-Many machine Software Component
Assembly, is a word processor where one software package (i.e. One) has had a
fixed
relation created between itself and several hundred functions (i.e. Many). The
user
cannot take one of those Component Assemblies - for example, a Component
Assembly
making text Bold, and use it elsewhere on text outside that word processor's
files.
2. Software Component Assemblies where the relationship of Components or
Component Assemblies is not fixed by the programmer and is accessible to the
user, and
which can be changed by the user in a single step. An example of this would be
a specific
assembly of code that makes text bold, which has not had any fixed
relationship created
to between it and any other Software Component Assembly. Because it has no
fixed
relationship to other Component assemblies, the user can himself accessed it
directly and
use it on any text he can find without being forced to simultaneously access
and use other
Component Assemblies at the same time. As this example demonstrates, it is not
sufficient that the Software Component Assembly - 'Bold' - is devoid of fixed
relationships, but the data on which it is to act - a piece of text - should
also be without
fixed relationships to other text. If that text had a fixed relationship
created by a
programmer to specific software package using its own file format, obviously,
the 'Bold'
code, although able to be accessed and used independently of any other
Software
Component Assembly, would be unable to produce a result.
This makes it clear that the fact that someone else has not created a fixed
relationship
between Data Assemblies, enables the user to create whatever Data Assembly he
wishes to -
create.
This demonstrates that ensuring that fixed relationships are not created that
do not
have to exist, is a desirable part of the method for creating an Any-to-Any
machine and an
Any-to-Any data engine.
315
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Hence it is preferable to define which Component Assembly relationships in
software
should be fixed (as far as the user is concerned in that they are not
accessible to him and can
to be changed by him even if accessible) and which Component Assembly
relationships
should not be fixed as far as the user concerned, in that he can access them,
control them,
and use them, without also thereby having to use any other Component Assembly
at the
same time.
SOFTWARE COMPONENT ASSEMBLY CRITERIA
A software Module is defined as a Software Component Assembly such that:
'?he Smallest number of more than one Software Component assembled
together, that as an Assembly, performs a single action that is useful for the
user, and
that can be directly accessed and used by itself without also accessing
another
Software Component Assembly."
If a Software Component Assembly meets the following criteria, it is
classified as an
Over-Assembled Software Component Assembly and is not termed a 'Software
Module':
"A Software Component Assembly is over-Assembled, if it performs more than
one single function that is useful to the user, and the user cannot access it
or use it by
itself without also accessing its other functions) or without first accessing
another
Software Component Assembly."
As soon as a Software Component Assembly is over-assembled, the data engine
immediately ceases to be an Any-to-Any machine, and has become a One-to-Many
machine,
as a single useful Software Component Assembly can no longer be related to
(used with) Any
Condition and/or Any Specification. Hence, it is desirable not to use Over-
Assembled
Software Components and to use only Software Component Assemblies meeting the
definition of a Software Component Assembly as defined above.
Hence, a Software Data Component - a Logic - performs one action and one
action
only and that action may, or may not be useful buy itself.
A Software Module for example -:
1. Performs more than function (as it contains more than one Software
Component)
2. Performs functions that form one single action this is useful to whoever
the
user is.
3. Performs a single action that he may need to accesses directly without
accessing anything else at the same time.
Referring to the definition of a Software Component Assembly a 'word
processor' does
not meet the definition of a Software Module above and is not termed a
Software Module
because:
316
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
1. It performs more than a single action that is useful to the user
2. Each of the single actions it contains that are useful to the user can not
be
accessed without first accessing another Software component Assembly - the
word
processor itself.
An independent Software Module that makes text bold, for example, meets the
definition above and is termed a Software Module because:
1. It performs a single useful function that is useful to the user.
2. It can be accessed and used by itself without also accessing any other
Software Component Assembly.
Thus it will be seen that the prime criterion that defines a Component is one
of
usefulness. The smallest unit of user data that still retains one part of its
original meaning -
i.e. its original usefulness - is a User Data Component. Lines of code that
can perform a
single function - i.e. have one usefulness - are Software Data Components,
i.e. Logics. An
item of data that has no usefulness is not a Component. Note that data doss
not have to be
in the form of letters or numbers but can be in the form of electrical
impulses or in any form
that carries information of any kind.
Logics can be assembled into Software Modules using either Data Assembly
Tables
or Data Relation Table records or both in the manner that will be described in
due course.
'Software Modules' and are of two types, one of which is most useful to
programmers, and
one of which is most useful to normal users.
PROGRAMMER SOFTWARE MODULES
Programmer Software Modules are Software Modules that are capable of
performing
one manipulation of one type that is of use (primarily) to a programmer in his
work of creating
an application with the Any-to-Any machine, or in providing a service to the
application that
the user does not need to access directly. Examples of such Programmer
Software Modules
are the New Record Module that creates a new Data Relation Table record, and
the Can Do
Module that checks if a Software Module and a data Specification have matching
abilities -
i.e. it checks if one can operate on the other.
USER SOFTWARE MODULES
User Software Modules are Software Modules that perform one manipulation on
type
of data and are of interest to, and directly required or called by a user in
order to perform the
work he wishes to perform. Such User Software Modules often call a number of
Programmer
Software Modules - and potentially also other User Software Modules - in order
to carry out
the work ordered by the user. Examples of such User Software Modules are 'FAX'
- a
Software Module that handles all the manipulations involved in sending a fax,
and 'BOLD' - A
software Module that makes any text boldface. -
317
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Because each separate Software Module installed in an application meets the
definition above for a Software Module, can be separately and directly
accessed by the user,
and because it does not have any fixed relationship to anything else, it can
also be related by
the user to anything else he wishes to relate it to. As previously remarked,
all actions done by
a user consist of Conditions, Executions and Specifications that the user
relates to one
another. The absence of a fixed relationship of a User Software Module confers
on the user
the freedom to create the relations he wishes to create. Thus, for example, a
user can create
his own relationships as follows (items in boldface are considered to be the
names of User
Software Modules):
When I say 'Close Up', PRINT my schedule for tomorrow, SAVE all my work,
LOGOFF, and SHUTDOWN the screen:'
'When I say 'Close Up' is a Condition, and the remaining words not in boldface
are
Specifications for the Executions named - the Software Modules in boldface. In
effect then,
the words 'Close Up' are the name for a Software Module that the user has
created himself,
by relating specific Executions and Specifications, and the user is enabled to
'program' his
own computer.
When Software Modules are made up into Assemblies in this manner, they are
termed
'Module Assemblies'. A programmer may create such Module Assemblies from User
Software Modules as he considers useful, but in doing so, he should not do so
by creating a
fixed relationship between any User Software Module and another. The
relationship he
creates is one that the user can remove by directly ordering it to be removed,
and should
ensure that the User Software Module still meets the definition of a Software
Module after the
relationship has been created - i.e. it can still be accessed directly, and
separately, and can
still be used separately.
RELATING SOFTWARE COMPONENT ASSEMBLIES TO CONDITIONS AND SPECIFICATIONS
As described in the Summary, an Any-to-Any data engine needs to be able to
relate
Any Condition, to Any Execution and Any Specification.
If a particular Logic needs to be executed by more than one Software Component
Assembly and this function may, under any circumstances, need to be executed
with more
than one Condition, or with more than one Specification, one method is to make
that Logic
into its own specialist Software Component Assembly, so that other Software
Component
Assemblies can use the specialist Software Component Assembly to perform that
function.
Thus, if many Software Component Assemblies need, for example, to create a new
record in the storage structure, then a specialist Software Component Assembly
is created to
perform that function, and other Software Component Assemblies then use that
specialist
Software Component Assembly to open new records.
318
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Alternatively, when a number of Software Component Assemblies need to perform
a
single specific action - a specific Logic - on the basis of Conditions and
Specifications that
are stated externally to them, then the Logic concerned can be references as
part of a
Software Component Assembly. However, it is desirable that not more than a
single
instance should exist of the Logic itself, and all other instances should be
references to that
Logic.
METHOD TO ASSEMBLE SOFTWARE MODULES
It has been stated that, all Software Component Assemblies that are Software
Modules may be stored in the form of components and that the assembly
mechanisms such
as Data Assembly Tables and Data Relation Table records used to assemble them
contain
only references to the numbers of the Software components - i.e. Logics. This
should not be
taken to imply that on a user's computer, the actual assembly process is
performed each time
a Software Module is run - i.e. each time it is copied into memory for
Execution
A Software Module is provided to the user in the form of Data Relation Table
records,
Data Assembly Tables and Records, and a Data Class Table that stores the
Software Data
Components - i.e. the Logics.
1. 'Installing' the Software Module is the process of loading the Software
Module
over the Internet or from a disk, and copying it into the existing Data
Relation Table.
2. When the user runs the Software Module for the first time, the assembly
process laid out in the Data Assembly and Data Relation Table records is
performed and
the finished, assembled Software Module is stored either in the main Data
Relation Table,
or in a Software Data Relation Table, in its assembled form, ready for
immediate use.
3. Each Data Relation Table record has three Administration fields 'Last Use',
'Use Count' and 'Use Index.' The method for using these fields will be
explained in due
course, but their effect is to count the usage of each record, including
Software Module
Execution records. If the programmer takes advantage of this facility, he can
create a
Programmer Software Module that, during machine start, reviews these fields
for Software
Modules, and loads into memory as many Modules as possible within the memory
Space
the application programmer allocates, deciding which Modules to pre-load in
this manner
based on the value in the Use Index field.
4. If and when the application programmer discovers an error in some part of
his
application, then this would normally only trace to one part of a Specific
Module.
Correcting the part with the error can be done rapidly and soon after its
discovery and
then updated all applications only requires a few seconds download of the
corrected code.
This can be achieved by sending a e-mail addressed to the application itself,
which the
application, with a suitable Software Module, unpacks itself and re-runs the
assembly
319
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
process concerning that Software Module only during an idle moment. If the
error
concerns a Logic, that may be used in many Software Modules, then the Repair
Module,
knowing the reference number of the Logic concerned, can use the Data Relation
table
and Software Module Data Assembly Table to locate all instances of that Logic
in all
Software Modules in the machine, and run the assembly process just on those
Modules,
during idle time. Similarly, a Software Module encountering a code error,
instead of giving
the user unintelligible messages as is the state of the art practice, can
activate a Repair
Module with a suitable Token. The Repair Module can then use the Internet to
obtain a
replacement for the defective part, run the assembly, and continue, with no
more than
short delay for the user while the repair is performed, and without loosing
user data in the
process, as the given Execution would revert one step and then simply wait
while the
running repair was completed.
79) Method to Enable a Computer to Manipulate Meanings Rather than Words
All user data and all software data may be stored as User Data Components and
it is
therefore useful to establish precisely what a User Data Component is.
2. Teaching: Humans Manipulate Data In terms of the Meaning of the Data
In terms of a computer, the data it can store and manipulate consists of
numbers,
words, sounds, images and electronic pulses, all of which are stored and
manipulated - in the
state of the art - as binary statements. Some of these meet the definition of
a Data
Component and some do not, as follows:
Humans transmit data between one another - and hence, potentially between a
human and a computer - by transmitting symbols that represent meanings. The
effect of a
transmission of the symbols - most usually in the form of words - between
humans is that a
meaning is transmitted. The teaching of this Any-to-Any machine is that this
transmission is
strictly analogous to a transmission between fax machines or modems. The
transmission
itself can be viewed - for example on a oscilloscope in the case of a fax
machine or modem -
just as speech between humans can be 'viewed' by listening to it. The effect
of the fax
transmission is that document which was, and a still remains in location 1,
now appears also
in location 2. The actual document - a letter, for example - that was
transmitted by a fax or
modem is the equivalent of the meanings - the understanding - transmitted
between humans
using human speech in this analogy.
Words then, are symbols for meanings - understandings. When one human
transmits
a single word to another - for example, he transmits (speaks) the word
'Explosion' - the
human hearing that transmission has a certain understanding that was caused by
the
transmission. The word 'explosion' can be considered to be a symbol for two
meanings - i.e.
whatever it was that the transmitter meant, and whatever it was that the
receiver understood.
320
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Note that what was meant and what was understood are unlikely to be wholly
identical. But
the meaning intended to be transmitted and the understanding that was
generated by the
symbol transmission serve to identify something because of the principle that
they are 'more
similar to one another than they are similar to anything else in the whole
world'. This principle
'5 is termed the 'Similarity Principle'. The same Similarity Principle also
operates in a fax
transmission and results in a fax transmission being useful. The transmitted
letter and the
received letter are not identical. Apart from the fact that each of them
exists in a different
space - a different location - they both exist as pieces of matter - paper -
that, while the two
pieces of matter are similar, are not totally identical - they are not the
same piece of paper.
One bit of paper with one of the letters, is not the identical size, color,
thickness, and
variations of any of these to the other. However, the two letters are more
similar to one
another than they are to anything else in the world, i.e., they obey the
Similarity Principle, and
hence, the fax transmission serves a practical purpose. The situation with the
transmission of
the word 'explosion' is similar to the analogy of a fax. The two meanings in
the head of the
speaker and the head of the listener that result from the transmission of the
word 'explosion'
are more similar to one another than they are to anything else, and hence,
serve a practical
purpose - the Similarity Principle is operating to produce effective
communication.
The word 'meaning' as used in 'humans manipulate meanings' is intended to
represent whatever it is that exists in the head of a person that he intends
to transmit when he
makes a transmission of a symbol - i.e. a word - and also whatever it is that
exists in the
head of person as a result of receiving that transmission. Because any
transmission - such
as the transmission of the word 'explosion' - usually has the result that the
transmitted
meaning and the received meaning are more similar to one another than they are
to anything
else - they obey the Similarity Principle - the word 'meaning' is used here as
though it is
singular - one thing - when in fact, a word used in isolation usually has two
or more
meanings and can, when analyzed carefully, have many more meanings than are
found in
dictionaries, which tend to describe types of meanings for given words, rather
than complete
precise single meanings.
The Similarity Principle is also seen in Data Classes, where it is used as one
of the
primary methods used to determine the contents of a Data Class. In a Data
Class, a first
name is a first name because it is more similar to any other first name than
it is to anything
else. The similarity is provided one part of it's meaning - it's meaning
includes the concept
'first name.' Suppose that one human transmits to another a single word 'Joe'
and no other
word. Whatever the mechanism may be,' it is clear in the mind of the listener
that this work, in
addition to the transmitted meaning also has a second meaning, i.e. that it is
a first name.
This other, second meaning, that is not a detectable part of the transmission
of the one word
321
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
'Joe' is 'first name'. Hence, as far as a computer recording for 'Joe' is
concerned, the
complete recording is 'Joe & first name' and it is this hidden, or not very
visible second
meaning that is part of 'Joe' that provides the basis for Data Classes and
Data Classes
display the Similarity Principle. In the instance of a first name, it is true
that 'every first name
is more similar to any other first name than it is to anything else.'
The usefulness of Data Classes further derives from the fact that the values
in each
Data Class have abilities - things they can do and things it cannot do that
are peculiar to that
Data Class. An e-mail can be addressed to a person and/or to a matter entity
such as a fax
machine. But it cannot be addressed to other Data Categories. A fax cannot be
sent to
Wednesday as Wednesday has no physical body, hence has no location, and hence
cannot
either receive or read faxes. Because of these phenomenon, when a Language
Processor
receives input, the number of Data Classes to which a given input word can
apply is relatively
limited and hence, Data Classes are of use in processing input.
Humans manipulate data by manipulating meanings. If one human sees a
construction beam falling towards the head of another human, he may say the
single word
'Jump' in a loud voice and the other human will perform an Execution - a jump -
when he
hears the meaning symbol 'jump.' The same pair of humans can be sitting
together later
watching a horse jumping contest, perhaps a contest in which one of them has
placed money
on a specific horse, and the same human can say the single word 'Jump' with
the identical
intonation, expression and force he used previously. However, the other human
will not
perform an Execution - a jump - when he hears the meaning symbol 'jump'. He is
likely to sit
where he is without moving.
Clearly, it is not the symbol 'jump' that the human is manipulating inside his
head, but
something else - i.e. he is manipulating the different meanings of the symbol
'jump'.
In the first instance, the meaning transmitted by the symbol - the word 'jump'
- can be
expressed as being approximately:
1 ) an order 2) Person Addressed 3) jump.
(n the second instance, the meaning transmitted by the symbol - the word 'jump
-
can be expressed as being approximately
1) an order 2) Thing addressed with ability to jump 3) jump
No one hearing the person saying the word 'Jump' at the horse show would think
that
the person was addressing the word 'jump' to the hedge that horse is about to
jump, or to the
seats around him or to the stadium ceiling. They would understanding the
person was
addressing the horse and hence, the understanding, i.e., the meaning of word
'jump' in the
two instances are not identical. They are similar, and could be said to be a
class of meanings
322
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
of the word jump, but they are not exactly and wholly identical - i.e. the
same without the
slightest variation in meaning.
The Execution that the listener performs based on the identical symbol 'jump'
is
radically different in the two examples - in one example, the listener jumps,
and in the other
example, the listener does not move a muscle.
Hence, equally, the listener is not manipulating the symbol - the word as such
- he is
manipulating the meaning that is for him related to that word, and that word
has at least two
slightly different meanings.
- Method for Converting Multi-meaning Words into Single Meaning Concept
Symbols
Hence, a 'word' is not necessarily a Data Component meeting the definition of
the
word 'Component' in defined in this Any-to-Any machine description. In fact, a
word, on its
own is almost never a 'Component' meeting the definition of a Component.
Most words, and, for example, the word 'jump' used in the example above, are
in fact
One-to-Many transmission elements. One word is firmly related to Many
meanings. The
above example shows that the word 'jump' is firmly related to at least the two
meanings used
in the example.
A human can be observed to process data by manipulating meanings and further,
to
manipulate meanings on an Any-to-Any basis. A human can create a relationship
between
any number of any meanings and any number of any other meanings in a manner
that is not
intrinsically hierarchical and is intrinsically unlimited. The human creates a
relationship
between the symbol 'New York' - which has a meaning per the Similarity
Principle for both
him and the listener - and the symbol 'good' - which also has a meaning per
the Similarity
Principle for both him and the listener. For the listener, the speaker has
related two meanings
together by relating their respective symbols together and transmitting the
related symbols.
The method used by the human to relate meanings is not necessarily the only
method that
could be used. For example, one human who wishes to transmit to another: 'New
York is
good', he does not go to New York, hire an airplane, drop a string round the
city and attach a
label with the word 'Good' on it and then show this to the other human. While
that method
would be ridiculous, the example serves to show that while a choice of methods
exists to
relate things to one another, a human uses one particular one of out of the
choice of ail
possible methods.
Hence, if a machine - a computer - is to act in a human-like manner and enable
humans to interact freely with it, the prime requirement is that the machine
should also be
able to manipulate meanings, and manipulate them on an Any-to-Any basis.
However, the
prime available transmission from a human consists of One-to-Many, multi-
meaning words.
323
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Hence, the requirement for a machine such as this Any-to-Any machine, to be
able to
do anything at all in a human-like manner, is the ability to disassembles all
the meanings of
each word into all the separate meaning Components that is part of the
Component Assembly
to which we give the name of a 'word'. This extends further. When a given
meaning of a
word is in fact assembled from more than one meaning, then the meanings
themselves
should be separated into their Components also.
Hence, the user Data Components that an Any-to-Any machine should manipulate
is a
'meaning Data Component' - one single meaning.that cannot be further split
apart and still
retain any of its original meaning.
Accordingly, the first step in constructing any form at all of data engine is
to manually
disassemble each word into meaning Data Components, and this teaching is the
teaching
that also enables any form of reliable and accurate Language Processor to be
built. Hence
also, an intrinsic part of this Any-to-Any machine, as will be shown, is that
by the very nature
of its construction it is itself a small size version of a Language Processor.
The next requirement to enable a computer to manipulate meanings on an Any-to-
Any
basis, is to assign One symbol to One meaning Data Component, such that no two
meanings,
and no two symbols are identical. Once this is done, a meaning can be
manipulated by
manipulating the corresponding symbol that represents that meaning Data
Component.
The total group of symbols created to represent different meaning Data
Components
is termed a 'Concept Language', and a Concept Language is any language in
which only one
symbol represents only one meaning Data Component - i.e., one symbol
represents one
concept. This Any-to-Any machine contains the framework of two Concept
Languages.
Any Language Processor then - and a data engine should, to some degree also be
a
language processor - in effect stores meaning Data Components by storing the
symbols
used to represent them. It stores these symbols - representing individual
meaning Data
Components - in tables that are dedicated, one table to each different type of
meaning Data
Component. The tables it uses to store symbols representing meaning Data
Components are
the Data Class tables of this Any-to-Any machine. In the Any-to-Any machine as
described
up to this point, every Data Class value mentioned or described is an example
of a standard
English word, but is actually being used in a different manner that is unique
and particular to
this Any-to-Any machine, namely as part of an English Concept Language. In an
X Language
Concept Language, the same words are used that are found in the grammatical
language,
but are used in a such a manner that one word symbol now has only one meaning,
and all its
other potential meanings are eliminated in that particular use. Because one
word used with
only one meaning is one symbol representing one meaning Data Component, it can
be
termed a 'user Data Component'. Hence when-a word that is used in that manner -
as a user
324
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data Component - and, when it is manipulated by the software of the Any-to-Any
machine,
the software is manipulating that single meaning - a user Data Component - by
manipulating
the word that now represents that single meaning.
However, words are not the only type of user data with meanings that a
computer may
be required to manipulate - images and sounds, etc. also exist and may require
to be
manipulated and a common format of some description for all data that the
computer may be
required to manipulate is desirable. Additionally, it is easier and faster for
computers to
manipulate numbers than for them to manipulate words, and it is therefore
convenient to .
translate all user data into a common format - i.e. numbers. Numbers are
useful in this
respect, as all and every number has the quality of being a Data Component,
and therefore, if
numbers are used to represent words, images etc, and this original user data
is stored as
user Data Components, each one of which has its associated single meaning,
then
manipulating the numbers manipulates the meanings.
For this reason, the Any-to-Any machine then takes the stored user Data
Components
(meaning Data Component symbols) stored in Data Class Tables and translates
them into
another Concept Language - termed a Number Concept Language. A Data Class
Reference
number is a Concept Symbol that is part of a Number Concept Language.
After translating the English Concept language into Number Concept Language
(i.e.
data Class Table reference numbers) the Any-to-Any machine then stores Number
Concept
Language statements by storing the numbers in relation to one another in a
Data Relation
Table. Hence a Data Class table serves two purposes:
1. The Data Class table acts as a storage structure for Data Components
values.
The particular values in a given Data Class display the Similarity Principle -
they are all
more similar to one another than they are to any other values at all. The more
general -
wider - of the meaning Data Components in a word - 'first name' in the case of
'Joe' -
provides name for the Data Class.
2. The Data Class table acts as a translation table between one Concept
Language and another, and in this case, between the English Language word used
as a
Concept Symbol and the Numbers Concept Language equivalent - which is its
record
number in that Data Class Table.
Thus, when looking at the contents of a Data Relation Table, what one is
actually
looking at are the remembered statements of a machine that is 'talking' Number
Concept
Language. The Any-to-Any machine manipulates these Number Concept Language
symbols
and statements, and thereby manipulates whatever meanings they represent.
However, it
does not 'know' what that meaning actually is. Only humans know what meanings
they attach
325
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
to words and hence to X Language Concept Language and hence to the numbers in
a
Number Concept Language.
Due to the 'Similarity Principle' the different meanings that different humans
attach to
a given symbol are usually more similar to one another than they are to any
other meaning,
and hence, humans can communicate, and can also communicate with a computer
whose
software is built using these methods.
As described above after the Any-to-Any machine has translated English Concept
Language stored in Data Class Tables into Number Concept Language, thereafter
it stores
statements - i.e. relationships of Number Concept Language statements - in the
Data
Relation Table. This reveals the most fundamental reason why tables and fields
are typically
named with numbers rather than with words.
The method of the Any-to-Any machine to disassemble a multi-meaning word into
a
single meaning Concept Language symbol is to use the Data Class tables,
records and fields
to state a particular meaning of a word - out of all that word's meanings and.
thereby
transform a multi-meaning word which is a Component Assembly, into a Concept
Language
symbol in that same spoken language, that represents one and only one specific
meaning of
that word. Thereafter, the Data Class Table also serves to translate that
symbol,
representing one meaning, into a Concept Language made up out of Numbers,
whereby one
number represents one Language Concept Symbol (a word used in a data Class
Table)
which, in turn, represents only one meaning. Thus, in effect, once a word is
entered into a
Data Class its meaning is transformed into:
Data Class Name meaning + 1 meaning of the Word used
And the translation in Number Language is
Data Class Table number + Record number in that Data Class Table
In the method of the Any-to-Any machine, the number of each field, or record,
or - for
example, the Data Class Table in which a value is stored, IS itself a Number
Concept Symbol
that has a relationship with One meaning. A Data Class Table's number is a
Number concept
Symbol for a part of the meaning of each value it stores. Thus, the number of
the table is a
Number Symbol for one part of the meaning of the stored value, while the
reference number
for the stored value is the symbol representing the other part of the meaning.
Any one Data Class table only ever stores values of one type. Particular
values are
stored in a particular data Class table because they all have one part of
their meaning in
common. Hence, the number of a Data Class Table is a number symbol that
represents the
common part of the meaning of each of the value in the table.
If the value 'John' is stored as value 3 in Data Class table named '1' - the
Data Class
table holding words to which humans ascribe the meaning of being a first name -
then the
326
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
value 13 is a Numbers Language statement for the meaning that humans refer to
with the
symbols 'First Name John'. Manipulating '13' manipulates the meaning of '13' -
m i.e.
manipulates the meaning of 'First Name John' and does not manipulate any other
meaning of
the word 'john' - most of which are vulgar. When '13' is translated back into
words, after
being manipulated in some manner, the symbols (to which the human attaches a
meaning)
represented by '13' are output to the screen for example. The user sees - for
example: 'I
sent the e-mail to John' and does not get an output of 'I sent the e-mail to
the John' - 'John
being vernacular for 'toilet'.
Due to this method of the Any-to-Any machine, a Spoken language Concept
Language can use the same word a number of times, but, each time with a
different one of its
meanings, For example, the word 'fax' used in isolation can be at least 1 ) A
thing - a piece of
paper or 2) an action. When translated into a Spoken language concept
Language, they
translate as follows:
Meaning 1 above = Data Category Matter + Data Class Type of Thing + fax
Meaning 2 above = Data Category Energy + Data Class Action + fax.
The Number Language translation of these is:
Meaning 1 above = Data Category Matter No + Data Class
Type of Thing Table No + Record No
Meaning 2 above = Data Category Energy No + Data Class
Action Table No + Record No
In effect, the Any-to-Any machine method expands the hidden or invisible
meanings
that are part of the word 'fax' and then states them ALL using Data Class
tables as a
mechanism to do so. Because, once a word is de-compressed in this manner, the
decompressed versions are different to one another, the particular meaning
that goes with
that particular decompressed statement of the word is now unambiguous, and a
single set of
symbols (word + Data Class) represents a single meaning of that word.
The Similarity Principle can bee seen to operate 'fax' as an action is more
similar to
any other action than it is to anything else, and certainly more similar than
it is to any material
object. Fax as thing, is more similar to any other material object than it is
to any action
whatsoever. The effect of the method is to disassemble a Component Assembly
termed 'a
word' into its Components, and this then allows the Components to be used in
data
manipulation, which is entirely unambiguous, because the Components themselves
are
unambiguous.
It is specifically this Any-to-Any machine method that enables a mufti-meaning
word,
to be turned into a single meaning word, and thereby enables a computer to
manipulate data
in human-like manner, as the computer is enabled to manipulate meanings.
327
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Hence, the Any-to-Any machine is a machine to manipulate the type of thing
that a
human calls 'a meaning' by manipulating a symbols that represent those
meanings.
- Restrictions on Use of Components
USER DATA COMPONENTS
A given user Data Component reference number can in general only be used in
its
own Data Class, as to do otherwise, effectively changes its meaning, and
results in one
reference having two meanings. If a particular user Data Component reference -
for
example, 7341 is assigned in Data Class A and then used in the Data Relation
Table in the -
Data Relation Table field for Data Class B, when Data Class A is searched for
7341, 7341 will
not be found.
Secondly, in Data Class A1, 7341 is the reference for meaning X. Hence, its
full
meaning is
7341 means = Data Class A Meaning + Meaning X
If it used in Data Class B, it now means
7341 means = Data Class B Meaning + Data Class A Meaning + Meaning X
And hence, one reference now has two meanings, the reference 7341 has now
become a component Assembly and is no longer a Component, and the machine in
general
has ceased to be an Any-to-Any machine.
Hence, if several Data Class references (of the same Data Class) need to be
stated
for a single Data Class Field, this is done using one of a number of methods -
an additional
Data Relation Table record, or a Sequence Record or a Data Assembly Tables.
These
methods will be described in due course.
SOFTWARE COMPONENTS
The above restrictions apply to User Data Components, and are preferable
because
Data Relation Table fields are fields each of which contain similar meanings -
meanings of a
particular type. 1n order to find a meaning of a certain type, it is necessary
to know where that
type of meaning is kept - i.e. in the field for that Data Class. It is also
useful, from time to
time, to see or be able to be given an idea of what types of meanings exist to
be related and
both of these require that meanings of similar types are kept together, and
for this reason
also, a meaning from one Data Class cannot be used in another Data Class.
However, Software Components do not classify by meaning, and do need to be
located by their meaning, and there is no requirement to manipulate software
Data
Components based on their meaning. Software Components - Logics - can be
classified by
function not by meaning and this classification is possible by using
additional fields in the
Data Class Table that stores them. The manner of classifying there will
described when
describing Data Class Tables . Additionally, software Components - Logics -
once written
328
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
and stored, do not need to be found frequently - only the Modules in which
they are
assembled - and hence, it is permissible for a Logic to be used in many Data
Relation Table
fields, at the same time as it is not permissible for a user Data Component to
be used in more
than one field.
- Methods to convert Data into Single Meaning Concept Symbols
Hence, it is of primary importance in constructing the Any-to-Any machine to
understand what does, and what does not constitute a 'meaning Data Component.'
The entirety of the summary of the Any-to-Any machine described the actions of
the
Any-to-Any machine actually by re-defining words as Concept Language symbols,
in which
one word has one and only one meaning because of the manner in which the word
is used in
a Data Class when describing the Any-to-Any machine, and it is precisely due
to this different
and unique method of using words in the Any-to-Any machine, that the Any-to-
Any machine
works.
The word 'letter', for example, has many meanings - it is a One-to-Many
assembly.
One symbol - created from the characters I,e,t,t,e,r in a specific quantity
and order - has
many meanings. Some of these meanings are actions ' to letter an invitation".
Some
meanings designate things: "The first letter of the text was large.'
In summary, the Any-to-Any machine selects one of these many meanings and uses
that one meaning with that one symbol - the particular assembly of characters
that is the
word 'letter'. The symbol 'letter' is placed - for example - into a Data Class
that has the
number of 54 - the Data Class to which humans ascribe the meaning 'Document
Type' - and
is given the reference number of 29. Hence, the reference number for 'letter'
becomes 5429.
The action of designating a Data Class to contain a particular meaning -
document type -
designates also that each member of the Data Class is also a Document Type.
When the computer now manipulates 5429, it is not manipulating the many
meanings
that are attached to the symbol 'fetter'. Whenever it manipulates 5429, it is
manipulating only
one meaning and that is 'Document Type Letter.' In effect, Number Concept
Language is a
way of compressing meanings known to a human into numbers.
While the same elements - words - are used by both keyword technology and the
technology of this Any-to-Any machine, the two technologies bear no
resemblance to one
another as the two technologies use words in two completely different ways.
Just as one
person may use a soft drink can to contain and market a soft drink using one
technology, and
another person may can use a soft drink can as part of a painting or a piece
of art, the two
'can' technologies bear no similarities to one another. Similarly, keyword
technologies and
the Any-to-Any machine technologies both use words, but in completely
different manners.
When a'keyword search' is done, a word such as 'letter' is said to be a
keyword and a mass
329
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
of text is searched for the word 'letter'. The search technology used is a
symbol-matching
technology. The symbol that is 'letter' is symbol-matched with entries in the
text that are the
same symbol. Consequently, the search returns all instances of the word
'letter' and thereby
inevitably also returns all instances of any of the many meanings that are
attached to the
One-to-Many machine that is 'letter.' Consequently, the computer returns 'Joe
wanted to letter
an invitation' and 'The first letter of the Bible was large' as well as: 'the
letter from the electric
company asking for payment.' This keyword search technology is the technology
that, in an
Internet search engine returns hundreds of thousands of hits when only a few
are required.
However, the human using 'letter' to search for something actually wants to
find just one of
the many meanings that can be ascribed to the symbol 'letter', except that
keyword
technology has no method to enable him to do so. if he could say to the
computer, search for
'Document type letter' and the computer was so arranged as to use this as he
uses it, then, in
the above example, it would return only 'the letter from the electric company
asking for
payment' and would not return the other instances that use the symbol 'letter'
in other
meanings. The technology of the Any-to-Any machine, along with a suitable
Visual or
Language interface, enables the computer to manipulate meanings, one aspect of
which is
enabling a computer to search for meanings.
Continuing the analysis of what does and what does not constitute a 'meaning
Data
Component' it is clear that a human will require to communicate with a
computer, and that
therefore, what does and what does not constitute a 'meaning Data Component'
should be
clearly understood. When the words 'Data Component' are used in relation to
user data, the
more exact meaning of the term is 'a single unique meaning represented by a
single unique
symbol or a set of symbols that, together, are unique'
The prime elements of human transmission are words and numbers - humans cannot
create pictures on their chests and have other humans accept the transmission.
Hence, the
elements of other transmission systems between humans - such-as non-word
sounds,
gestures, facial expressions, images and electronic pulses - are either less
precise or more
laborious to construct, and so perform a secondary role in human transmission.
Since the requirement for the construction of a data manipulation Any-to-Any
machine
in a computer is to store all user data as Data Components, it is therefore
useful to
understand first, which of the human transmission elements are Data
Components, and which
of them are not Data Components. Those that are Data Components can be stored
as Data
Components, and those that are not should be broken down into Data Components
before
storage. If a transmission element consists of several Components, it is
useful to understand
what each of these are in order to determine if the Any-to-Any machine can
store that type of
Component or not. If a transmission element consists of several Data
Components, then
330
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
either the Any-to-Any machine itself - or some other mechanism - is needed to
resolve each
element type into the Data Components from which it has been assembled, so
that these can
be stored by the Any-to-Any machine.
Reviewing each type of human transmission element in turn:
WORDS:
The words of a spoken Language - if transformed by putting them into data
Classes in
the manner described - can be converted into Data Components. However,
virtually all
words, if not converted into Components with the Any-to-Any machine method or
another
method that produces the same result, do not qualify as Data Components. An
endless
variety of other methods than the one described can be used to implement the
teaching of the
Any-to-Any machine and achieve the same thing result. One of these which is
particular
useful when recording blocks of text, and which avoids having to put all text
into a Data
Relation Table when it is not optimum to do so, is simply to code each word
with a number
that is its Data Category and Class. For example, if the word 'fax' as the
action is recorded,
in a Data Relation Table as Data Category 3, Data Class 65, it.can be record
in Data Class
coded text as '365fax'. If 'fax' as a thing is similarly recorded in Data
category 5, Data class
121, then the word can be recorded in Data Class coded text as '5121 fax.' An
appropriately
constructed search engine, looking for things, looks for words coded 5121 and
finds 'fax' or
looking for actions looks for word coded 365 and finds 'fax'. Different to
keyword technology,
when looking for 'fax' (when the user wants an action) it does not find and
return 'fax' the
thing. Another method is to list all the meanings of a given word and then
simply number
them and record the number along with the word. For example, if 'fax' as an
action is given
the number 1 and so recorded as 'faxl', and 'fax' the thing is given the
number 2 and
recorded as 'fax2', then the teaching of the Any-to-Any machine is again used
to enable a
computer to manipulate individual meanings of words and not the words
themselves. These
methods of including the Data Class reference in the stored text are generally
referred to as
'Data Class Coding' methods
The majority of words - for example - 'banana' 'letter' 'New York' can be used
as Data
Components in the Any-to-Any machine if and only if such words are placed in a
Data Class
table per the methods of the Any-to-Any machine. The fact of placing such
words in a Data
Class acts to select one meaning, out of all its possible meanings, and
thereby converts a
word symbol that is not intrinsically a Data Component into a Data Component
by discarding
all its other meanings.
Some words and also some suffixes and prefixes in the language have a
'meaning'
that is in fact a coding operation performed on adjacent words, and may in
addition have a
meaning in the normal sense of the word. Such words are turned Operator Words
and their
331
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
meaning often states a relationship between words, as well as performing a
coding operation
on other words. The operations such words perform are generally:
1. To select one of the meanings of a word, or of part of a word, or
2. To relate that word to another word in some manner
The activities of Operator Words on neighboring words can become complex, and
in
addition, the Any-to-Any machine method of assigning an additional meaning by
assigning a
word to a Data. Class is not sufficient for Operator Words as they are usually
affecting words
other than themselves. Effectively, the only satisfactory way to use Operator
Wards relation
to the Any-to-Any machine is to process them with a Language Processor written
with the
Any-to-Any machine methods and thereafter, the effects of that processing are
expressed in
Data Relation Table records that can be used by the Any-to-Any machine.
The subject of Operator Words is the domain of Language Processing and
accordingly is not described here, but a programmer creating an application
with the Any-to-
Any machine needs to understand what they are, sufficiently to avoid them when
creating an
application with the Any-to-Any machine. With this objective, the following is
a short
description of Operator Words:
An example of an Operator Word is the word 'are'. 'Are' has a meaning of
'exists' but
it also has other meanings, some of which perform operations on other words.
It should be
remembered that written text is a derivative of spoken words, and that, in
speech, punctuation
virtually does not exist, and a meaning can be discerned perfectly well - by
humans - if
speech is delivered in an uninflected monotone ignoring punctuation. If
someone speaks the
words 'The dogs' the assumption is may be that there is more than one dog or
that there is
one dog. However, both these assumptions are invalid. The assumption that it
is more than
one dog is invalid: 'The dogs collar is red.' There is only one dog. When the
words: 'the dogs'
are spoken, there is no punctuation to tell the listener whether it is 1 dog
or 2+ dogs. If the
person says 'the dogs collar is red' then it is 1 dog. The assumption that it
is one dog is
equally invalid: if the person says the 'dogs collars are red' it is now known
that there are 2+
dogs. The word that states, in this instance, whether 'dogs' is 1 dog or 2+
dogs, is the word
'are'. The word 'are' is an Operator Word - it is operating on other words,
and in this instance
is operating on the 's' of the word 'dogs' to select one of the several
meanings of 's'. The
other meaning of the 's' in the word 'dogs' is 'dog, 1, has' and is
dramatically different to
another other meaning of 's' in 'dogs' which is 'dog, 2+'. 1n fact there is
still another meaning
of 's' which is not '2+' and 'all' - 'dogs are good'. Hence, in the above
example, both 's' and
'are' are operators, and 'are' operates on 's', which operates on 'dog'. The
combination of
these Operator Words is to select different meanings of 'dog' namely
Dogs (+ good) ('are'-is absent) = dog, quantity = 1
332
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
= word which follows is a something belonging to
the dog
Dogs + name of thing + 'are', = dog, 2+
Dogs + 'are' (+ good) = dog, quantity = all
This illustrates the manner that a Language Processor uses rules to detect
which
meaning of a given word symbol - or suffix or prefix - is in use and such
rules are easily
expressed using the Any-to-Any machine. When a Language processor has detected
the
meaning of a word that is in use, it can then assign the correct Data Class
user Data
Component to the word. The above example shows that any one given word can
have a
meaning that is itself composed of more than one data meaning Component, and
therefore, a
single word can be represented by more than one User Data Component. The
description
previously given of the method used to assign words to Data Classes, and the
description
above, illustrate that spoken language is a compressed transmission
technology. Once a
word is decompressed, the word can then be placed in a Data Class table and
from there, in
Data Relation Table record in the form of user Data Components. For example,
the second
meaning of 'dogs' stated in the example above, when recorded in a Data
Relation Table is
recorded as Data Class Non Human life, value dog, quantity 2+. The third
mewing of 'dogs'
stated in the example above, is recorded as Data Class Non Human life, value
dog, quantity
all (every Data Class value can take a quantity). The different meanings of
the words are
now differently represented in Concept Language and the individual Components
of the
meaning can be separately accessed and queried. For example, if the query is
given 'Have
you heard about 2+ of anything? The answer can be returned, 'Yes, dogs.' if
the query is
issued 'how many dogs were being discussed?' the reply can be 'at least 2 in
this instance,
and all dogs in that instance. If the query were more precisely worded as 'Do
you know
anything about dogs? The query wood return 'all dogs are good, some dogs have
red collars'
etc. Note that the distinction between 2+ dogs made in the recording of the
data, and 'all
dogs' shows up in the answer 'some dogs have red collars'. If the plural
'dogs' had been
treated as 'all' the answer would return 'all dogs collars are red, which is
not true.
Because of this interaction with other words, Operator words cannot be used
directly
in a Data Relation Table without first being processing by a Language
Processor. An
Operator Word can be detected by using a group of words with and without the
word in
question and seeing if the word in question changes the relationship or
changes something
else about the words, in the manner that was shown for 'are' above. An example
of an
operator word that sets a relationship is 'on' in 'the flowers on the wall'.
Removing 'on' leave
'the flowers' and 'the wall' neither of these word groups are changed by the
removal of 'on'
333
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
but 'on' states a type of relationship between the groups. 'On' is an Operator
Word in this
instance.
Many words in a language do not perform operations on other words, or if they
do,
those operations are limited. In the Language Processor, words that perform no
or limited
operations on other words are termed 'Meaning Words'. Most words that are
referred to in
the state of the art as 'keywords' are in fact Meaning Words, and Operator
Words are largely
ignored in the state of the art, and even eliminated from the material
searched by some
search engines, even though they are extremely key to determining meaning
Components.
- Vllhile Operator words cannot be used in the Any-to-Any machine without
prior
Language Processing, Meaning Words can be used, provided that the meanings
used are
single meanings created by assigning them to a Data Class.
'Banana' 'letter' and 'New York' are examples of Meaning Words.
How Meaning Words behave also needs to be understood in order to use them in
the
Any-to-Any machine. Every Meaning Word can be found to have at least one
meaning that
classifies in each one of the five Data Categories. This meaning may, or may
not have a
variation of spelling. The following table shows how the four words: 'banana',
'letter' and 'New
York' each have one meaning in each Data Category. While the usages in the
examples and
the spellings may not be grammatically correct, and some are infrequently
used, when people
speak, they pay little attention to what is and what is not grammatically
correct or the
frequency with which a word is used in one way when they speak. Indeed, some
people
delight in flouting such rules when speaking. The criteria for speech between
people - and
hence the criteria that should be applied to manipulating words that a
computer may be given
and have to use correctly - is not whether the usage is considered
grammatically correct by
some authority or other, nor is frequency of a usage any criteria whatsoever.
The sole and
only criterion is whether that meaning of the word is, or is not understood by
most other
humans when they hear it. A computer is there to understand what is said to
it, and is not
there to be grammar, syntax and usage standards enforcement tool:
334
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data Category Banana Letter New York
LIFE, Data You are a veryThat is a veryA New Yorky
Class
Quality bananly personletter-like summer
- e-mail.
that yellow or
suit!
TIME Banana time It is Letter !t is New York
time - time
Johnny - the sit down and - get on the
write plane
doctor said it before you
2 a day miss it
SPACE Go to the BananaGo to the letterGo to New York
ENERGY (Actions)I'm Bananaing I think you You had better
it - should
peeling away letter Joe New York that
the (i.e.
rubbish to send him a attorney letter
find the letter)
good in it.
MATTER Banana, pleaseWhere is the Make a model
eat of
one now letter? New York
Words used in the Summary as being members of Data Classes have been used
throughout as being symbols representing meanings that can be generalized as:
Data Category meaning + Data Class Meaning + Value in Data Class meaning.
Thus when a reference number for 'letter' is used in the Any-to-Any machine it
is used
with the meaning:
Matter, Document Type, letter.
If the word 'letter' is used in the Any-to-Any machine as an action - 'letter
Joe about
the bananas' then it is placed in the Action Data Category, has a different
reference number
and hence, different meanings. The meanings of the reference number then is:
Action, Document type, letter
The usage of the word 'letter' as an action is not very usual. However, other
words
frequently appear in more than one Data category:
'Fax Joe'- 'fax' is an action, and is therefore recorded in a
manner and with the reference numbers that ascribe it the meanings of:
Action + Document type + fax
Where is Joe's fax - 'fax' is a thing, = and is therefore recorded
in a manner and with the reference numbers that ascribe it the
meanings of: Matter + Document Type + fax
'e-mail' can be either an action and hence used 1 ) as an action in the Energy
Data
category, or 2) as a thing in the Matter category.
335
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The number of different meanings attached to given word syrribol that can
occur in the
restricted environment of human giving orders to a computer is relatively few.
They are
relatively simple and easy to distinguish because the command environment
itself acts to
eliminate many possible meanings, leaving each word with a reduced meaning
set. The
different meanings that remain for a given word symbol can be distinguished
easily by a
suitably constructed Visual Interface that guides the user to perform the
distinction himself.
Alternatively a suitably constructed and simple version of a Language
Processor can do this
quite easily for a large part of the orders a human may give to a computer.
The construction
of such a simple Language Processor using the Any-to-Any machine methods will
be
described shortly.
Once the interface has distinguished the meaning in use, and sent it to the
correct
Data Category, the word switches from operating as a One-to-Many mechanism and
becomes a Data Component Concept Language symbol with a single meaning - i.e.
a
Component - and hence can be used by the Any-to-Any machine. The word itself
is no longer
entered as just the word, but is entered as Word = Data Category + Data Class
+ Word
Even if the same word is used in another Data Category, it is also entered as
(another) Data Category + (another) Data Class + Word, and its recording in
the Any-to-Any
machine is now therefore different from the recording for the other meaning of
that word.
e-mail = Action + e-mail, is now no longer the same as
e-mail = Matter + e-mail
The two meanings of the word have been distinguished from one another by
recording
them in the Data Category of their meaning. This results in the two different
meanings having
two different recordings in the Any-to-Any machine, and two different
reference numbers
assigned to them. In reverse, when a reference number is found, the word to
use for that
reference number can be found also. If a Language Processor is in use, then it
can be told
whether the word is - for example - e-mail - an action, or e-mail - a thing,
and use its
grammar formatting rules to place the word correctly in its output. If a
Visual interface is in
use the output process is easier as each Data Class is directly connected to
an Active
Element displaying values from that Data Class, and hence, from that Data
Category. Using
a suitable Label record with the output will display appropriate Label
characters. The human,
looking at the Label characters, and the Output characters, will see words
that, for him, have
certain meanings. Hence, while the Any-to-Any machine does not actually
manipulate the
meanings themselves, only symbols for meanings, but since the human supplies
the
meanings instinctively without being asked to do so, as far as the human is
concerned, the
computer has manipulated meanings, and has 'understood' him.
336
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
This describes why the methods of the Any-to-Any machine - Data Categories,
Data
Classes and the Data Relation Table enable a computer to enable a computer to
manipulate
meanings, and hence - amongst other things, provide the basic enablement
required for a
computer to be programmed to perform Conditions, Executions and Specifications
in a
human-like manner.
NUMBERS:
A number, by itself and unassociated and unrelated to anything else, qualifies
as a
Data Component. A number, by itself is completely different to anything else
in universe, and
if broken into Components, ceases to have any ability to function as that
number and its
Components cease to have any of the meaning of the original Component. For
example, the
number 123 in isolation means 123, and means nothing else at all. If it is
broken into
Components '12' and '3' for example, '12' and '3' do not have any of the
meaning of '123', but
in fact are each completely different names, or Data Components, with
completely different
meanings. If '12' and '3' are strung together - i.e. their meanings are added
together - the
result is 15, not 123. Because of this, all numbers qualify as Data
Components. Because of
the accident that numbers used as Data Components are same type of thing as
the type of
thing used by the Any-to-Any machine to reference values in Data Classes, a
field in a Data
Relation Table that is used to record numbers does not usually require a Data
Class table.
Entries in the field that are numbers can do double service as their own Data
Class Table and
no translation is required for the human to understand them, except perhaps a
Software
Module conversion routine that converts numbers written as words into numbers
as written as
numbers for so that they can be recorded in the Data Relation Table and to
reverse the
procedure when needed to display number written in the form of words. However,
if required,
a Data Class table can be created for a Data Relation Table number field, and
be used to
hold one example of each number used in that field, and under certain
circumstances, this
can speed look-ups.
A number, totally by itself, means that number and nothing else - '123' means
'123
and nothing else. However, when it is related to any other Data Component, it
acts on the
Co-reducing Concept Principle and Method. For example:
123 letters. The concept of 'letter' with its meaning of a thing, plus 123,
effectively
means, 'out of all letters, we are talking about 123 of them.'
Any data at all can take a quantity:
123 happier
123 Wednesdays
123 spaces
123 jumps
337
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
123 bananas
123 'if's
In terms of human Specifications for data, Numbers fall into a general
grouping of
Data Components termed 'Modifiers' in this Any-to-Any machine. A 'Modifier' is
defined as:
A Data Component, or Data Component assembly that, when used by totally
by itself, identifies a class of data that is so broad and far reaching as to
service little
practical usefulness. When used with any other data whatsoever, it limits that
other
data to that part of it which contains the Modifier.
~ As an example of this, the number '123' encompasses the concept of every
single
occurrence of '123' that ever has existed, and ever will exist both in reality
or in imagination of
everyone who ever has existed, or wiN exist. This concept is so broad that, by
itself, it is not
frequently used wholly by itself. However, it can be used with any data
whatsoever, and then
- with the Co-Reducing Concept Method - does identify the part of that data
that contains the
Modifier.
Several Data Classes, all of which are found in the Life Data Category, meet
the
definition of a Modifier. For example, one of the Life Data Category Data
Classes is the Data
Class of 'Quality'. A word in the Quality Data Category such as the word
'good' has a
meaning that is so broad and far reaching as to serve little practical
purpose. The word
'good' has a very broad meaning if said in total isolated from any other data,
including
preceding circumstances. ('Good' has one meaning - as an acknowledgement to
something
said - that is an exception to this, and which is precise').
Because of the common phenomena displayed by the types of data classified as
Modifiers by the Any-to-Any machine, Modifiers are treated differently in the
Any-to-Any
machine to Data Components that are not classed as Modifiers.
The Any-to-Any machine provides three methods with which to manipulate and
record
Modifiers. Which of these methods, or which combination of the two methods is
chosen by
the programmer depends on several factors:
1. The capacity of an individual field in the storage medium (database) to
record
numbers.
2. Whether Modifiers are required at all in the application concerned
3. The number of Modifiers to be recorded for a given field.
The thee methods are as follows:
338
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
First Method - Include the Modifier in the Data Relation Table field using
Combined Numbers
A given Data Relation Table field containing a Data Class value, in addition
to the
reference number for the data it contains, can also contain the reference
number for up to
ONE Modifier of each type, so that the number I the Data Relation Table field
is a Combined
Number - i.e. a it is a single number, and different digits positions in the
number are treated
differently by the accompanying logic- The disadvantage of this method is
there are several
Data Classes that are Modifier Data Classes, and hence, this can lead to the
requirement to
contain very large numbers indeed in a single Data Relation Table field. Using
a large
number in this manner for a small amount of data can considerably reduce the
overall
capacity of the Data Relation Table. In other words, some fields in the Data
Relation Table
can run out of available numbers long before others, necessitating the use of
a Software
Module (to be described later) to reorganize the Data Relation Table numbering
and maintain
its Unlimited nature. The method however, can be useful in some applications
such as
embedded applications where there are relatively few Modifiers that may need
to be recorded
and the frequency with which they will need to be recorded is low . An
embedded application
- for example, an application in a car recording a cylinder temperature - may
not need to
record the non-Modifier Data at all, and only need a single Modifier, which
can then be
presented as a Data Class. For example, if a specific field in the Data
Relation Table is
considered to contain (labeled as) 'Temperature °C of Cylinder 4' and
arrangements are
made for the temperature probe to supply data to that field, then the only
requirement .is to
record the Number Modifier - e.g. 998, 993, 1019 etc. On the Co-reducing
Concept method,
the data that is in effect recorded each time is:
Temperature °C of Cylinder 4' 998
Temperature .°C of Cylinder 4' 993
Temperature °C of Cylinder 4' 1019
A Modifier can be used as a Data Class so that the information reads out as:
Data Class Name: Temperature °C of Cylinder 4' Modifier
998
993
1019 Danger!
In addition to being of use in embedded applications, this method is also
useful where
there only a few members of a Data Class containing Modifiers. Examples of
such Data
Class are the Data Class Existence which states whether a thing does or does
not exist and
the Data Class Sign, which has only 3 members - positive negative and neither
positive nor
negative. Data Classes of this type require relatively few digits to refer to
all their members,
339
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
and therefore, their reference numbers can conveniently be used as part of
Combined
Numbers.
Combined Numbers are limited in use to places where a record number is
unlikely to
be a part of the Combined Number. The reason for this is if a Record Number is
used as part
of a Combined Number, then the more digits are used for the other parts of the
combined
number, the fewer digits are available for use as record number in the overall
table, and the
sooner steps should be taken to make more numbers available as record numbers.
Thus
using even one record number in one single Combined Number in the Data
Relation Table
reduces the number of records that a Data Relation Table can hold. The
decision on whether
or not to use a Combined Number in a given field is a question of balancing
the reduction in
the number of fields that are needed against the consequent reduction in the
number of the
records the Data Relation Table can then hold.
Second Method - Include Modifies as Data Relation Table Records
The second method, which is a useful method for office and similar
applications,
where modifiers can be numerous, is that each Data Relation Table record can
be
accompanied by any one or more Modifier type Data Relation Table records each
one
containing the reference number of one specific Data Class whose values are
Modifiers.
Using this method, a Data Relation Table data record can contain
entries that state 'John' and 'Past Time and 'Send' and 'Letter' ('letter'
being
used with the meaning of a type of document.
Data RelationData RelationData RelationData Relation
Table fieldTable fieldTable field Table field
10 20 30 40
Data RecordPaul Past Time Send Letter
Number 22 11 123 104
Modifier
Record
Quality Good Good Quick Slow
Modifier
Record (1
)
Quality Young Bad Badly Exquisite
Modifier
Record (2)
340
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
In effect the Data Relation Table records in the above example, when phrased
per the
conventions of grammar, state:
'Twenty good young Pauls, 123 times sent, quickly but badly, 104 slow
exquisite letters at 11 good bad times in the past'.
This method of storing Modifiers is one of the general methods of storing data
in the
Data Relation Table, and is a method in which the data in a particular Data
Relation Table
field parallels data in another Data Relation Table record with which it is
associated, such that
the value in a specific field number concerns and is associated with the value
in that same
field number in the associated Data Relation Table record. Records that
parallel one another
in this fashion are termed Associated Records.
Third Method - use a Combination of the Previous Two Methods
fn this method, some specific Modifier types are included as a Combined Number
in
the Data Relation Table field concerned, while others use their own type of
Data Relation
Table record, while still others use a Compound Modifier Data Relation Table
record, in which
several Modifier reference numbers are used as a Combined Number in a single
(or a few)
Data Relation Table records, Compound Modifier type.
Methods to Interchange between the Different Methods of Recording Modifiers
The method now to be described is the general method to use when different
applications written with the Any-to-Any machine methods use different ways of
recording
given data.
Whichever method of the above methods are used, in every case, one or more
Modifier Data Ciass Tables exist, and the number recorded by the method is the
reference
number to that Modifier in the appropriate Data Class table. The reference
number of a
Spoken Language Concept language value is a Combined Number that consists of
the
number of the Data Class Table in which the value is stored as well as the
record number of
that value in the data Class table. Because of this manner of creating a
reference number,
the reference number can be found no matter where in the table it is stored.
Converting or
reading between Data Relation Tables using different methods is then a
question of either
checking the pattern in the Table itself, looking for where references with
the Modifier Data
Class Table Number are stored or, if the programmer provides for it, storing a
reference
number in a Table Design table, that states which method is in use.
The manner in which Modifiers are stored depends on the requirement of a
particular
application to use Modifiers, particularly the necessity to find Data Relation
Table records
based on Modifiers alone. If it is needed to find a record based on the
modifier alone, with no
other data at all, then, in the absence of other arrangements this would
require a search of all
341
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
fields of the entire Data Relation Table. In this case, it can be worthwhile
to make one of two
provisions:
i . W rite a Software Module that searches for Modifiers in rows, after
setting the
record type to the Modifier type require, rather than the more normal method
of searching
in columns. If this is done, it can be useful for searching other types of
Associated
records and Sequence records.
2. Create a parallel Data Relation Table record for Modifiers, other
Associated
records and Sequence records, in which only those types are recorded, and in
which the
Modifier records occur in columns in the table. This system requires writing
such records
twice, once to the normal Data Relation Table and once to this Associated
Record Table.
Method to record Associated Records that are frequently used to identify Data
Relation Table records
An Associated Record Table is a table that is constructed without record
numbers as
such, since each value entered in it - such as a Modifier has its own
dedicated fields and
each other type of item in it - also has its own dedicated fields, termed a
'Field Set'. For a
given item that is to use the table - for example, Modifiers, the minimum
Field Set is as
follows
1. Reference Number. Each value new value entered in the Field Set is given
the
next available number. An example might be the number 14
2. Data Class Value Ref. This field contains the value reference of that value
in
the Data Class Number. An example might be the number 14128 referring to the
associated Data Class Table number 14, value 128 is transiated to 'good'
3. Data Class Value Type. This field contains the value reference number for
the
type of the particular value entered in the previous field. An example might
me the
number 15014 referring to the associated Data Class Table number 15, where
value 014
translates as 'Quality'
4. DRT Ref. This is an abbreviation for 'Data Relation table reference, and is
a
Combined Number consisting of the Record number and the field number where the
value
is assigned.
When this method is used the Data Relation Table uses the Reference number
from
the Field Set either as a Combined Number or as a separate record of that
type. In
consequence, if the Data Relation Table field is accessed first and a
Associated Record table
is in use, the reference number points to a specified Field Set and number in
that Field Set in
the Associated Table record. If the Associated Table is accessed first, then
the DRT Ref field
in that table contains a value pointing to the particular Data Relation Tabfe
field where that
value is used. If all instances of a given value or a given type of value in
an Associated
342
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Record Table are required, all these can be found, together with their
pointers to where they
occur in Data Relation Table record fields.
When an Associated Record Table is used, Software Modules should be written to
take account of this, or, one Software Module is written that logically
combines the two tables.
Modules that combine Tables or Record or convert records using one method to
records
using another method of the Any-to-Any machine are generically termed 'Record
Converters'.
When more than one Software Module is required to perform an action, then a
separate
specialist Module is written to perform that action. In the above example, if
a specialist
Module is written to combine the tables logically - for example, by making the
appropriate
Field Sets into virtual Data Relation table records for all other Modules,
only the specialist
Module should be written. No change is required to any other Module in order
to read an
application in which the Modifiers are record in either Data Relation Table
records, or in an
Associated Record Table. If, on the other hand, all Software Modules are
written to take
account of the additional Associated Record table, then none of them will work
if they receive
data in which the Modifiers are in the form of Data Relation Table Records and
the entirety of
them will have to be replaced. Since many of the Modules may have come from an
alternate
software house, the possibilities for problems are limitless.
Hence, when alternate methods exist to record data, the basic method to do so
is the
most flexible method - i.e. using an entire Data Relation Table for the items
to be record - is
considered to be the method in use under all occasions, and all alternate
methods -
Combined Numbers, an Associated Record Table, Data Assembly Tables, Sequence
Records etc - are used, one Software Module is written for each type of
conversion, and
works in the background, and presents all remaining Modules with the data
converted into the
form of a virtual Data Relation Table. The Data Relation Table Administration
fields, Record
Type number, Sub-Level number and Sub-Sub-Level number provide adequate
possibilities
for marking any Data Relation Table data record that contains one or more
types of alternate
methods of recording data. When the controller Logic of a software Module
detects one of
these relatively few numbers in the appropriate field, it sends a token to the
appropriate
Virtual Record Converter Software Module, which performs the appropriate
conversion. A
Virtual Record Converter Software Module does this by creating the needed Data
Relation
Table record types in a Working Data Relation Table that is used simply as its
own temporary
repository where it can write records, marking them as the appropriate type of
record and
then reading them into memory where the remaining Data Relation Table data
records - with
which they are associated have already been placed for the Software Module
that is
executing.
343
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Normally, most Modifiers are not the sole subjects of a search and
consequently,
creating an Associated Record Table is an unnecessary degree of elaboration if
done for
Modifiers alone (such a table may be desirable for other reasons). Referring
to the Boss/
Secretary model, a boss will not normally query a secretary with 'what do you
know that is
good?' and even if he does, is likely to get a counter-query - 'what sort of a
thing are you
talking about?' - simply because the query is too broad. The boss is likely to
reply in the
sense of 'What's good about Joe' or 'What's good about today' - which, in
either case, means
that the search required in the Data relation Table is relatively limited, and
can be performed
acceptably without requiring an Associated Record Table.
SOUNDS
A single sound - a single note - is not a Component as it can be broken down
into a
number of Data Components such as frequency, amplitude, and many other aspects
with
which musicians are familiar. In many applications, it is adequate to treat
sounds as a Data
Class Content Sub-type termed 'Sound' and this can include any sound. As just
described,
any Data Class entry can have any number of Modifier records, and one Data
Class whose
values are Modifiers is the Life Data Category 'Name'. Thus, an entry in the
Sound Data Sub-
class can be accompanied by a Name such as 'Bloopah' - a made up name. (More
normally
however, the complete Data Relation Table record would be given a name in the
Administration field 'Name of this Item').
In applications where the Software Modules are required to manipulate sound
itself,
then one method is to disassemble sound into Data Components, and then assign
each to a
Data Sub-Sub Class of the Data Ciass Sound, or, create the Data Sub-Sub-
Classes as
Associated Data Relation Table records, with one Associated Record for each
component of
the sound. As per the method of the Any-to-Any machine, the data assembly that
is 'a sound'
can then be represented by one type of Data Relation Table record for each
type of Data
Component making up 'a sound'. In this case, the Software Module that reads
the Data
Relation Table Sound type, Associated records in parallel, supplies the output
device with
appropriate inputs based on the Data Relation Table records, controlled as
needed by Timer
and other Data Relation Table record types.
In the state of the art, some sound software applications - such as Voice
Recognition
- produce results that are themselves a problem, and, for example, Voice
Recognition is
seldom 100% accurate. Such applications manipulate sound not as sound Data
Components
as described above, but as sound data assemblies, consisting of many sound
Data
Components combined. Thus Voice Recognition in general treats speech as
consisting of
Component Assemblies termed phonemes which are defined as ' a phonological
unit of
language that cannot be analyzed into smaller linear units.' Such a statement
is transparently
344
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
false as any sound can be analyzed into smaller units and some of these can be
linear. Voice
Recognition attempts to compare user phonemes with recorded phonemes, which is
the
action of comparing one sound Component Assembly with another sound Component
Assembly . However, and inevitably, because even a phoneme is composed of a
considerable number of sound Components, no one spoken phoneme is wholly
identical to
another, and many phonemes overlap in some of their constituent sound Data
Components.
The inaccuracy that arises through failing to break down the sound into all
possible
Components, is then compensated by using various grammatical and syntax
techniques, all
of which apply some of the time, but none of which apply all of the time, and
hence,
inaccuracy is the norm in the state of the art, and a continuing problem.
A further source of inaccuracy is the use of probability calculations to
determine,
based on phonemes, which word was spoken. As previously stated, a human uses
probabilities in relation to the future, but uses them' far less or not at all
in relation to existing
data. A human, hearing a spoken Word, either identifies that word or does not
identify it. That
identification can be either correct or incorrect, but in either case, the
human treats it as
correct. If the human does not identify a word, he does not then use
probabilities, but looks
for, and potentially selects a word that has the abilities required of the
undetected word by the
remaining words used. He does not use probabilities, but matches certainties.
As the speech
proceeds, he may find that one or more of the words he detected 'do not make
sense' and
may substitute another word that does concretely have the same abilities as
the word that
'does not make sense' or he may ask for clarification. In all cases, however,
the results of the
human's manipulation of words can be analyzed and stated as the result of
concrete choices
based concrete comparisons, and cannot be analyzed as the result of
probability calculations.
Probability calculations in terms of Voice Recognition, depend on various
aspects of
frequency of use, or arbitrarily stated correctness of use, and neither of
these methods are
detectable in human word manipulation and therefore, are unlikely ever to
produce results of
comparable accuracy to the results produced by another human.
Spoken sound - i.e. spoken words and numbers - can be recorded in a Data
Relation
Table in terms of Data Relation Table Sequence type Associated records of
Sound Data
class Type that are simultaneously recorded for each type of sound Data
Component, each
one of which is accompanied by a Timing record to state the duration of that
Component.
'Understanding' speech consists of two elements:
- Detection of a word from its sound
- Detection of the meaning of the word that is in
use in this instance.
A Language Processor can detect which meaning of a word is in use in any
instance.
345
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
However, a human listening to speech, does not necessarily use the meaning of
a
word to detect which word that word is. If a human hears 'and and and, but' he
may detect
the words perfectly well but have no idea what the speaker means by using
them. Hence, the
state of the art method used by Voice Recognition to resolve uncertainties of
word detection
of using grammar and syntax - essentially to determine what word can be used
with what
other word - will tend to fail in every instance where the use of the word is
not found in the
incorporated rules of grammar or syntax. Hence, in order to be as successful
in Voice
Recognition as a human, voice recognition technology should not depend on
meanings,
grammar or syntax, but should depend on detection of a word based on its
spoken sound
alone.
As previously discussed, humans are adept at relating data using Data
Components
such as meanings, or specific combinations or patterns of Data Components.
A human, hearing any two spoken words in isolation from other factors, either
detects
them as being adequately identical to be the same word, or detects them as
different. In
either case, his detection of the word - as opposed to the meaning of the word
- as either
identical or different can only be based either on a sound Component in that
word, or on a
certain combination of sound Components in that word compared to the other
word. The
'other word' can of course, either be spoken, or be his memory of another
spoken word.
If a word is detectably different to a human, then the detectable difference
is based on
a sound Data Component or a combination of sound Data Components, and of these
matching a particular remembered sound Data Component or particular pattern or
particular
combination of sound Data Components, which does not match any other word's
combination
of sound Data Components. In effect, the process of detecting a word in a
computer is
analogous to the process previously described for detecting a particular data
Specification in
Data Relation Table records. This can only be done accurately if the data is
record as
Components and records can be located based on the particular Components they
contain.
When user data is recorded as Component Assemblies and then searched for using
Component Assemblies such as in Keyword searches, the results are haphazard at
best, as
Internet searches show. In the case of word detection, the sound Specification
consists of a
number of different sound Data Components that occur simultaneously in
specific relationship
to one another. The Any-to-Any machine Data Relation Table is a method of
recording
relationships of data rapidly and can equally well be used as a method to
record parallel (i.e.
simultaneous) inputs of different sound Data Components in the form of Data
Class Sound,
Associated record types. Once such voice inputs are recorded in terms of Data
Relation
Table records, they can be matched with previously recorded voice inputs
recorded in the
same manner. -
346
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Qualified engineers can observe the different Data Relation Table records for
each of
two words that are being confused, and can themselves compare - using the
standard
methods of the Any-to-Any machine - the Data Relation Table records for the
sounds of the
. two words. Additionally, they can themselves compare individual types of
those records with
the same types for other words, and thereby, find a particular combination of
sound Data
Components that separates the two words from one another and from all other
words. If a
particular word is recorded many times, spoken by different people - as is the
practice in
state of the art Voice recognition - then a Software Module can automatically
compare all of
the Data Relation Table records containing one sound Data Component for each
of the
recorded words. Based on this, the Software Module can calculate the maximum
and
minimum for each Component and record this as a type Data Relation Table
records termed
a Maximum records and Minimum records. If such Maximum and Minimum records are
used
for each sound Data Component in a word, then the engineer can even better
ensure that the
chosen pattern of sound Data Components for a given word does not overlap the
sound Data
Component pattern for any other word.
Hence, the Any-to-Any machine provides methods allowing the problems existing
in
state voice recognition to be resolved.
IMAGES
Images, just like word content and sound content, can be recorded in whole as
Data
Component assemblies in Data Relation Table records, Image Sub-Class of the
Content Data
Class. Once so recorded they can be related using the Data Relation Table to
any values in
any data classes, but doing so, relates them as a fixed assembly of Data
Components, and
does not enable them to be found based on their Components, nor does it enable
their
Components to be manipulated.
In order to make images into image Data Components and store them as image
Data
Components and subsequently assemble them using the Any-to-Any machine
assembly
methods, it is desirable first to disassemble 'an image' into its image Data
Components.
Once that is done, image Data Components can be handled by the Any-to-Any
machine with
the same or similar, image-adapted methods used for handling other Data
Components.
One element of 'an image' is its shape and its 'shape' can be analyzed as
follows:
A Point can be defined by three coordinates.
A Line can be defined by two or more sets of coordinates (each
which consists of three coordinates) where two of the coordinates are
the same for all coordinate sets
A Curve can be defined by more that two sets of
coordinates where one of the coordinates are the same for all
347
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
coordinate sets and another changes by a constant value in relation to
its distance from the set of coordinates at either end of the curve
An Area can be defined by three or more sets of
coordinates where one of the coordinates in the coordinate sets is the
same for all the coordinate sets.
A Circle can be defined as a single set of coordinates
where the periphery of the circle is at a fixed distance from that set of
coordinates and where all of any coordinate sets at that periphery have
one coordinate in common.
A Space can be defined by four or more coordinate sets
where at least one coordinate is not the same in all the sets of
coordinated.
A Coordinate Pattern can be defined as any number of sets of
coordinates that are each separated from one another by distances,
where those distances bear a fixed proportion to one another. The
space occupied by any Matter can be defined in terms of a Coordinate
Pattern.
An Object When an object is defined in terms of the Space
the object occupies, it can be defined as a Coordinate Pattern where at
least one coordinate is not the same in all the sets of coordinates.
The Name of an Object or of a Coordinate pattern
May depend on 1 ) the orientation of the coordinate pattern with
respect to a stable datum or with respect to a specified limits of a stable
datum and/or 2) the relative size of the coordinate pattern. The
direction of Gravity is frequently a stable datum that dictates the name
of a coordinate pattern. For example, a box is termed a box, unless it
has objects on it that are on the opposite side of the box to the center
of gravity of earth, and then it may be called a 'table'. But it wilt not be
termed 'a table' if the objects are attached to any other surface of the
box than the surface that is opposite to the center of gravity of the
earth. A box that is termed a table in the above example, may be so
termed provided that the dimensions of the box fall within certain limits
that constitute the limits of what can be termed a table. If the box is 1
kilometer square on each side, it will be unlikely to be termed a 'table.'
From the above it is clear that the image Data Component that when assembled
with
other image Data Components, makes a shape, is a set of three coordinates. All
the other
348
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
types of shape are various assemblies of three coordinate sets. Hence
'Coordinate Set' is
one Data Class (in the Space Data Category) that is needed in order to build
an image.
Different types of coordinate sets can exist, and each type therefore, is a
sub-class of the
Coordinate Set Data Class. The Coordinate Reference Data Sub-Class (in the
Space Data
Category) of which a given coordinate set is a member, is a part of its
meaning (an the sense
described above for words). A Coordinate Set has no meaning without either a
reference
point or a statement of the coordinate type - and the type itself, when
defined, states a
reference point.
Coordinate Sets can hence be stated as part of a Data Relation Table, and
hence the
relationships of Coordinate Sets that determine a point, a line, a curve, an
area, a space, a
coordinate pattern or an object, can be stated in terms of Data Relation Table
records.
Hence, any name can be related to any one of these, and any one these can be
related to
any name using the Data Relation Table.
Hence, one type of image Data Relation Table record is a Coordinate Set
record. A
Coordinate Set record can be created as a-Sequence record in which each set of
three
consecutive fields contain one member of a coordinate set, and where each set
is in the
same sequence. Alternatively Coordinate Set records can be created as sets of
three
Associated records, in which each record contains in each field one of the
three coordinates.
In this case, the set of three Coordinate Set records are used in the same
sequence each
time.
However, a coordinate set is only one type of image Data Component that makes
up
an image. The point described by a coordinate set has no size, color, mass or
any other
physical characteristics other than defining a point in space.
A second type of image Data Component and hence, a second type of Data
Relation
Table image record is a distance that separates any two coordinate sets.
Hence, a set of
three Coordinate Set records is accompanied by a Distance Record stating the
distance
between each individual set of three coordinates. Alternatively, distances can
be replaced by
angles between any three Coordinates sets, one of which can be a reference
coordinate, and
hence, a Distance Record can be replaced by an Angle record if desired.
As soon a point has a size, it is in fact no longer a point, but an assembly
of points,
and therefore, the other characteristics of an image can only be applied to
one of the
assemblies of points, i.e. to assemblies of image Data Components. In order to
describe
conveniently 'an assembly of image Data Components' the word 'shape' will be
used in the
following description. Equally, as soon as a line has any thickness at all, it
is no longer a line
but is an assembly of a Component Assemblies. A line is itself a Component
Assembly, and
giving the line a thickness is in fact describing a shape that is an area made
of two identical
349
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
lines one of which has one coordinate different in both its coordinate sets to
one of the
coordinates that is the same in both coordinate sets of the other line.
Similarly, a circle whose
circumference has a thickness is not one circle but two circles. These
teachings need to be
remembered when describing shapes in terms of Data Relation Table records.
In order to be visible at all, a shape should have a color; and, if it has no
color, it is in
fact invisible. Visibility of a shape - i.e. the color of a shape - does not
affect the existence of
a shape.
'Color', in terms of image Data Components, is an assembly of image Data _
Components. While fight is in fact essentially measurable as a wavelength and
a strength,
due to the restrictions of physical Components, it can be workably described
in terms of Hue,
Saturation, Luminosity, and Red, Green Blue, and hence, each of these is a
type of image
Data Component record.
With Coordinate, Distance, Hue, Saturation, Luminosity, Red, Green and Blue
Data
Relation Table records as base, any object can be specified in terms of Data
Relation Table
records and if it can be described in terms of Data Relation Table records,
the records
describing it can be related to a name for that object. However, additional,
higher level
assembly records of these basic records can also be useful. Examples of such
Data Relation
Table record types are Orientation records to set the orientation of an
object, by changing the
coordinate reference point, or by specifying a displacement from the
coordinate reference
point. Relation records that can set the relation of one object (group of Data
Relation Table
records) in relation to another can also be used etc.
The advantages of stating and manipulating an image with the above methods of
the
Any-to-Any machine are:
1. Each individual image Data Component and every assembly of
Components can be accessed in a non-hierarchical manner
2. Each individual image Data Component and assembly of Components
can be named.
3. The user can control each individual image Component or assembly of
Components by using its name. If a Language Processor is installed, an image
can
be created by the user describing what he wants.
4. Any part of an image can be related to any other data.
5. Images received can be identified by Software Modules by means of
comparing their records to records of previously recorded images. If an object
is
recorded for which no matching records exist, a name can be requested for the
object,
and thereafter, the computer 'knows' that object. If the image is related to a
name,
and an image is identified, the name for the identified image can be output.
If a
350
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
computer has visual ability and an order is given concerning an object,
Software
Modules can compare received images with stored images and thereby identify
the
object referred to by the user.
6. Movement can be ordered in the standard human manner, which is to
use named objects (Data Category Matter) as Locations (Data Category Space),
i.e.
a computer that is mobile can be told to 'go to the refrigerator'.
80) Methods for Handling Similarities
In the state of the art, software classically answers a query with an all-or-
nothing,
black or white approach - the query is either true, or it is not. Fuzzy Logic
of various
descriptions attempts to overcome this, by assigning degrees of truth.
Referred to the boss 1
secretary model, a typical conversation might occur as follows:
Boss: 'Is this letter similar?'
Secretary: 'Similar to what? To other letters?
Boss: 'Yes, is it similar to other letters?'
Secretary: "Similar to what other letters?"
Boss: 'To letters from other customers."
Secretary: 'Yes. Many of them praise our new product like
this letter, but some are angry about it."
The following facts are observable in the above conversation:
1. The boss' first question 'is this letter similar?' uses the word 'similar'
and results in a query that is extremely broad The numbers of meanings of
individual
words in a page of writing in 'a letter' are probably in the order of 30 lines
x 10 words x
5 meanings each on average = 1,500 meaning Components for the words alone,
plus
further meanings for particular combinations of words. Assuming that the
secretary
can probably remember, given a little time, say 100 instances of the each
meaning
somewhere or other in what she knows, that means that the letter in question
can be
'similar' to 150,000 other items - i.e. 150,000 items that have one or more
meaning
Component or meaning Component combination in common. Consequently, it is
hardly surprising the secretary immediately attempts to refine the query by
asking
'similar to what?'
2. The secretary's last statement 'many of them praise our new product'
shows that the conclusion 'praise our new product' is one way of expressing
that she
has found certain meaning Components or meaning component combinations in the
letters she has seen that are the same as, or have a concrete relationship to
one of
the meaning Components or meaning Component Assemblies of the word 'praise'.
The example makes it clear that 'Similarity' can be defined as:
351
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Similarity' of one thing to another or other things, is the degree to
which
one has Components or Component Assemblies that are common to the other.
The Any-to-Any machine methods enable a computer to detect which items have
common Data Components and therefore, enables a computer to detect
Similarities. Equally,
the methods of the Any-to-Any machine enable a computer to detect Differences -
i.e. those
items where the Data Components are not the same. Equally, it can detect
Similarities in
items that are different, and Differences in items that are Similar. Finally,
the Any-to-Any
machine methods enable a computer to detect Identities - items in which all
the Data
Components are the same or a part of an item that is identical to another -
where the Data
Components in that part are the same as the data components in a part of
another item.
The ability to recognize Differences, Similarities, and Identities, is one
workable
definition of intelligence.
Note that the domain of fuzzy logic - the degree to which something is true -
is the
domain of the Quality of a Difference, Similarity or Identity, and this area
is covered by the
Any-to-Any machine's methods that are described under the heading of the
description of the
Quality Data Relation Table field.
81 ) Methods to Handle True and False and Partially True or Partially False
A computer should able to answer the question 'is it true that Specification
X' - 'Is it
true that the e-mails (plural) were sent yesterday?' However, the computer
'view' of the
subject of truth in the state of the art is a binary view of truth - black or
white, true or false.
However, for humans, partially true and partially false also exist and cannot
be ignored if data
is to be manipulated in a human-like manner. However, it is not possible to
process a query
containing true or false in the absence of definitions for what constitutes
'partially true' and
what constitutes 'partially false', in terms that a computer can process.
These cannot be
defined without first defining 'true' and 'false' in a manner that permits the
existence of
'partially true' and 'partially false' defined in such a manner that a
computer can process this
in terms of its binary truth system. The methods of the Any-to-Any machine to
enable a
computer to process true and false, and permit processing partially true and
partially false are
provided by the definitions used by the Any-to-Any machine as follows:
A Complete Truth is defined as
A Component or Component assembly that is stated to be a specific
Component or Component Assembly, and is the entirety of the complete specific
Component or component assembly that it was stated to be.
A Partial Truth is defined as:
352
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
A Component or Component assembly that is stated to be a specific
Component or Component Assembly, and is part of, but only part of the entire
the
specific Component or component assembly that it was stated to be.
Consequently, Completely False is defined as
A Component or Component assembly that is stated to be a specific
Component or Component Assembly, which is not any part of the specific
Component
or component assembly that it was stated to be.
Hence, the definitely for Partly False is identical to the definition of
Partly True and is:
A Component or Component assertibly that is stated to be a specific
Component or Component Assembly, and is part of, but only part of the entire
the
specific Component or component assembly that it was stated to be.
A Component is either true or false. Either 'John' exists, or he does not. But
as soon
as any Component Assembly - i.e. more than one Component , a grouping of
something -
exists, then partial truth / partial falseness become possible.
Note that these definitions can be implemented in the Any-to-Any machine,
since all
data is recorded in the form of Components and Component Assemblies and the
definitions
provided concrete standards which the application can compare, and assign a
value of 1)
True - i.e. Completely, or 2) True', Partly True / Partly False, or 3) False -
i.e. completely
False.
In effect, the methods of the Any-to-Any machine previously described using
Concept
Hierarchies to Return Nearest Truth are simply one application of the Any-to-
Any machine's
methods to manipulate Partially True, and simply do so in one specific manner -
and many
other manners of manipulating Partially True also exist.
Note that these definitions provide a firm basis for the techniques of Fuzzy
Logic, in
that it is now possible to calculate the percentage of Components that are
matched, and
based on this, choose the item in which the Components have the highest or
lowest
percentage of match, or those with any percentage of match in between. In
effect, the
methods of the Any-to-Any machine enable a computer to manipulate infinity-
base logic.
82) Methods for Handling Orders, and Methods for Handling Content in an
Any-to-Any Meaning Manipulation Engine
3. Method Required to Handle Content in an Any-to-Any Meaning Manipulation
engine.
The 'content' - for example of a letter or a book - as used so far in this
description,
has been referred to as a Data Class but mention has not so far been made of
the fact that
the 'Content' Data Class is potentially composed of a large complex of Sub-
Data Classes.
353
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
When referring to 'Content', the framework that has so far been described -
giving
orders to a computer - no Vonger applies. Any 'Content' can potentially be
recorded and can
potentially describe anything whatsoever in the universe and anything that can
be
experienced or imagined. Hence 'all the Content in the world' implies that
Content will contain
all meanings of all words and word combinations in the world - for example
every dictionary
and phrase book, and the body of every book in every library, is a member of
the Content
Data Class. Consequently, where Content is concerned, the set of meanings for
a given
word is no longer limited to meanings to do with giving orders, but includes
all meanings of
that word anywhere.
Some applications for the Any-to-Any machine - embedded applications and small
applications such as VCR control - have zero content that is of interest to
the application. In
such applications, all meanings of words are delimited by the environment -
giving orders to a
computer - to a single meaning, or at most two meanings that can be handled
easily by this
Any-to-Any machine as already described, and hence, no provision is required
for either
recording content, or attempting to turn it into user Data Components.
However, if a computer is to be able to be questioned - for example on the
contents of
the Library of Congress - and asked the question 'Did Jack love Jill?' and be
able to query its
records and reply correctly, then every word - a One-to-Many Component
Assembly of One
symbol and Many meanings - should have each meaning disassembled and stored
with it
own Concept Language symbols or Concept Language statement. While Data Classes
and
the Data Relation Table have the capacity to record all such user Data
Components, the
process of distinguishing which of all possible meanings is in use requires a
large number of
interacting rules. The complexity of distinguishing the different meanings is
beyond the
capacity of a Visual Interface and requires a Language Processor built with
the Any-to-Any
machine or by another method, that can apply rules, thereby detect meanings
and hence
construct Data Relation Table statements for any words. However, when a
Language
Processor has processed - for example, the Library of Congress - in this
manner and
recorded it as Data Relation Table records, and receives a query also
processed by the
Language processor, then this Any-to-Any machine can answer the question 'Did
Jack love
Jill.'
Between and including these two extremes, the Any-to-Any machine can handle
the
Content Data Class in a number of ways, each of which is useful in different
applications, and
in some instances, is commercially desirable. The Any-to-Any machine provides
three main
methods in which orders can be given to and questions answered on those
orders. Further,
the Any-to-Any machine provides three main methods by which content can be
given to a
computer and stored and questions answered concerning that content. These
different
354
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
methods can' be combined if useful and each of them can be implemented to
whatever
degree suits the purposes of the application designer.
With the Any-to-Any machine, it is possible to give orders to a computer
containing
applications written with the Any-to-Any machine in one manner that results in
Data Relation
Table records being created, while recording Content in a variety of different
manners, some
of which result in the Content being recorded as Data Relation Table records.
4. Basic Types of Input
In a computer environment, where an Any-to-Any data engine constructed as per
the
teaching of this Any-to-Any machine handles all operations, all data entry can
be divided into
two basic types, pure data Recording, and Orders. Hence, when Content is to be
recorded
an order to the computer is still involved and may be handled by a different
recording method
to that used for Content. In effect, there is almost no such thing as pure
content recording:
PURE DATA RECORDING
Pure Data Recording - i.e. without a specific order to record data preceding
the
recording of each item of data - only occurs in an embedded application built
with the Any-to-
Any machine where the inputs are fixed and do not change - for example, in an
application
that records data form a car engine. In this type of application, the inputs
are the same, and
occasionally, the Data Relation Table that has been recorded is read out to an
exterior
application
ORDERS
In all other environments, every activity of an application is treated as
being or
containing - at minimum - an order to record the incoming data in a Data
Relation Table
record. Even when a user only wishes to record data, this itself begins as an
order to record
the data. When an application built with the Any-to-Any machine receives input
from
someone other than a user - it receives e-mail for example - this too is
treated as being or
containing an order to record that data. The reason for this was described in
the Summary,
namely that the terms used that describe an item of data, or are part of the
environmental
circumstances at its creation may form part of the Specification that is
issued later by the user
to find and therefore, every even should be recorded.
Orders themselves also full into three types:
1 ) Orders that require only data to be recorded.
In most cases - other than when a programmer is building an application - an
order to record data may also require one or more Software Modules to find the
Data
Components to be recorded, using Data Class Tables, or to find existing Data
Relation
Table records or groups of Data Relation Table records, so that their
references can
be recorded as part of the incoming data. For example, if data is coming from
a
355
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
specific person, then the appropriate Software Module will need to find the
User
Number for that person, and record that user's number in the User Number Data
Relation Table Administration field.
2) Orders that require something to be found
Finding something also may include accepting sorting and operators at the
same time, or as an extension of the find operation.
3) Orders that require something to found, and then an Execution
performed the data that was found.
The method used by the Any-to-Any machine to do an operation - i.e. to do
an Execution - is to find the appropriate Software Module. A large part of
the'
operation of every Software Module is comparison of Data Relation Table
records,
and the finding other Data Relation Table records based on the comparison.
4) Orders that are any combination of the above three.
Hence the majority of the operations performed by the code for an application
are (in
order of frequency of use) are:
1. Finding records
2. Comparing of records
3. Writing records
4. Actual executing an order - i.e. actually sending an e-mail that is ready
to send.
Hence, whatever method may be used to record Content, a method is also
required to
order the computer, and this leads to a number of potential combinations of
methods that can
be used for recording orders and for recording Content:
- Methods To Enable A Computer To Accept User Orders: - Interface
Combinations
In the following and throughout the Any-to-Any machine, when a Language
Processor
is referred to, it is assumed that the data entry to the Language Processor is
either through
the keyboard or using Voice Recognition Software (which can also be built with
the methods
of the Any-to-Any machine and, if built this way, can be easily integrated
with other
applications built with the Any-to-Any machine). Voice Recognition is
considered to be no
more than a keyboard replacement and, if Voice Recognition is not installed,
then an Active
Element displaying a box on the screen provides a user with a place to enter
whatever he
wishes to say to the Language Processor.
ANY-TO-ANY MACHINE + NO INTERFACE AT ALL
Orders are 'given' by loading Software Modules, and the Software Modules
function in
place automatically. This is one method for an embedded application.
356
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
ANY-TO-ANY MACHINE -~- VERBAL INTERFACE ONLY
In this case, orders are given and replies received via a Language Processor.
ANY-TO-ANY MACHINE + VISUAL INTERFACE ONLY
This method has been described in Summary. It consists of Icons displayed by
Active
Elements (or displayed in the normal way in the state of the art). Icons are
connected to and
activate Software Modules in the manner previously described.
ANY-TO-ANY MACHINE + VISUAL INTERFACE + EXECUTION ASSISTANCE
Limited assistance provided by a small version of a Language Processor that
only
processes orders and does not process Content. The Language Processor contains
enough
Language Processing to distinguish between the different meanings of words
that are used in
the environment of ordering an Execution. The simplest version of this does
not process the
user's Conditions, or the Specification on which the Execution is to be done -
the user should
do that himself - it simply identifies and loads the correct Software Module.
This (smallest)
version of Language Processing works out which Software Module is the right
one to call, and
so determines the Execution to use, but leaves the user to enter the
Specification. In this
case, the Software Module that is selected, loads a suitable Screen, and its
Prompt, Label
and other records prompt the user for the Specification and any Conditions,
and enable the
user to Specify this through the Visual interface provided. This version can
be built in the
normal manner without using the Any-to-Any machine to build it, but is easier
to build, use
and control if built using the Any-to-Any machine. If the teaching of the Any-
to-Any machine
is followed, this version can be created quite with the method described in
the following steps,
which also service to describe one of the way that the Any-to-Any machine
methods enable a
computer to 'learn' The Any-to-Any machine method to create a simple language
Processor
to identify Executions - i.e. Software Modules to use - is as follows:
Method To Create a Simple Execution Language Processor (Enable A Computer
To Learn)
A Language Processor that only processes the user's order to the extent of
finding the
right Software Module to use, is termed an Execution Language Processor.
1. Make a fist of the Executions that are to be created in the application
2. Clearly distinguish between the Executions that are to be created and the
Specifications for those Executions. Ignore the Specifications.
3. Work out all the words and the wordings that a user can use to order each
Execution in the list. As an example of the application,of the method, the
following list is
the result from using this method concerning the Execution 'Fax' - as used
when giving an
order to somebody to create a fax. (Specifications are shown in parenthesis
with some of
these examples for clarity).
357
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Send a fax
1 want to fax
Fax (Joe)
Do a fax
Make a fax
Create a fax
Fix a fax ("Fix a fax to Joe')
Faxing ('I want you to be faxing Joe) (How about faxing Joe)
Let's fax
Please fax
4. if the word that best expresses the Execution (the word 'fax' in this case)
could
have another meaning when used in the context of giving an order to a
computer, work
out the possible Specifications using that could use that word (the word 'fax'
in this case).
The following is the result of using this method concerning the word 'Fax') as
used when
giving an order to somebody to create a fax):
Get me the fax
Find the fax
Show me the fax
Use the text of the fax
Put the text from the fax
Print the fax
Send the fax
Where is the fax
Send the fax (that I sent yesterday)
Take the fax
Save the fax
Which fax number (did I use)
Which fax (contains XYZ)
Where (is) the fax machine (to which I sent)
Please find the fax
Let's get the fax
5. In all these instances, the word 'fax' is being used as part of a
Specification for
another, different Execution. In fact, the word 'Fax' can be used with one
meaning - as
an action (Data Category Energy) or with a second meaning - as a thing (Data
Category
Matter). The user is not very likely to use it the Time Category meaning ('fax
time'), or as
quality (Get me the fax-like e-mail), or as an emotion ('I feel faxy'). He
might use it as a
358
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
location, Space Data Category 'Go to the fax'. Since a computer with a simple
version
Command Language Processor is unlikely to be mobile, if the action of 'go to'
is enabled
in the computer then the same method applied to 'go to' as are now being used
on the
action of faxing, will take care of working out the words to be used to
activate the 'go to'
Software Module. Similarly, the same method applied to any of the following
will also find
the word to use to activate them: Send (the fax somewhere), Display the fax;
Save the
fax, Use the fax (text), Print the fax, FTP the fax, e-mail the fax.
6. Underline the word or words that occur when the word is used to order the
action, that do not occur when the other meanings) of the word are used, and
make list of
these, including each different word or words only once. A small spreadsheet
is an easy
way to do this. The following is the result of using this method concerning
the word 'Fax'
(as used when giving an order to somebody to create a fax).
A fax
Fax (this is the word Fax without any other word coming before it).
Faxing
Let's Fax
Please fax
7. Make a User Equivalency Table for the 'User Action' Data Class, and set
each
of the word sets in the list (6) as User Data Reference for the whatever name
has been
given to the Software Module that does the action of faxing - whose reference
number is
placed in the Standard Data Reference field of the same record.
8. Repeat the above steps for all the actions to be enabled in the
application.
9. Review the User Equivalency Table and make sure there are no duplicates in
the User Data Reference fields. If there are, review the lists for the two
actions that have
the same User Data Reference value and find another word or words that does
occur next
to one of the words already used - or a words that does not occur next to one
User Data
Reference but occurs next to the other. Adjust the User Equivalents so every
one is
different.
10. Write a Module called User Order that queries the User Equivalency Table
using the users words two or three at a time (depending on the maximum number
of
words in any User Data Reference). This query takes the first X words and
queries the
User Data Reference field, then, starting from word 2, takes the next X words
and repeats
the process. Alternately, index the first word of each User Data Reference
entry, put the
users data entry into a Data Relation Table series record, word by word, and
then query
the record using the index. If the first word in the index does not match the
word in a field,
query the next field. If it does match, query the entire User Equivalent field
values against
359
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the record, beginning at the position where a match was found. If there is a
match, supply
the Standard Data Ref to the Execution executable file. If the User Equivalent
entry does
not match, continue the query process. If there is no match anywhere in the
order, call a
Software Module named 'Understand'
11. Write a Software Module called 'Understand' that, in the event no match is
found. anywhere in the users order data entry, displays a Sub-View and uses a
Help
record to display a user message such as "I'm sorry, I don't understand what
you want me
to do. This is a lost of what I can do - click on the one you wanted, or,
write only that
word in the Order Entry box on the screen'.
12. Write a Software Module called 'All Actions' that displays the names of
all
installed Software Modules. Include in 'Understand' sending a token to 'All
Actions' to
return the value the user clicks. When the user clicks one of these buttons,
it will execute
normally, meanwhile 'Understand' receives back the number of the Module
clicked.
13. Write a Module called 'What Said' that uses a Help Record to displays ~a
message to the user such as 'OK, I understand what you wanted me to do. So
that I will
understand you next time you give me the order the same way, I need to know
now which
were the CONSECUTIVE words in your order that mean you wanted to do THAT
action,
and not ANY OTHER ACTION. Please enter them in the command box, or highlight
them
in what you wrote, which I am displaying in the command Box now.' What Said
queries
the User Data Reference to make sure that entry does not already exist. If the
entry does
not exist, it passes the token to a Module called 'Write Equivalent'. If the
entry does exist,
it passes the Token to a Module called 'Resolve'.
14. Write a Module called Write Equivalent that writes the users words into
the
User Data Reference field of a new User Equivalency table record, and writes
the number
of the corresponding Software Module into the Standard Data Reference.
15. Write a Module named 'Resoive'. Resolve: 1) Displays a Sub-View and uses a
Help Message to display a message that says approximately "Those words do not
indicate to me that you want to do an ACTION, Are you sure you want me to
remember
those words as indicating the ACTION you chose? If you do, Click 'YES' and if
not, chose
some other Consecutive words in your order that indicate you want to do the
action of:' 2)
Display next to 'of' the name of the Software Module the user chose 3) Display
a Yes
button. If the user clicks Yes, sends a token to a Module called 'Overwrite'.
if the user
chooses another value in the order, returns the token containing the user
value to What
Said.
16. Write a Module called 'Overwrite' that Overwrites a record in the User
Equivalency Table, based on the values in the token received.
360
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The method described in steps (10 to 16) serves to describe the general method
of
the Any-to-Any machine for writing software that enables a computer.to 'learn'
new things. In
this,case, it is being is applied enable a computer to 'learn' a new series of
words that the
user uses to indicate a specific action. If the user had originally written
'Send a Bonga to Joe'
and the above method was in use in the computer, when the user later says 'I
want to Bonga
Bill', the Fax Software Module will execute.
Note that the above describes the method for assisting the user with high-
level
Execution such as 'Fax' something. The exact same method is used for any other
Execution
that is to be enabled in the Any-to-Any machine, such as any and all of the
Executions found
in any word processor such as: 'Apply Heading 1' 'Index', or that are found in
any
spreadsheet etc.
Note that an Any-to-Any Visual Interface has a number of ways to enable the
user to
access the 500 to 1,500 or so possible Executions that make up a normal office
application
suite (once duplicate Executions in different packages in the suit are
discounted). While
provision is made to take over the whole screen to list those that exist and
allow the user to
choose, an interface such as the Execution Language Processor just described
is based on
the reverse assumption to the assumption behind state of the art menus. State
of the art
menus are built on the assumption 'Can't be done, unless we specifically tell
you it can be
done.' Hence, in the state of the art, all Executions should be listed and
this is done in nested
menus. This method is effective when very few Executions are possible, as was
the case in
the early days of software. In the state of the art, where normal off-the-
shelf packages can in
fact do more than most users expect, the assumption that requires less
(undesirable) user
intervention is 'can do it unless we tell we cannot do it.' With this
assumption a list of all
possible actions is chiefly useful as a tool to show the user the width of the
horizons of what
can be done. However, when nearly every possible way in which a user can order
the
possible Executions is covered in the User Equivalency Table, and those that
are not covered
can be learned, then it becomes practical to allow the user to order whatever
he wants
without having to consult a menu in order to do so. Hence, this method of the
Any-to-Any
machine enables menus to be eliminated as a source of user problems. Instead
menus can
be used but with a different purpose - namely to enable a user to perform
Executions he
does very frequently - such as 'Print'. In this case menus with a relatively
limited number of
buttons are provided by a Sub-View that displays frequently used Software
Modules, so that
he can give an order faster by clicking the menu button or saying the menu
button Label, than
he can by any other method.
The same method described above - for detecting which Execution is to be done -
can
equally well be applied to On-Screen Specifications, where the possible choice
of
361
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Specifications is extremely limited. The method requires taking a given
screen, listing all the
ways any one item on it can be referred to and then following the remaining
steps as
described above
The methods described above can be combined with the method of 'feeding' the
contents of Prompts as follows. No matter what command the user enters, en
Execution
Language Processor results in the required Execution being identified, its
Software Module
called, and the Module can then display the Prompts to the user, one at a
time, and each
Prompt contains the appropriate Prompt text for one of the Conditions it needs
to be satisfied
for it to execute. Thus as soon as - for example - the interface identifies
that the user wants
to send an e-mail, if the order did not contain a person's name, Prompts can
immediately ask
for the addressee name, then for any Ccs, then for a subject fine (i.e. title)
and finally for the
Contents. This method of feeding Prompts to the user one at a time, or a few
at a time, acts
as a substitute for the inability of the computer to accept a spoken or
written language
Specification. The user has the impression that he is in full control of the
computer, is not
limited, and that the computer 'understands' him. The Any-to-Any machine
enables this to be
achieved using only the rudimentary Execution Language Processor described
above. In
fact, the user is limited, but only to the extent that the interface can not
accept sophisticated
data-mining-type commands, even though the underling Any-to-Any machine could
process
them.
2O ANY-TO-ANY MACHINE + VISUAL INTERFACE + FULL ORDER LANGUAGE PROCESSING
This next larger version of Language Processing processes Specifications and
Conditions as well as the Executions on which they are to occur. It supplies
both the
Execution and the Specification (plus any Conditions) to the Any-to-Any
machine in the form
of Data Relation Table records. This version can be built using an
extrapolation of the
method described above to build an Execution Language Processor. However, it
will prove
complex, or at best difficult to process more sophisticated Specifications in
this manner. This
is so because the more sophisticated Specifications require more than one Data
Relation
Table to express them, and hence tend to require extremely complex Views in
the Visual
Interface, Views that have to change dynamically based on the possible
branches the user
chooses in order to state them. For this reason, one method is to use a full
Language
Processor built with and in an Any-to-Any machine in order to process user
Conditions and
Specifications. However, only the more sophisticated Specifications, of a type
that would be
termed 'data-mining' in the state of the art actually require a Language
Processor. All normal
applications such as Office applications do not require a Language Processor
but can operate
well with a version of the Execution Language Processor extended to cover
simple
Specifications and Conditions.
362
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- Method enabling a computer to execute orders and display a variety of views-
suitable for different user - for a single Execution- feeding prompts to the
user.
The entire point of the Any-to-Any machine is to enable a computer to parallel
a
human in his data manipulation, and a desirable part of this is the degree to
which the
Interface can make it easier for a user to use the computer. The detailed
description will
include a description of how the Any-to-Any machine enables a screen to be
displayed that
puts greatly increased functionality at the disposition particularly of the
sophisticated user.
Less sophisticated and less educated users are not_necessarily assisted to a
great
degree by providing them with a Language Processor enabling them to order
complex
manipulations that are within the capacity of the Any-to-Any machine to
execute, but beyond
the capacity of the state of the art software to execute. Such users are more
likely to be
assisted by a Visual interface that guides them through an Execution one step
at a time.
For example, a sophisticated user who wants to send one e-mail to several
people
with different vias for each addressee, and send some Ccs to different
possible locations with
different confidentialities will not be greatly assisted by a full scale
Language Processor that
waits for him to enter or say all the details to a blank screen. Executives
who know how to
dictate, often prefer to write something themselves, as they prefer to play
around with the text
as they go and similarly a blank screen while the order is being entered wilt
not be the best
assistance that the interface can provide.
Such an executive will be best assisted by a sophisticated screen, such as the
one to
be described, which both enables him to control all aspects of the operation,
and also acts as
a reminder of things he might like to do and what he has already ordered. At
most he might
want to issue verbal instructions concerning parts of the screen. The Any-to-
Any machine
enables such sophisticated screens to be created and adjusted in any manner by
the user to
his particular preferences.
However, the low educational level, new user would only be confused by such a
screen, as he would be presented with too many things he did not understand
all at once -
the situation that occurs in the state of the art today.
Such a person would be better assisted by a computer capable of carrying on
dialogue, either using text to speech, or using the screen to display the
following as Active
Elements in a Sub-View as in the following example:
User: 1 want to send an electronic mail
Computer. (1 )OK. Who to - what is his name?
User: Joe
Computer (2) Joe who? What is his last name?
User Brown:
363
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Computer (3) OK. Do you know his e-mail 'address'?
User Oh yes. Here it is. Brown~somewhere.com
Computer (4) That's fine, I'll remember that for the future.
Now, what do you want to say? Do you want to dictate it, or do
you prefer to write it?
User I'll dictate it.
Computer OK, I'm listening, go ahead.
User: ZNXBZNXB
User Jill (i.e. name given to the Any-to-Any machine application by
the user)
Computer Yes? Are you finished?
User Yes.
Computer. OK I'll send it straight away and tell you when its gone.
What would you like to do next?
The Any-to-Any machine enables an interface to be programmed to do this, as
follows. As previously described, a Software Module - such as the Software
Module named
'E-Mail' has a Condition record stating the Conditions that should be met for
the Execution to
occur successfully. These Conditions are stated for each Data Relation Tabie
field for which
a value is required. While every Data Relation Table field is available in
each Condition
2~ Record in order to state a Condition, in practice most Executions require
relatively few
Conditions. For example, in the case of an e-mail, the Conditions that should
exist for
successful Execution are:
1. There should be a first name. If the first name has not
been recorded then to save repetition in the future,
2. A Last Name should be required also. Additionally there
needs to be
3. An E-mail address as well as
4. A Title, and
5. A Content.
There should also be an e-mail account and an active modem connection, but the
computer can check that itself and does not require user assistance to do so.
The Conditions 1 to 5 above will be stated in the E-Mail Software Module's
Condition
Record. As previously described, every Software Module can also have
Associated Prompt
and Help Records, where once again, the Prompt Data and the Help Data is
recorded for
each Data Relation Table field for which a Condition Requirement is stated in
the appropriate
field of the Condition Record.
364
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Hence, Conditions 1 to 5 above in the Condition Record are Associated records
with
the prompt Record, and correspond exactly with Prompts 1 - 5, each one in the
same Data
Relation Table field as the Condition for whose completion it prompts.
Consequently, if a Software Module called Execution Control it written, it can
use a
Token to control the Software Module 'fax' to execute one field at a time, and
only to proceed
to the next Condition requiring to be satisfied when the previous Condition is
satisfied. The
Execution Control can use an Execution Sequence Record that is an Associated
record with
the E-Mail Software Module to state the order in which Conditions and their
Prompts should
execute.
Also as previously described, Any View Module can be used with Any Execution
Module, and hence the View Module normally used by the Fax Module to display a
sophisticated screen described above for the sophisticated user, can be
exchanged for any
other View Module. In this example, Execution Control can use a Token to order
Fax to use
its Number 7 (simple) View Module instead of its Number 4 View Module that is
usually uses.
The Number 7 View Module is set up so that it displays Prompt Record fields 1
to 5 above
one at a time, putting the words in a 'Talk Bubble' that makes it appear a
screen image of a
person is talking, or using Text to Speech to speak the words or both.
With this method, the Any-to-Any machine provides the elements needed to
control an
interface so that the interface appears to carry on the conversation described
above. The
items marked 1 to 5 in the conversation are only the contents 1 to 5 of Prompt
record, that is
activated by the E-Mail Software Module logic checking the Conditions 1- 5 in
the Condition
record in turn, finding them not satisfied, and therefore displaying the
Prompt, which the
associated View Module puts on the screen as a Talk Bubble.
In this manner, the E-Mail Module, without the slightest change, can be used
to drive
either an extremely sophisticated display, or a display that a low-education
child could use
successfully without assistance. It is up to the programmer to provide
different View Modules,
which between them satisfy all ages. If the programmer is creating a general
purpose
application, then it is in his best interests to create a number of different
View Modules for
each Execution Module, assign them to different competences of user, and label
them using
the Marking Number Data Relation Table Administration field so that they can
be recognized
as to which Level of user competence they belong. He should similarly create
and label sets
of Prompt Records, Label records and Help records, so that all these things
are in
accordance with the user's competence. If he then writes a Software Module to
identify the
level of user competence when a user accesses an application for the first
time, he can then
use a field in the Data Assembly Table, User Table to state that user's Level
number. By
writing all Software Modules to check the User Level in the User Table, he can
ensure that a
365
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
given Software Module to execute a specific action uses the correct View for
that users
competence. By counting the number of time the user does a specific Execution,
using the
Last Use, Use Count and Use Index Data Relation Table Administration fields,
he can write a
Software Module to track the user's experience with a given Software Module,
and can offer
to change the user to the next more sophisticated level of View (and Help and
Prompt) when
the time required to complete the action (which is tracked in the Time Used on
Item
Administration Field) decreases and then remains stable, showing that the user
is competent
with the particular View being used. The fact that the underlying Execution -
i.e. Software
Module does not change, no matter what the View being used, and the fact that
the Software
Module does not have a fixed relationship with any particular View, enables
the Any-to-Any
machine to be used to create applications that automatically teach the user,
and place more
sophisticated options at the disposal of the user as he gains experience.
However, the user himself can build the simplest View Module, such as that
described
above, into the most sophisticated View if he wishes, and no View is fixed as
in the state of
the art, as Visual Interface Control mechanisms that will be described
shortly, are provided to
control an Any-to-Any Visual Interface, in which Any field and Any Active
Element can be
display Anywhere on the screen. The programmer may provide a Software Module
called
'View Change' that allows a user to place any number of any Data Relation
Table fields on
the screen (by placing an Active element on the screen), or to place entire
records in a similar
fashion, or put any Software Module's Icon on the screen etc. When the user
finishes
changing the View, the View he changed is saved in relation to the user's
name. Doing so
does not change the programmer-created screens, which are available at any
time.
- Methods To Enable A Computer To Handle Content
THE ANY-TO-ANY MACHINE ACTS AS DESCRIBED BUT STORES NO CONTENT AT ALL.
In embedded applications, all data can be stored as Data Relation Table
entries and
Data Classes are not required. Most embedded applications are acting as One-to-
Many
machines, and hence, the number of data types is usually limited and in
addition, data is often
only numeric. One or more Data Relation Table records can be used to record
all data, and
the Data Relation Table fields can be set up so that fields exist only for the
data types to be
recorded. Each data input can be software wired to its own Data Relation Table
field. The
advantage of setting up an embedded application this way is that, if and when
the data is read
out - as, for example, when servicing a car - the data can be read out into a
full-scale version
of the Any-to-Any machine. Once in the full-scale version the data can then be
handled in the
normal Any-to-Any manner. Additionally, the embedded version can respond
correctly to
commands or orders issued by the non-embedded version as both have the same
underlying
366
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
construction. Thus the chief advantages of using the Any-to=Any machine
methods to build
an embedded application is a) ease of construction and b) inter-operability.
THE ANY-TO-ANY MACHINE OPERATES AS DESCRIBED, BUT ALL CONTENT IS STORED AS A
SINGLE DATA RELATION TABLE FIELD OR COMPUTER FILE
In this method, Content is stored either in the Content Data Class table, or
stored on
disk with each Content Data field in the Data Relation Table record containing
a pointer to the
disk file. Both methods can be used in combination so that shorter contents
are stored in the
Content Data Class table and longer ones on disk. If the structure in which
the Data Relation
Table is built, will not accept disk addresses in such a manner that Software
Modules can
Activate them, then the disk reference can be stored in a Content Data Class
Table, and a
separate Software Module is built to access the disk and obtain the file when
required, based
on the instructions it finds in the record of the Content Data Class Table,
whose number it has
received with a Token.
The result of this method is that while all entries in the Data Relation Table
are
meaning Data Components, those in the Content Data Relation Table field are
not as Content
that has not been processed by a Language Processor is a complex Component
Assembly.
The Any-to-Any machine then behaves as previously described, with all the
advantages of
doing so, However, when a Specification contains something that is in a
Content entry itself, it
should resort to state of the art keyword searches. This is the more
fundamental reason for
the method previously described, namely that when doing something - such as
finding
something - that includes locating something partly by finding Content
containing specific
words, all the remainder of the Specification is processed first. The part of
the Specification
that refers to Content is processed last, or when there is no other part of
the Specification
available to process. In this situation, the Any-to-Any machine is novel in
the sense that it
incorporates a standard state of the art text search engine but acting on one
of the Data
Relation Table fields only - the Content Data Class field - while the
remaining fields are
searched as previously described, with the Co-Reducing Concept method. The
result of this
method is that searches on the Content field work no better than any keyword
search in the
state of the art. The difference and advantage of the Any-to-Any machine is
that with the
Any-to-Any machine, 150 or so other fields that do contain user Data
Components - and
which therefore only contain words each of which has only one meaning - are
now available
to assist in specifying an item and finding a given item. In practice, a
review of actual user
Specifications show that these invariably contain values from a number of
different Data
Classes, and values from the content Data Class form only a small percentage
of the number
of different Data Classes used in any one Specification. When the Data
Relation Table is
queried using the Co-Reducing Concept Method - i.e., the query in each field
operates only
367
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
on the Data Relation Table fields already selected by query of all other Data
Relation Table
field values - the number of items left on which to run a keyword search of
the Content field is
relative few, and therefore, rapid. Although the keyword search on the Content
field finds
words regardless of their meaning, the selection of items on which it is being
run is relatively
small, and this greatly reduces the chance that the word used in the search is
being used with
a meaning other than the meaning the user intends. In any case, if more than
one item is
found, the numbers of items from which the user should make a selection are
far fewer than
in the state of the art. Additionally, the programmer can set up an Active
Element in the
search Sub-Views he creates, in which a relatively large Active Element
displays a large piece
of content, showing where the word concerned is located, and highlighting it,
enabling the
user to decide rapidly which of the choices is the one he wants.
When a user Find is in progress, the items found at any one time are
displayed, so
that the user can interact with the computer and both the Find Specification
and the results
produced by the Find so far, act to assist him in finding the right item.
(This is termed
'Dynamic Execution Interaction). Hence if the Content field (keyword
technology) search
produces more results than the user requires, three options exist for the
user:
1 ) Click one of the items displayed to open it
2) Refine the keyword search in the standard manner
3) Add to, or modify the remainder of the Specification other than
the Content field Specification. Because such additions or changes to other
parts are handled by the Any-to-Any machine with the Co-Reducing Concept
query method, the reduction in the number of items selected is likely to very
large and rapid.
This method of handling Content - storing Content without Language Processing
it - is
adequate in practice for the great majority of applications constructed with
the Any-to-Any
machine, and especially for most commercial and private use applications such
as typical
office suite applications. It is also adequate for use of the Any-to-Any
machine to construct
an Internet search engine. A great deal of what an Internet search engine
terms 'Content' is
in fact not content at all but is in fact an entry in one or other Data Class.
If an Internet search
engine is constructed with the methods of the Any-to-Any machine, and
preloaded with a wide
selection of values in each Data Class, then a Software Module can be written
to convert an
existing Internet search engine database into Data Relation Table format. As
the Software
Module receives records from the existing database, it converts them into Data
Relation Table
record format and then saves them into the new Data Relation Table. This
conversion can be
done by an unlimited number of machines simultaneously, since the resulting
Data Relation
Table records are all the same format and can therefore all be copied into a
single Data
368
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Relation Table. If the user is presented with suitable screens to access the
finished Data
Relation Table, and the search engine is written per the teachings of the Any-
to-Any machine
and searches using the Co-Reducing Concept Method, then the Any-to-Any machine
enables
Internet searches to be an order of magnitude more accurate.
An additional advantage of the Any-to-Any machine is that, in the state of the
art,
websites often have to manually indexed before they can be entered into the
search engine
database, and this procedure is slow. At the present time in the state of the
art, most Internet
search engine databases are months behind and hence, even the low standard of
search
they produce is inaccurate. If the Any-to-Any machine methods are applied to
'indexing' web
sites, then complete sites can be downloaded automatically to the search
facility using state
of the art technology. If all pre-loaded Data Class entries are placed in a
single table that
contains the entry, plus its Data Class number and reference, then an 'Index'
software Module
can go through words in a site one at a time and place the Data Class
reference number in
Data Relation Table records it constructs.
As already described for creating an Execution language Processor, a reduced
version Language Processor can be constructed rapidly to distinguish between
the more
common meanings of a given word - such as 'e-mail' the action, and 'e-mail'
the thing. If the
'Index' Software Module uses such a rudimentary Language Processor, then the
Any-to-Any
machine as a whole, applied to Internet search engine construction, enables:
1) Any number
of machines can process different sites simultaneously and 2) Enables Internet
Search
Engine databases to be kept up to date without requiring manual indexing. and
3) Enables
Internet searches to be far more accurate than in the state of the art
CONTENT IS STORED AS A BLOCK AFTER BEING PROCESSED BY A LANGUAGE
PROCESSOR. "DATA CLASS CODING"
With this method, the Language Processor converts the normal Content into a
Language X Concept Language. The Language Processor uses rules to determine
which
meaning of each word is use, and then assigns that word the corresponding
Language X
Concept Language symbol or symbols for that meaning. This gives the general
effect of a
special kind of annotation in the text, and has similarities a special format
used to store a
state of the art word processor file, where not only is the word stored, but
other aspects of the
word are stored also - its visual appearance and position are also stored. In
this Language
Processing application the things that 'also stored' with each word are
numerical codes
indicating the Data Class of the word. Since many words contain meanings with
more than
one part, such Language Processing results in the addition of Language X
Concept
Language symbols for the other parts of the meaning of each word also. Text
stored in this
manner is essentially a form of the original language in which each of the
words in the content
369
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
are decompressed and represented by Concept Language symbols that between
them,
contain all the meaning Data Components of the word. This method is a further
description of
Data Class Coding previous described.
This method disassembles a Content text into user Data Components, but does
not
state the relationship of any one Component to another. The method splits the
content into
its Component Data Class entries, but does not do the next stage of Language
Processing -
constructing Data Relation Table records that state the precise relationships
of those user
Data Components to one another. When this method is in use, one option is to
store the
content twice, one in a Content Data Class Sub-Class field called 'Content,
Formatted' and
the original unformatted text in another Sub-Class field called 'Content,
Original', or
alternatively, to write the Field Logics operating on the Content Data Class
in such a manner
that the Data Class Codes are removed before display, and before re-using the
text in a
manner that results in the text going to a computer that does not use
applications written with
the Any-to-Any machine's methods. The advantage of writing the text twice, to
a Content,
Original and Content Formatted data relation table fields, is that the
necessity to remove the
Data Class Coding from the text before viewing or external forward is avoided.
The
Formatted field can be used in searches for meaning, while the Original field
is used to
display the search result to the user, and this overcomes the problem that the
Formatted field,
while perhaps semi-comprehensible, will be much less clear for the user than
the same text in
the Original field.
This method enables Content to be searched with what is termed Key Meaning
technology. I.e. instead of searching the Content for words, as done by
Keyword technology,
the Content can now be searched for Key Meanings using almost the exact same
procedures
as used in Keyword searches. The only difference is that the query on the
Content field itself
should be processed by the Language Processor so that the correct query is
issued.
As per 'The Interchangeability Principle & Method of Data Field and Record', a
Data
Relation Table field can either 'be' a field or 'be' a Data Relation Table
record. In other words,
it can either contain a Data Class value, or point to a Data Relation Tabie
record of its own
type that contains the Data Class Values. This method can be used to advantage
when
looking for - finding - meanings in Content that has been processed in the
above manner into
user Data Components. When this method is in use, and the user wishes to
search for
something, the appropriate View Modules, instead of displaying one field into
which to enter
keyword search values for the Content field, displays as much as needed from a
single Data
Relation Table record, but applying it only to the Content field. All Data
Relation Table fields
are now available for the user to enter Specifications in any of the different
Data Classes, but
whatever entries he makes, apply only to the Content Data Class. The queries
based on the
370
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
values the user enters in this manner then look for Content items in which all
the user's
Specifications are found, and in order to show the user the results, a large
Active Element is
opened to show the user the resulting Content that was found. This method is
applicable
where large volumes of Content have to be searched - such as a library - that
has been Data
Class Coded and is an improvement over keyword technology, but not as good as
full
Language Processing of the Content. To assist in such searches a parallel Data
Relation
table record display can be provided, enabling the user to specify Operators
etc, and another
to allow him to specify the separation allowed between one value and another
in his
Specification, or the separation for all values - such as that they should
occur in a single line,
paragraph or Chapter. If the material in the library has non-Content entered
into a standard
Data Relation Table, then searches can be relatively accurate even though the
volume is
large. The same principle of Data Class Coding can also be applied to Internet
search
engines, which can automatically Language Process and Data Class Code the
content of
Internet sites.
This method enables all searches to be done based on meaning, with the
disadvantage that the relationships between individual meanings in the
Specification can be
found, but relationships between individual meanings within the Content can
not be found.
The first advantage is accurate Content searches that will, for example, be
able to
distinguish between the different meanings of the word 'letter' as previously
described. As
another example, if a user requests all items that meet a certain
Specification and contain
within their content, 'furniture', the search will find all items that mention
chairs, tables etc,
and do not mention the word 'furniture' at all. (As described previously, the
Concept
Language statement for a word, includes stating in some manner its Concept
Hierarchy.
'Chair' is a type of furniture and, when the query for 'furniture' is entered
in the Matter Data
Category part of the Data Relation Table query entry, will find all values
that contain 'furniture'
as part of their Concept Hierarchy. Since 'chair' and 'table' when used in the
matter data
category contain 'furniture' in their Concept Hierarchy, they will be found
and returned.
However, if the user enters the word 'chair' in the Data Relation Table query
entry, in the field
for Position (of a person) it will return ail those Positions for which
'chair' is a synonym - such
as 'Professor of Engineering.' Similarly , the word 'table' used in the Action
data category will
not return instances of furniture but instead (as a synonym for 'delay' or
'schedule for the
future' or 'agenderize') will return items which have been placed on the
agenda.
The further advantage is that Execution can then be related to meaning in the
content.
As previously described, a user can use User Condition Records to state the
Conditions that
he requires for an Execution to occur and thereby relate Execution to his
Conditions: 'If Data
Relation Table field Condition 1,2,3,4' then do (Software Module) X'. The
method for Data
371
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Class Coding of Content described above enables a computer to Execute user
Conditions
that include the meaning of the Content as a part of the Condition (or as part
of the
Specification) . Without Data Class Coding, a command such as 'If my wife e-
mails me and
says 'We did it', then X, Y Z' will not execute if the wife says in her e-mail
'Success! Let's
celebrate' but will execute correctly if Data Class Coding is in use on
Content. This ability can
be of importance in business in orders such as 'af our clients have contacted
us wanting to
purchase ABC, then (do) XYZ'. If a client had sent an e-mail saying 'I want to
buy ABC' that
e-mail will not be found if Data Class Coding is not in use, but will be found
if it is in use.
CONTENT IS PROCESSED BY A LANGUAGE PROCESSOR AND OUTPUT AS DATA RELATION
1 O TABLE RECORDS
When full Language Processing is in use, after the Language Processor
processes
Content into Data Class Format (i.e. assigns the words in the content to their
correct Data
Classes), it then further manipulates the Data Class Formatted text to record
the relationships
of the user Data Components in Data Relation Table records. Such Data Relation
Table
records are then recorded in the Data Relation Table in use as Data Relation
Table records,
User Data type, Content Sub-type, Sub-Sub-type Text. If this method is used,
the resulting
construction is completely an Any-to-Any machine with consequent advantages.
In practice, the main advantage of full Language Processing is that it enables
the
computer to record, use and Execution user commands that 1 ) are too complex
for a Visual
Interface to accept and 2) Can be as complex as the user wishes. They will
execute
successfully, provided only that for each Execution required in the command, a
Software
Module exists capable of doing that Execution. Whether this Condition is met
is easily tested
by identifying the Executions that the user orders, and - per the standard
Execution
procedure - checking that this Execution exists, and that the Execution can be
done on the
Specification the user states for it. In this manner, such commands as the
following will be
corrected before Execution is attempted on the whole order: 'if my wife calls
and says 'we did
it', put the modem in the frying pan and make the printer into hamburgers'.
83) Methods to Enable a Computer to Handle Unlimited Data: Scaling the
Any-to-Any machine and Applying the Unlimited Principle
As remarked in the Background, humans manipulate data in an Unlimited manner,
and is, in fact, only limited in his normal activities by physical limits.
When manipulating data
a human can do so in a manner that takes no account of physical limits. He can
for instance
say, or write a novel in which he says: 'in the exact same space in which the
tree was
growing, five other trees of almost the same shape were growing to at the same
time.' The
data the human stated is not possible in the physical universe, but is
possible in the human's
372
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
imagination, and can be stated on paper, and is data like any other and
therefore, may be
required to be manipulated by the Any-to-Any machine.
Hence, it is axiomatic that a computer, in order to be able to manipulate data
in a
human-like manner, should also be able to manipulate the human's data in an
unlimited
- manner. This principle is codified as the Unlimited Principle and is defined
as:
A computer, within the limits of the capacities of its hardware, should never
limit a user in a manner that he does not limit himself.
The Any-to-Any machine includes a number of methods for ensuring that the Any-
to-
Any machine itself implements this principle, and the programmer writing
software should
take care to ensure their software follows the Unlimited Principle.
Because the entirety of the Any-to-Any machine concerns data manipulation, the
entirety of the contents in all Any-to-Any machine structures are data of one
sort or another,
and every method for allowing the structure to expand has a corollary method
that permits the
view of data to contract. 'Expanding data' in the Any-to-Any machine consists
of methods
that allow any data or grouping of data to be amplified - i.e. further detail
added to any part.
For example, any field in Any Data Relation Table record can be expanded into
a complete
Data Relation Table record. 'Contracting data' in the Any-to-Any machine,
consists of
methods that allow any data or grouping of data to be related to other data so
that the original
data or grouping is only a small part of the data recording that refers to it.
For example, a
Data Relation Table record can be created that that contains as only one of
its fields the
reference for a record that itself references many other records. None of the
methods for
expanding and contracting data are intrinsically hierarchical, but hierarchies
can be imposed
on them - a hierarchy is simply one of several methods of viewing data.
In the summary, it was stated that any Data Relation Table field can be
expanded to
be a Data Relation Table of its own type. The corollary truth is that the any
Data Relation
Table record containing only one value can be contracted and referred to in a
Data Relation
Table field.
Viewed from the point of view of a Data Relation Table field concerned
pointing to a
Data Relation Table record, the Data Relation Table record to which it points
is an expansion
of its data. Viewed from the point of view of the record being pointed to, the
field that points
to it is a contraction of that record's data.
Methods of expanding (and hence ways of contracting) Tables, records and
fields in
the Any-to-Any machine are inevitably also ways of relating data.
These methods are as follows:
373
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
5. Method to Enable a Computer to Use Unlimited Numbers
To ensure the unlimited requirement of the Any-to-Any machine as far as
reference
and other numbers used by the Any-to-Any machine are concerned, the last digit
position in a
number is not used as part of any reference. This last digit position is
reserved for a digit
stating that this remainder of the number is an earlier part of another number
and strings
together with another number that forms the end part of the whole number. If
needed, the
manner of that stringing together is stated by the particular number that is
the last digit, or, if
one digit does not provide enough possibilities, it is used.as pointer to a
record that does. A
fast digit position value of zero states that the number is not strung to
another number.
Similarly, the first possible digit position in a number a number is not used
as part of
any reference, but is reserved for a digit stating that this number is the
latter part of another
number and strings together with that other number which forms the first part
of the whole
number. The manner of that stringing can be stated by the particular number
that is the last
digit, which either acts to state the manner or acts as a pointer to a record
that does state the
manner.
This mechanism is used to ensure that a problem similar to the Y2K problem
does not
arise.
- Methods to Enable a Computer to Expand and Contract the View of Data.
Data Relation Table record expansion is one of the general methods for
ensuring the
Any-to-Any machine remains Unlimited and is the general method of enabling any
data
structure to become larger or smaller and therefore the data it holds to
become larger or
smaller also.
A Data Relation Table field expands or contracts in the following sequence:
A Data Relation Table field
1
Table 3
A Data Relation Table can be expanded to be a Data Relation Table record
2
A Data Relation record of a single type can be expanded to be a Data Relation
A Data Relation Table can be referred to in a Data Relation Table field
of a senior Data Relation Table
4
A Senior Data Relation Table field can be expanded into a Senior Data
Relation Table record 5
A Senior Data Relation Table record can be expanded and made into an entire
Data Relation Table of its own, etc 6
374
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
This expansion - and hence contraction - sequence can continue without limit,
in
either direction. Looking from a viewpoint of a field in the last - most
junior - Data Relation
Table, that field can be infinitely contacted without limit by continuing the
sequence upwards.
The method by which this expansion and contraction is achieved is as follows:
As previously discussed, a Data Relation Table field can contain a reference
number
pointing either to a Data Class value or to a Data Relation Table record of
the same type as
the field concerned.
Additionally, a Data Relation Table record of a specific type can be stored in
a Data
Relation Table dedicated only to its own type of record. Thus, if there are
150 fields in the
basic or senior Data Relation Table there can be at least 150 Data Relation
record types,
each or any of which can be recorded in its own Data Relation Table, dedicated
exclusively to
its record type, and therefore, at least 150 Data Relation Tables can exist,
each of which
contains records of one of the 150 types of Data Relation Table records. There
is no
requirement, other than speed of processing requirements, for these Data
Relation Tables all
to exist on the same machine. Whenever this type of method is used, then a
Virtual Record
Converter Software Module of the type already described should be written that
makes the
150 Data Relation Tables look like one table as far as all other Software
Modules are
concerned. When more than one Data Relation Table is used Field Concordance'
is
maintained as follows:
1 ) All the Data Relation Tables in the group use the same single set of
Data Class tables.
2) A given number of a field in each Data Relation Table contains the
same type of data in the same number of field in each of the Data Relation
Tables.
This is desirable method of the Any-to-Any machine is termed 'Field
Concordance'
and is desirable as it ensures inter-operability of tables and Software
Modules. A
Virtual Converter Module would become extremely complex if a given type of
data .
were in different place sin different tables - for example in one table the
time and date
was field 55 and in another time and date was in field 97
Data Relation Tables themselves can be expanded and contracted in the number
of
fields they contain. As per 'The Interchangeability Principle of Data Type and
Class' a Data
Class that is X Data type can be either:
1 ) Included in the Data Relation Table as a Data Class, with other
adjacent fields used in the Data Relation Table to state the Type, and Sub-
Type and,
if need be the Sub-Sub-Type, or alternatively
2) Each Type can be assigned its own field. The disadvantage of doing
this, is that either all the Types are each assigned their own field, in which
case, the
375
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data Relation Table, and the Software Modules to go with it, expand very fast
indeed,
or alternatively only some of the Types are given their own field. In the
latter case,
logic then can have to look in two places in order to be sure of finding a
value - once
the main field for the Data Class and once in the field dedicated to a values
in that
Data Class of a specific Type. It can be justifiable to do this in certain
specialized
applications, where a particular Type is required very frequently and the
increased
speed of an average search outweighs the time penalty of sometimes having to
look in
two places, and the penalty of finding another now requires a Virtual Record
Converter
in order to read its Data Relation Table.
Which of these solutions to use is a choice for the programmer to make. The
general
principle is to make a Data Sub-Classes out of any Type of a Data Class' value
that is likely to
form a very frequent member of a Specification. The largest part of the Any-to-
Any machine's
operations are query operations, and anything that is a Data Class or Data Sub-
Class or Data
Sub-Sub-Class can be queried simultaneously as part of a Co-Reducing Concept
Method
query. If a Specification may contains several different Type values from a
given Data Class
in a single query, then double Data Relation Table records - one record to
record each single
value, or a Sequence record to record all the values for that field, will be
needed frequently.
Similarly, double queries will also be needed frequently to query for the
second and
subsequent values in that field or to query the List Record.
Data Classes can be expanded almost infinitely in this manner, and whether or
not to
make a Type into a Data Sub-Class is a question of judgment in relation to the
application in
question, remembering also the increase in complexity of the Visual Interface
that may occur
as a result of doing so, and the maximum number of fields that is permitted by
the storage
structure housing the Data Relation Table.
- Methods to Enable a Computer to Join Data: Chaining Data Relation Table
fields, records and tables together.
Chaining, or stringing one thing together with another of the same thing is
another
general method of enabling any data structure to become larger or smaller and
therefore the
data held to become larger or smaller also.
Chaining or stringing is the general procedure of joining one of something
onto
another of the same thing or onto another of something else.
CHAINING FIELDS
Fields can be chained to one another using unlimited numbers as already
described,
but can also be chained to one another using Sequence records. Sequence
records
constitute a list of something and essentially a Sequence record can consist
of a list of
reference numbers for anything in the Data Relation Table. In other words, a
given field can
376
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
sometimes to contain a large number of values of a given type. For example,
one person
may describe another with a long string of Qualities. 'Joe is short, heavy,
good, fat,
expensive, loud-mouthed, hungry, not greedy' etc. The available choices are:
1 ) Create a Sequence Record containing all these Qualities, and put the
record number of the Sequence record in the Quality field, or
2) Create a Sequence Record containing all these Qualities, and put the
record number of the Sequence record in the Quality field together with the
first of
these Qualities, i.e. using a Combined Number in the Quality field, or
3) Create a separate Data Relation Table record for Joe, for each of his
qualities.
(Note that the first two cases are methods to state that such a series record
is
associated with a particular data record. Each of these has their own
advantages and
disadvantages and which method is used depends on the data the application is
likely to
receive. (It should be noted however, that when there is a choice of methods
to do only ONE
of the methods should be used consistently, otherwise, Software Modules
written to operate
with another method will not operate with another, unless a Virtual record
Converter Module
has been provided to ensure that they can. If an application operating with
one method,
receives Data Relation Table fields from another application that applies a
different method,
then, on arrival, and before recording, the incoming Data Relation Table
record should be
converted by a Incoming Record Converter to the method in use in the receiving
Data
Relation Table before being recorded. An Incoming Record Converter acts
similarly to a
Virtual Record Converter, with the difference that it actually writes Data
Relation Table
records, rather than converting records and putting them into memory.
The programmer should however, pay attention when using Sequence records
because as soon as references are put into a Sequence record, the references
in each field
of the Sequence record no longer has any relationship to the Data Relation
Table field in
which they are found, and therefore, Sequence Records are excluded from all
normal
searches. In order to include them, a mechanisms such as an Associated Record
Table - as
previously described - needs to exist, or a search Modules need exist that can
search in the
normal manner - for example, to locate Sequence records of a given type such
as Quality
Sequence records containing Quality values - and then search the found records
in Row
search looking for all instances of the required Quality.
If it may be desirable to keep the references in one or more fields of a
Sequence
Record related to its Data Class, then either:
1 ) A Sequence Record is used and is related to its parent Data Relation
Table record using the AND WAS V field in the Data Relation Table. (An AND WAS
V
377
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
field, states that the record is joined to another - expressed by AND - that
the other
was its parent - expressed by WAS - and that it is joined Vertically -
expressed by V
- to its parent, in other words, its values are an addition to that record,
and not added
on to the end of it, which is coded in an AND WAS H - H for Horizontal -
field. Which
of the fields of its parent record it belongs to is contain in the AND WAS V
reference
number.
2) A Sequence record is not used at all and instead one Data Relation
Table record for each item in the list and if needed to group there together
using the
grouping methods to be described, or
3) A Data Assembly Table is used. If using a Data Assembly Table for a
given Data Class then the Data Class reference values not entered into the
Data
Relation Table record directly, but entered in the Data Assembly Table. The
Data
Assembly Table then consists of a record number - that is used in the Data
Relation
Table field for that Data Class - and a sufficient number of fields to
accommodate
most foreseeable needs Even so, in case that number of fields is exceeded, a
Data
Assembly Table should include the provisions described in this Any-to-Any
machine
for Chaining Records, so that one record can be extended if need be. In
addition the
Data Assembly Table - which is really a miniature Data Relation Table - can
include
its own Sequence Records stating which Data Relation Table records use the
particular combination of one type of value that is recorded in each of its
own records.
If this method is used, all Data Assembly Tables of this type are effectively
an
extension of their own Data Relation Table field.
Whichever method is used, a Virtual record Converter is required to ensure the
entirety of the Data Relation Table operates in the same manner, as far as all
other Software
Modules are concerned.
The above description covers the standard methods that can be used by the Any-
to-
Any machine whenever a list of something is required, such as a list of town
names, a list of
town to visit etc and whenever a Sequence Record is mentioned, a Data Assembly
Table
created in the above manner is an equally acceptable solution. However, these
methods are
not used, when something else, other than the thing itself also needs to be
stated. Data
Assembly Tables should preferably not contain data outside their own Data
Class as
otherwise, sooner or later, the values for a given Data Class can be found
almost anywhere in
the system and software becomes impossibly complicated. With very limited
exceptions, a
Data Assembly Table only contains values in its own Data Class, and even with
these
exceptions, never ever contains values from more than one data Category. If a
Data
Assembly Table needs to contain values from a variety of data Classes, and
especially if it
378
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
needs to contain values from more than one Data Category, a Data Assembly
Table is not
used at all, and the assembly is performed in a Data Relation Table record of
a specific type.
A Data Relation Table is the only place in the Any-to-Any machine where Cross
Data
Category assembly is permitted.
CHAINING RECORDS
Records are chained together using 'AND' and 'AND WAS' Data Relation Table
Administration fields as previously described. In this method the AND field
contains the
number of the next record that is to be chained together with another record.
The AND WAS
field contains the number of the record that was the previous record. In this
manner, both
records refer to one another. Addition any "AND' field can contain a reference
to the field in
the other record it is an AND to (in the case where it does not apply to the
whole record) and
this is expressed as either as a Combined Number or in a separate field.
The Data Relation Table field contains two pairs of AND, AND WAS fields. One
Pair
is termed AND H, AND WAS H, the 'H' standing for horizontal and the other pair
is termed
AND V, AND WAS V, the 'V' standing for vertical.
'H' or Horizontal chaining is used either for records that are the opposite
sides of
something - opposite sides of a communication for example - or for the next in
sequence of
something - for example, the next statement in continuous Content processed by
a Language
Processor.
'V' or Vertical chaining is used when a single Data Relation Table record
needs to
contain more than one value in one or more Data Class Fields, in order to be
complete. 'V'
chaining essentially states, 'although this is 2 records, treat it as one.'
AND as well as AND WAS records can also have Data Relation Table records of
their
own type. If this method is used, then the AND field contains a pointer to the
AND record and
the AND record is a type of Sequence Record listing all the record numbers
which are the B
records to the AND record's A records. When an AND WAS record is used,
similarly, the
AND WAS field contains a pointer to an AND WAS record. The AND WAS record is a
type of
Sequence Record listing all the record numbers that are the A records to the
AND WAS
record's B records. If a single AND or AND WAS record is not sufficient, then
the AND or
AND WAS field in the AND or AND WAS record points to a further record of the
same type.
In this manner any one record can be related to any number of other records,
either
as a parent or as a child. Additionally the relation system is not
hierarchical as Any record
can be related to Any other record. Furthermore, when a user selects a record
that is in the
middle of any AND, AND Was sequence, he can trace it either backwards or
forwards.
When a Software Module is looking for all instances of a given record number,
then it
uses a particular Software Module to do so termed Record Instance. Record
Instance when
379
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
first called calls another Software Module termed Instance Index. The Module
Instance
Index, receiving a token from Record Instance, searches the whole Data
Relation Table for
record numbers occurring in the Data Relation Table anywhere other than in the
Record
Number field, and makes an index of them showing the record number and field
in which they
occur. Once activated, Instance Index uses its own Start Tirne field to set
its own Start time
and schedules itself for periodic Execution. Since records are not changed in
the Data
Relation Table, when Instance Index is called in the future by Record
instance, it only should
index records that have been added since it last indexed the Data Relation
Table.. The
Record number it last indexed is recorded in the Last Record number field in
its own
Execution Record.
When Instance Index reports complete to Record Instance, Record instance looks
up
the record number it wants in the Record Index constructed by Instance index.
Depending on
the token it has received, it either returns the numbers of the mother records
containing those
record numbers, or queries the Data Relation Table to locate them, and passes
the remainder
of the query to the logics in other fields processing the remainder of the
query.
CHAINING GROUPS OF RECORDS
Groups of records are chained together by grouping the names of each group in
a Sequence
Record. The methods used will be described in detail under the description for
the Group
Data Class.
2O CHAINING SPREADSHEET RECORDS
Spreadsheet records are chained together using AND and AND WAS V and H fields.
A Spreadsheet in the application is not any fixed size as in the State of the
art spreadsheet
packages, and is not limited in this way. A spreadsheet in the application is
as large or as
small as it needs to be.
CHAINING DATA RELATION TABLES
Data Relation Tables themselves are chained together vertically - i.e. made
longer -
using the Data Relation Table Administration Fields, Data Relation Table
Identity Number and
the field Sub-level Number. As will be described when describing the Data
Relation Table
Identity Number field, each Table is given a unique Identity number and in
addition, Data
Relation Table record number 1 is the record for the Data Relation Table
itself. The Sub-
Level number in this record contains the number of the latest Table to be in
operation and
hence, when only one Data Relation Table exists, this number is 1. When two
tables are
joined, the Software Module that joins them sets the number of the Sub-Level
Field to the
next number available - i.e. 2. When Data Relation Tables are joined in this
manner, the
Software Module that does the join should activate a Virtual Record Converter
Module, type
380
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Table, Sub-Type Vertical, to make the join transparent and join the two tables
into one logic
table.
Data Relation Tables can also be chained together horizontally if need be. As
discussed above, 'The Interchangeability Principle of Data Type and Class' can
lead to a very
large number of Data Sub-Classes and Sub-Sub-Classes, and the process of
dividing a Data
Class can potentially continue indefinitely leading to a very large number of
Data Classes that
exceed the number of fields that the host database can offer. In this event,
Data Relation
Tables may have to be chained together horizontally, side by side. When Data
Relation
Tables are joined in this manner, the Software Module that does the join
should activate a
Virtual Record Converter Module, type Table, Sub-Type Horizontal, to make the
join
transparent and join the two tables into one logic table.
METHODS TO AVOID CHAINING DATA RELATION TABLES
However, the Any-to-Any machine contains methods to avoid the necessity to
Chain
Tables together, as follows:
One method that effectively enlarges the capacity of a Data Relation Table is
to
remove all the Administration records to their own Administration Record
Table, and then
create a fixed relationship - using standard state of the art database
relation technology -
between the Administration Table and what is now the User Data Table. This
frees up all the
fields that were used for Administration and makes them available for use as
Data Class
fields.
Another method is to remove the Administration fields for each record and make
then
into a separate Administration Record for each record, so that an
Administration Record
accompanies every record. This also frees up all the fields that were used for
Administration
and makes them available for use as Data Class fields. Both these methods
require Virtual
Record Converter Modules to make the resulting records appear to software as
they would
normally appear.
The remaining method is to split the Data Relation Table itself across two or
more
tables, using state of the art relation technology to create a fixed relation
between the record
numbers in the tables concerned. Again, a Virtual Record Converter Module is
needed to
handle the resulting split tables.
With any of these methods, Data held in one application with one Data Relation
Table
that is a horizontally joined pair can be automatically converted into format
required by an
application operating in a Data Relation Table that is not horizontally
joined, using a suitable
Record Converter Module type. This is possible, as the only reason for
expanding tables
Horizontally, is to provide more room for Data Class Sub-Types, so that a
specific Type of
value in a data Class has its own field. Converting records from a Data
Relation Table that
381
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
has a field for a specific Type, to a Table that does not have such a field,
requires the
Converter Module to write the value found in the field, into the Data Class
for the converted
record, and write the Type into the Data Class Type field, using and chaining
a second record
to do so if necessary. Converting in the other direction requires a Converter
Module that does
the reverse process.
Two Data Relation Table can 'talk' to one another or pass data back and forth
between then by passing data through a pair of suitable Record Converter
Modules that
operate in the above manner.
CHAINING AN UNLIMITED NUMBER OF DATA RELATION TABLES AS A TRANSPARENT WHOLE -
1 O 'IF NOT FOUND'
In practice, humans automatically impose their own limits on how much data
they are
willing to keep in locations other than their own. While one single
International Data Relation
Table complex could - in theory - be created with the Any-to-Any machine, and
hold all known
data, this is unlikely to happen because humans have a proprietary view of
their own data and
are generally unwilling to let the data exist on a machine not under their own
control. Even
within a single company, each unit generally wants to keep its own data.
Further, the more
data that is held at a single site, the greater are the communication problems
at that site in
connecting to other sites, and equally the greater are the risks of physical
damage.
For this reason is quite acceptable to a human, and even expected, that if
data is
unavailable on-site, that the application should go somewhere else to get the
data and the
Any-to-Any machine includes methods for doing this automatically, without
requiring user
intervention and these are named "If Not Found' methods.
To describe the method by example, suppose that a user asks an application for
the
telephone number of a John Smith in the Outer Hebrides, a value that is highly
unlikely to
exist in many of the world's computers. The user would not object to the
application looking
for the data he requested elsewhere.
For this reason the "If Not Found' field is one of the Data Class Table
Administrative
fields and therefore, a record type 'If Not Found' also exists in the Data
Relation Table. Like
any Data Relation Table record, an If Not Found record can exists as if Not
Found Condition,
Execution and Specification record types. Equally, an If Not Found can exist
as an AND
record that states the Condition plus an AND WAS records that state a number
of alternative
Specifications for actions to try in turn, each one with a Specific Software
Module Name in its
Software Module name field. An AND record can, as previously stated, have an
unlimited
number of AND WAS records, and these can effectively be a list an unlimited
number of
different actions that can be taken to attempt to locate the data that was not
found.
382
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
In the same way that any Data Relation Table field can be a Record of that
type,
similarly any Record of a given type can have its own Software Module or
Modules type to
manage its type of records if desirable.
Equally, every Data Relation Record has an If Not Found Administration field,
which
can contain an If Not Found Software Module Execution record number, or point
to an If Not
Found Condition records that listed the Execution Record number of a list of
If Not Found
Modules to try in turn. Further, a Condition Record is often paired with a
Director Record as
an Associated Record that states a record number for an action to take if a
Condition is not
satisfied. The Director record can state either an if Not Found Execution
Record number or
an Find Not Found Module that tests all If Not Found Condition records to find
which one is
met and use its Associated if Not Found Director record to activate either a
specific If Not
Found Module or a an if Not Found Condition record that lists if Not Found
Modules to try in
turn.
To give an example of an alternate general method of If Not Found functioning,
suppose that the user does request the telephone number of John Smith in the
Outer
Hebrides and this is not found. The actual value that was not found, was 'John
Smith'
meeting the Specification given (' in the Outer Hebrides). Other 'John Smiths
might have
existed in the Data Relation Table, but not the one being looked for. The
failure to find the
name required is detected by the Find Post-Execution Condition Record, as
previously
described. This failure causes Post-Execution Find Failure Module to look for
and activate
the If Not Found Software Module whose number is stated in the Director Record
that
accompanies the Failure Condition Record. This activates the "If Not Found Tel
No' Software
Module. The If Not Found Tel No Software Module - like every other Software
Module has
Condition Records with it, and compares the If Not Found Tel No Condition
records to the
users' data entry, and find that a particular record is matched, because the
Concept Hierarchy
of 'Outer Hebrides' is 'England'. If it does not find any match, then its
accompanying Director
Records will activate a Software Module that find out from the user where
'Outer Hebrides' is,
enters the appropriate values and returns Execution to If Not Found Name
Module enabling
that Module to find a match.
One of the accompanying If Not Found Module AND record could state, for
example,
the URL and Data Relation Table number for a Telephone Director in England, as
well as the
name of the Software Module required 'Connect URL'. 'Connect URL' can then
connect the
URL and then return Execution to if Not Found Tel No. If Not Found Tel No,
receiving the
Token stating it is connected, transmits a Token Calling a remote Software
Module also
named 'FIND' plus the Data Relation Table record of the 'Not Found' part of
the users
Specification. Remote 'FIND' executes the query, and returns the token
containing the found
383
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Telephone Number. The local If Not Found records the number in the local Data
Relation
Table, and return its Token to the Local FIND Module, stating that the
Condition that failed
can now be met. FIND reports the telephone number to the user, or performs the
Execution
that required it as the case may be.
Alternatively, supposing that a local telephone company runs a system using
the Any-
to-Any machine, then the users If Not Found Module can pass the record
containing the
Specification that was not found, to the local telephone company. The
telephone company's
application, does not find the information either, and accordingly, its If Not
Found Module is
activated and, matching the user's Specification to one of its Condition
records, forwards the
users Specification to another, similar application running in England, which
repeats them
procedure with Scotland etc, and returns the number required back down the
chain to the
user. The user only gets a message from his application 'I'm getting the
number, what would
you like to do while I'm waiting for it?' If the user is still needs to do
something with the item
before it is complete, then all he needs is a message 'I'm getting it, let's
carry on in the
meantime.'
Effectively, the If Not Found methods enable an unlimited number of physically
separated Data Relation Table s to act as a transparent whole
sees several seconds pause, and then his machine continues executing
This describes the procedure by which remote Data Relation Tables can be
effectively
connected to the local Data Relation Table, in a manner transparent to the
user, and while
satisfying the Unlimited Principle. The same general procedures apply not just
to Telephone
numbers but to every Data Relation Table field and also apply to instances
where
combinations of fields are not found, and also when combinations of field
values are not
found. These procedures can be applied to booking car, hotel and airline
reservations for
example. If a user orders, for example, 'Book a car with Avis for Minneapolis
at 14.30
Thursday' the attempt to find a 'Book Car' Module will fail. Two possibilities
then exist:
The If Not Found Action Module can go to a remote Data Relation Table and load
a
Book Car Module.
The attempt to do this may also fail because there is no remote Data Relation
Table
recorded from which to collect that Software Module. However, supposing that
suitable If Not
Found Condition records had been created and one of them matched the user's
query, then
the Associated Director could contain URLs for car rental companies, and
result in the
application containing the company, and either making the booking directly by
sending the
appropriate Data Relation Table record and receiving a confirmation record
back, or by
downloading a Software Module to do this. Equally, when the car rental company
URL is
reached, it queries the local Data Relation Table, find there is no 'Book Car'
Module,
384
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
downloads it to the local Data Relation Table and the procedure continues
under the control
of the Book Car Module. Companies wishing to sell its services would have an
interest to
supply all possible users with such If Not Found Condition /Director record
pairs. With the
above established it is not then difficult far Condition records and 'Watch'
Software Modules
to be established that watch the users input and offer to book cars and planes
and so on
when the Language processor detects a statement that the user is going
somewhere.
In effect, the Any-to-Any machine enables a computer for which a programmer
has
created suitable Data Relation Table If Not Found records to do something it
did not know
how to do before and this is another manner in which the Any-to-Any machine
enables a
computer to 'learn'. In common parlance, the ability to connected remote Data
Relation
Tables, can be used to enable a computer a computer to 'learn' how to do
things it did not
know how do before and this 'learning' process can be fully transparent for
the user.
Theoretically, Any computer may need to perform Any (possible) manipulate on
Any
data. However, storing all possible data and all possible Software Modules on
a single
computer is neither realistic, technically possible, nor desirable, and this,
in the state of the
art, causes a problem. A debate continues in the state of the art computer
world on this
problem, without any resolution in view. One side considers that all software
and data should
exist on the local machine - which is not practical, as a single machine
cannot hold all data
and all possible Software Modules. The other side considers all software and
all data should
exist on the server - which is equally impractical, being both slow and
contrary to human
desires to keep their own data under their own control. The Any-to-Any
machine's If Not
Found methods enable a workable solution to be found in the middle of this
problem, whereby
the user keeps all the data and Software Modules he has used at least once on
his own
machine, and where his computer, meeting an If Not Found either for data or
for a Software
Module, connects for 'advice' - much as a secretary may ask a senior secretary
how to do
something or where to find something - with a senior Data Relation Table
maintained by the
software provider. The senior Data Relation Table, just like an advisor, can
either provide the
data or Module required, or tell the junior Data Relation Table where to look,
and connect it
directly to the place where it can found, or to the place that knows where to
find it, in the
manner previously described. As a result, the If Not Found Any-to-Any machine
methods
enable a computer to have available the data and the Executions its user
needs, and to
obtain transparently any data or Module that it finds the user needs, but
which the computer
does not yet have available.
These abilities require that international standards should exist for the
structure of
software that is to be remotely queried, and this might be considered
unlikely, and this aspect
of the Any-to-Any machine, therefore, not useful. However, standards tend to
be adopted
385
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
when it is financially advantageous to adopt them. Public Service
organizations will favor the
adoption of such standards, as the more such organizations can demonstrate
they are of use,
the more likely they are to receive public funding. Commercial organizations
will also tend to
favor the standards for commercial reasons, because such standards will enable
them to
acquire customers they did not have previously.
- Methods for Handling Approximation
Approximation Definition
While a human may expect exactness in the Execution of an order, this is not
necessarily true when a human issues queries. Human queries and statements as
frequently
issued are themselves Approximations. For example, a human will say 'about a
couple of
weeks ago I wrote a letter to Joe.' In fact, the letter to Joe was written at
a specific time or
times, on a specific day or days, and these timels and dayls, in fact, could
be anywhere from
perhaps one week ago to perhaps five or six weeks ago. In effect 'a couple of
weeks ago' is
an Approximation for the specific time at which the letter was written.
Hence, the ability to handle Approximations is a desirable feature of a data
engine that
is to manipulate data in a human-like manner. However, computers are machines
whose
basic transistor and binary mechanisms are two state Any-to-Any mechanisms
that are only
capable of returning an exactness and hence return 'or or off', 'true or
false'. Hence, in order
for a computer to be able to Approximate, the approximation should be stated
for a computer
as an exactness. In other words, there should be a clear statement for the
computer of
exactly what an Approximation is and if this is done, the computer can exactly
test the exact
statement of an Approximation and determine whether it exists or not.
In the state of the art however, mechanisms do not exist to do this,
consequently
causing the problem that a computer is unable to manipulate data in a human-
like manner to
that degree. Fuzzy logic exists that attempts to solve this problem by - in
essence -
assigning a degree of truth to data. The word 'true' is defined by the Oxford
English Diction
as 'Consistent with fact; agreeing with reality; representing a thing as it
is,' and all the many
definitions of the word have as a constant element the comparison of one thing
with another.
Approximations however, do not have any comparative element, they are
statements
of fact and hence attempting to handle approximations by assigning a degree of
truth to them
cannot produce a successful result. For example, stating that the term 'about
a couple of
weeks ago' is a statement that has a value of being 75% true would itself be a
false
statement. The statement 'about a couple of weeks ago' is 100% true if the
event concerned
occurred within the time period covered by the exact definition of 'about a
couple of weeks
ago' which could be defined as 'a period of time between more than 2 days ago
and less than
90 days ago'. However the statement 'a couple of weeks ago' is 100% false if
the event
386
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
occurred an hour ago. Hence, assigning a fuzzy logic degree of truth to a
statement such as
'a couple of weeks ago' is a nonsense.
An Approximation is not the same as a Similarity and this shows clearly in the
human
phrasing 'X and Y are approximately similar' - something can be approximately
something
else, or similar to something else, br both.
In the terms of the Any-to-Any machine, a Similarity has previously been
defined as:
The Similarity of one thing or things to another thing or other things, is the
degree to which one has Components or Component Assemblies that are common to
the other.
An Approximation is defined as:
A Component or a Component Assembly that contains within it the intended
Component or Component Assembly; and which may be stated either as a statement
or as a rule.
Approximation Specification
Each Data Class, and potentially each type of value within a Data Class can be
the
subject of an Approximation Statement or an Approximation Rule. The type of
Approximation
Statement or Rule varies with Data Category, Data Class and thereafter, with
individual
values in a Data Class - for example:
1. Data Class First Name. Any name beginning with 'D' can be
considered an approximation for the first name of 'David'
2. Data Class Time Period. A'week' can be approximated by any time
that is within ten days either way of the center of the week.
These examples illustrate that what does and what does not constitute an
Approximation for a given value is a question of judgment and therefore a
question of what
most people consider to be an Approximation, tempered by the individual user's
view of what
does and does not constitute an Approximation for that value.
Hence, in order to enable a computer to process Approximations - in addition
to the
Concept Hierarchies that are part of the Data Relation Table itself -
Approximations are also
enabled in the Any-to-Any machine with the following methods:
1, The Data Class Table containing user data values for which
Approximations are to be used is provided with two - or more - additional
fields for
Approximations.
2. When an Approximation is an exact value -for example, when 'pony' is
considered an approximation for 'horse' - the first Approximation field is
used to state
the exact Approximation that applies to the value in the Data Class Record.
This is
the case when - as a further example - the approximation for a First Name such
as
387
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
David could be 'D" - i.e. D followed by any other characters - 'his first name
is D
something, or B something.'
3. When an Approximation needs to be stated as a range with a higher or
lower limit, Approximation fields are used in pairs. A 'week' is stated using
paired
Approximation fields - (+) X days in the first field, (-) Y days in the second
field. If
many Approximations are required for a single Component, then the Data Class
can
use one Approximation field instead of two, and use the single Approximation
field to
refer to entries in a type of Data Assembly Table termed_a Many-to-Many table.
1n a
Many-to-Many table, one field states the senior value - i.e. the Data Class
record
number (i.e. the Numbers Language reference of the Spoken concept Language
Value) and the other field states the junior value that is related to it- i.e.
is an
Approximation for it. In the case of an Approximations Data Assembly Table,
two
fields are usually required as previously noted, so that higher and lower
limits can be
specified when they exist. Approximation Values are also stated as Numbers
Language Data Class references, and if they refer to a value outside their own
Data
Class, should contain as part of their reference number, the number of the
Data Class
table in which they occur. Approximations should ideally be pre-loaded into an
application, but if Approximations are in use, then when the user enters a new
value in
a Data Class, then the user should be asked 'what are approximations for
this?' by a
suitably written 'Obtain Approximations' Software Module.
4. Assemblies of user Data Components can also be considered to be
approximated by other assemblies of user Data Components. User Data Component
assemblies are stated in the Data Relation Table in the main, and therefore,
Approximation of Assemblies is a matter of stating that one Data Relation
Table
record approximates another or others. This is achieved using the
Administration
Field 'Approximation' which can state either another Data Relation Table
record
number of the Base Record Number of another Data Relation Table item. If the
Data
Relation Table item or record has more than one Approximation Component
Assembly
- i.e. it can be Approximated by more than one Data Relation Table records
stating
3D different items - then the Approximation field can refer to the number of a
Data
Relation Table record Approximation type that lists the Approximations.
5. Approximations are not necessarily reciprocal. A pony may be an
Approximation for a horse, and a horse may be an Approximation for a pony and
hence, the Approximation is reversible. However, 'a week' can be an
approximation
for 'a day', but a day is not necessarily an approximation for a week, and
hence this
Approximation is not reciprocal. Consequently, if a reciprocal approximation
exists,
388
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
then it should be specifically stated and not assumed to. exist in the manner
in which
Approximation Software Modules are written.
6. Approximations in 'generally accepted use' may or may not be
acceptable and used by individual users, and therefore, the Approximation Data
Assembly Table just described is used with an additional field for User
Number.
Approximation Software Modules, looking in the Approximation Table look first
for an
Approximation value recorded with user's number. If it fails to find an
Approximation
value for that User Number, then it looks for an Approximation value that has
been
recorded without a User Number - i.e. the default Approximation value.
7. If a finer degree of control of Approximation is required, then it is
useful
to define the User Data Component in an Expanded Data Class Table that is
expanded to full Data Relation Table size. In this case a user Data Component
such
as a 'horse' for example, can be defined using full Data Relation Table
records in the
Expanded Data Class table. Such definitions can be stated in more than one
way; for
example, a 'horse' can be defined in terms of descriptive words, and/or or in
terms of
a Shape as previously described for Image Component Assemblies. e. If other
animals are similarly defined as Shapes, then a computer with suitable imaging
hardware can look at an object and answer the question 'Is that a horse?' and
answer
with a human-like Approximation response 'No, it is more like a pony or a
donkey than
a horse.' User Data Components can be described in terms either of words, or
images, or sounds, or in terms of all of these. Each of these can be split
into
definitions for each Data Category - horses, for example, can be described in
terms of
names, in terms of where they are found, in terms of what they do, and in
terms of
what they look like. Nothing limits the extensiveness of the definition of a
Data
Component, and, provided appropriate if Not Found records and Modules are
included, then the application can go elsewhere to obtain the definition the
user has
asked for..
Approximation Conditions
Approximation Conditions can be incorporated as part of the Find Module one of
several types of If Not Found Condition record - i.e. a type of Condition
Record that detects
what exactly was not found and is accompanied by Companion Director record
that states
what to do if the value is not found. One of the first actions that can be
done if an exact value
is not found, is to search again, using an Approximation for the value for the
value that was
Not Found. For example, if a search fails to find the word 'horse' it can look
up the
Approximations for the word 'horse' - such as 'pony' and re-search, using the
Approximation.
This enables a computer to search for an item in response to an order such as
"Get me the
389
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
letter from Joe about bananas" and return 'there is no letter about bananas,
but I do have one
about apples'. This example illustrates that, in addition to the ability for
an application to
record a user's approximation fro something - as described above - the Any-to-
Any machine
methods for enabling Approximations also include the use of Concept
Hierarchies described
previously.
All Condition records can be either Field Parallel - detecting - in the case
of If Not
Found Condition record - that a value was Not Found in a particular field, or
Table parallel, in
which cases they detect that specific combinations of values in specific
fields were - in this
case - not found. Field Parallel Condition records have Companion Field
Parallel Director
records that state in each of their fields the Execution record number of the
Software Module
they are to call if the Condition stated in the same field of the Condition
Record is detected.
Table Parallel Condition Records state the number of the Execution Record of
the Software
Module to call either in their Director Administration field, or - when
several Modules are to be
launched simultaneously - contain the number of a Directory record that lists
the Execution
Records to call.
One of the types of Software Modules that can be called by the Director record
that is
a Companion Record to an If Not Found Condition record, Approximation Sub-
type, is an
Approximation Software Module - a type of Software Module that manipulates
Approximations.
If an If Not Found Condition Record, Approximation Type does not exist, or if
the
Approximation Execution fails or is not accepted by the user, then the
Execution Token is
returned to calling Execution Record, which can then check for matching If Not
Found,
Elsewhere Sub-Type Condition records, that result in the application connected
to distance
applications to obtain the missing data - as will be described in due course.
Approximation Execution - Approximation Software Modules
Approximation Modules use the values that were not found to look up the
Approximations for the Not Found values, and then use the Approximation values
to query the
Data Relation Table> creating and using an Approximation Find record that uses
the original
Find record, and substitutes the Approximation values for the values that were
not found.
The Approximations can either be searched as a group, or one at a time, but it
is preferable to
try Approximation Values one at a time, starting by substituting the value
most to the left of
the Data Relation Table, and if that fails, substituting the value Data Class
next to the right of
it, etc. The reason for this procedure is that values to the left of the Data
Relation Table have
a higher importance than those to the right - as per the Data Class Functional
Hierarchy
previously described - and following the Functional Hierarchy tends to produce
the shortest
Execution time.
390
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
If the Approximation Module finds records using Approximations, it can either
return
these to the Find Module together with the Approximation used. The Find Module
uses this,
plus a Prompt record that is a Companion Record to the If Not Found Condition
Record, to
present the found record to the user, and uses the Prompt record to inform the
user of the
Approximation used.
- Methods to Store, Assemble and Translate Data Components
In order to create an Any-to-Any machine, all data (whether software or
otherwise)
should be stored as Data Components meeting the definition of Components.
Because all
data is stored initially as Components - or, in the Any-to-Any machine, copies
of Components
- Components can then be assembled in any manner to suit any purpose. e. A
basic
teaching of the Any-to-Any machine is exactly that an Any-to-Any data machine
is a machine
that stores and assembles Data Components, meeting the definition of
Component.
As soon as two or more Components are assembled in fixed relationship, the
result is
a One-to-Many machine and the Components of such machines can no longer be
related to
other Components, and therefore, an Any-to-Any avoids aft and any fixed
relationships
between Components.
At its most fundamental, manipulation of data is the subject of the creation,
recording,
detection and destruction of relations between Data Components. The Data
Relation Table is
the method used by the Any-to-Any machine to store relations of Components
that have been
created by software at the behest of a programmer user or an end user.
Software consists of
Data Components that have been related by a programmer, and hence the
relationships of
software Data Components to one another are also recorded in the Data Relation
Table.
For convenience and practicality two miniaturized versions of the Data
Relation Table
are used in the Any-to-Any machine - Data Class Tables and Data Assembly
Tables.
DATA CLASS TABLES
The Data Class Tables of the Any-to-Any machine form part of the Any-to-Any
machine's methods to enable a computer to relate any data to any other data.
Data Class
Tables are the one of the Any-to-Any machine methods to translates all data
into a common
format such that any data can be related to any other data
One fundamental teaching of this Any-to-Any machine is that - in order to
create,
record, detect and destroy data relationships (i.e. manipulate relationships)
in an Any-to-Any
manner - it is preferable to disassemble data into Components. A further a
fundamental
teaching is that in order to manipulate data in an Any-to-Any manner it is
also an inescapable
requirement to translate every and all Data Components into one common
language and
store them in that common language.
391
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
To illustrate this prime requirement: if a line in.a drawing is stated in one
image file in
one manner, and a similar line is stated in another image file in another
manner, it not
possible to detect if something exists in those two files that meets the
Condition that
describes a line, in the absence of a conversion mechanism that converts
specifically
between those two file formats. However, considering all the formats that do
exist, and the
number of formats that could exist, writing a conversion mechanism between any
one of
them, and all the rest of them, results in a logarithmic increase in the
number of converters
required with the addition of each new format. However, if conversion is not
done between
any one of them, and all others, then it is not possible to detect if a
Condition exists in any or
all of them - for example, detecting that a line exists. If conversion
mechanisms are provided
between each format and every other format the process becomes so complex as
to be
difficult in practical terms. When it is not possible to detect if a specific
Condition exists -
such as a line - it is equally not possible to create a relationship between
the data that meets
the Condition. It is even more difficult - in practical terms - to convert
every manner of stating
anything directly in every other manner of stating everything else. (The above
teaching of the
Any-to-Any machine is described in relation to a line in a drawing, but
applies just as much to
conversion between spoken languages, conversion between drawings and images
and
languages, etc)
The Any-to-Any machine solves this problem by using methods to convert all
data into
one common language that is convenient for computers and that can be made
convenient for
man also - i.e. Numbers Concept Language. When all formats are converted to
one
common format - such as Numbers Concept language - then each new format only
requires
one converter and the increase in converters is arithmetic, not logarithmic.
Hence, in practical
terms, a primordial requirement for the creation of an Any-to-Any data
manipulation machine
is the requirement to provide a) One common language for all data and b) to
provide
translation mechanisms that are capable of translating all data into one
common format. A
further teaching is that it is a desirable requirement that the elements from
which the common
language is built, are themselves Components, as any ambiguity at all - one
element with
more that one meaning or function - anywhere in the common language will
prevent its use to
construct an Any-to-Any data manipulation engine.
The Numbers Concept Language of the Any-to-Any machine is an example of
enablement of the above teaching, and provides one common language into which
all data
can be converted or translated, that meets the requirement of being able to
express all data
as Components. Numbers are chosen in this Any-to-Any machine as the Components
from
which to construct the language, because:
392
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
1 ) Numbers are the data type that is most native to computers and that
they can hence manipulate most rapidly
2) Numbers are themselves Components
3) All data can be expressed as numbers.
In the state of the art, all data is already expressed, eventually, as
numbers. The
advantage of the Numbers Concept Language of the Any-to-Any machine is that it
is a
language composed of numbers that are used in such a manner that they can be
readily
converted into a form that is useful for the ordinary user.
Hence, the native form of the Any-to-Any machine is a Data Relation Table that
contains only numbers in the form of Numbers Concept Language. However,
Numbers
Concept Language is not something that humans can speak or read directly.
Therefore, this
description describes the Any-to-Any machine in a form using two languages A)
Numbers
Concept Language into which all data is translated, satisfying the requirement
for a common
format, and B) English Concept Language, as a mechanisms for a human to be
able to
communicate in Numbers Concept Language.
Data Class Tables are one part of the Any-to-Any machine that enable all data
to be
converted into Numbers Concept Language and that enable the Any-to-Any machine
to
convert between Numbers Concept Language and English Concept Language. In an
embedded application - such as car engine monitoring - where all incoming data
is in the
form of numbers (numbers satisfy the definition of a Component) these numbers
can be
placed directly into Data Relation Table Data Class fields with requiring any
translation. The
act of placing them in a specific Data Relation Table field, intrinsically
translates them into
Numbers Concept language and hence, Data Class tables are not required to do
the
translating in this kind of application.
When the Any-to-Any machine is to be multi-Language, or to accept data that is
not
described in Numbers Concept language, Data Class Tables are required, and
contain (a
minimum of) one field per Concept Language to be translated. Each field
contains a value in
one Concept language. Translation is a data manipulation like any other and is
the subject of
creating and detecting relationships between Data Components in different
languages. Data
Class Tables relate a Component in one Concept Language to a Component in
another
Concept Language.
Data Class Tables contain one field per Concept language, and nothing more,
provided that no further information needs to be recorded concerning
Components in the
Concept Language.
Because Data Class Tables are miniaturized Data Relation Tables, when it is
necessary to record further data concerning a Component, their records can be
expanded to
393
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
become a standard main Data Relation Table record. In the state of the art
however, it is not
normally possible to put an expanded Data Class record into the Data Relation
Table because
most databases - which are the most convenient existing type of structure to
house Data
Relation Tables - do not usually accept a mixture of data types in a single
field. Due to this
failing it is normally not possible to expand a Data Class Table's record into
the main Data
Relation Table and if it is needed to do so, then a separate Data Relation
Table should be
created for the purpose.
A Data Class Table is a miniaturized Data Relation Table. Supposing that the
Data
Class Table contains two fields, one for Numbers Concept Language and one for
English
Concept Language, and that this Data Class Table is servicing field 51 in the
Data Relation
Table. In effect, the first field in the Data Class Table - containing the
Numbers Concept
language number (which is the record number in the table) - is a main Data
Relation Table
record in which the only field that has a value is field 51. The second field
in the Data Class
Table - containing the English Language Concept language value - is another
main Data
Relation Table record in which the only field that has a value is field 51. If
these two records
were in the main Data Relation Table, the record with the Numbers Concept
Language value
in field 51, would have a value in its AND field that joins it to the other
record containing the
equivalent English Concept Language value in its field 51. Similarly, the
record with the
English Concept language value in field 51, would have a value in its AND WAS
field, joining
it to the record with the equivalent Numbers Concept Language value in its
field 51. (A full
Language Processor written with the methods of the Any-to-Any machine does
exactly this
and expands a Data Class Table to full Data Relation Table size. It then puts
all expanded
Data Class Table records into one, specialist full Language Processor Data
Relation Table,
that processes incoming and outgoing data, passing it to and from the user and
to and from
the main Data Relation Table). Hence, an alternative way to view a Data Class
Table record
is that it is in reality, a table containing a pair of Data Relation Table
records, in which only
one field is used in each record (assuming that the Data Class Table contains
two fields for
two Concept Languages)
Because a Data Class Table is a miniaturized Data Relation Table, even if it
consists
of only two fields, all Data Relation Table methods and mechanisms are
available, although, it
is practically difficult to use any of them in a Data Relation Table
consisting of only two fields.
Expanding a Data Class Table all or part of the way to becoming a full Data
Relation
Table in the above manner makes available some or all of the fields also used
in the main
Data Relation Table fields to describe or control just one single Component.
Additionally, as
more of the main Data Relation Table fields are added, particularly
Administration fields, it
394
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
becomes possible to use more and more of the methods and mechanisms that are
applicable
to the main Data Relation Table. Expanding a Data Class in this manner can be
useful when
there is a need to state data about the Component itself, or to Control the
function and use of
the Component itself in a precise manner. It should be emphasized that all
Data Class
records are the equivalent of what would be Data Relation Table, Component
type records
and only describe or control the Component they contain.
In the state of the art, storage limitations in mechanisms such as databases
used to
house Data Relation Tables mean that the non-numbers data types in many Data
Classes
cannot be accepted in the main Data Rehation Table which is formatted to
contain numbers.
Many databases do not accept mixed data types in a single field and therefore,
the expanded
Data Class records have to be kept apart from the main Data Relation Table.
Data Class Tables can therefore exist in any form from just two fields up to
containing
all the fields in the main Data Relation Table and through any intermediate
stages that are
useful. However, when doing so, it should be clearly remembered that the Data
Class Table
field containing the Numbers Language number (which has a second, unused
function as the
Data Class table record number) is the sole field with a value in ONE record,
and each of the
other fields containing values in other Concept Languages are the sole field
with a value,
each in their own record. Equally, this does not necessarily mean that
separate records have
to be created for each Component.
The situation in the physical universe itself is that much of it consists of
at least two or
more of something and these two or more are related - two sides to a
communication, a
cause and an effect, a machine that makes something and the thing made by the
machine
etc - and hence, in most cases, a pair of Data Relation Table record is
usually needed to
state a given relations ship, and one of the main purposes of the AND, AND WAS
fields is to
pair records in this manner so that the two sides of something can be
represented easily.
The same types of data are needed to state something, and hence, the data
types that
constitute each record are the same. Hence a single Data Relation Table record
could be
created as two Data Relation Table records placed end to end, in which the
data types in the
fields of one, are the mirror image of the other. However, this would make a
Data Relation
Table excessively large and difficult to understand and manage. Names - for
example of a
sender of a communication - would be found in the name fields on one side of a
given
records, and the names of the receiver of the communication on the other side
of the record.
If more than one person received the communication, then for the second and
following
receivers, one side of each record would be blank, except for referring to the
record
containing the sent communication. For this reason, in normal practice it is
more practical to
395
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
split the two sides into two records, and simply provide a mechanism (AND, AND
WAS) to
relate the two.
However, if a Data Class Table needs to be expanded only to a small extent,
because
only a small amount of data needs to be noted about the Component, for
example, it can
practical to only include a few extra fields from the main Data Relation Table
in the expanded
Data Class Table, and then, functionally divide the Expanded Data Class Table
so that one
set of fields in it apply to one Component and the other group of fields in it
apply to the other
Component.
For this reason, an Expanded Data Class Table can have two fields - or more -
fields
containing exactly the same data type (Notes - a form of Content - for
example) at the same
time, but one of the two fields applies to one Component only, and the other
field applies to
the other Component only.
When doing this it should be remembered that only number are used to name
Tables
and fields and that the Number of a table is the same as the number of its
Data Class in the
Data Relation Table. Secondly, it should be remembered that an Expanded Data
Class
Table, being a miniaturized Data Relation Table, can only contain fields that
are found in the
main Data Relation Table. Consequently, all field numbers in a Data Class
table, whether
expanded or not, are number identically to the number of the Data Class whose
type of value
they contain. If, for example, in the main Data Relation Table, the Content,
Text field has a
name for the field that is its Data Class number - for example 104, and a
Content, Text field
is used in an expanded Data Class table, then it is also numbered 104.
However, most
databases will not accept two or more fields in a given table. Therefore,
supposing the
Expanded Data Class Table contains three Content, Text fields, (to contain
notes) each
applying to a different one of three Components that are recorded in the
Table, then the first
Content, Text field is labeled 104, the second one is labeled 10411, and the
third 10412. Un
the fast two digits, the '1' of '11' is considered to be a representation of
the AND mechanism,
and the second '1' of '12' is considered to state that this is part of the
first additional record.
Since an Data Class Table, to whatever degree it is expanded, is a
miniaturized Data
Relation Table, the contents of its fields - other than the field containing
the Component itself
- consist wholly of references to components in other Data Class Tables in the
standard
manner that is used in the main Data Relation Table. Consequently, maintaining
the exact
same field numbering system as used to number fields in the main Data Relation
Table, has
several advantages:
1 ) Confusions about the nature of field contents are avoided
2) A Converter Module for the Data Class Table - and which is stated in
the Expanded Data Class Table itself - can covert the Data Class Table records
so
396
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
that other Modules can access them and use them or display them when required,
as
the type of data in a given field number is the same, no matter in which table
that field
occurs.
Expanded Data Class tables contain data that can be classed as second level
information, or - in the case of Software components - classed as adjustments,
and hence
the access required to such tables by the user or programmer is unlikely to be
very frequent.
Note that while all Data Relation Table fields are available to state data
about a user Data
Component, and to control a user Data Component, one control that may not be
used.is to
use the Exist Data Relation Table field to state that the user data component
does not exist.
This may not be done as to do so could effectively destroy all data in which
that user Data
Component was used as a Component. Any Data Component can however be declared
Active (the normal state) or Inactive using the Data Relation Table 'Active'
Data Class field
When the arrangement of keeping the equivalent of several shortened Data
Relation
Table records in one Data Class Table becomes too cumbersome, the Expanded
Data Class
Table can be expanded to full, or near-full Data Relation Table size, and the
contents of
different fields applying to a given Component, split into a separate record
for that type of
Component. To do this, the part of a record applying to one type of Component
is made into
a separate record that is joined to another or other separate record for the
fields concerning
each other Component in the table, using the AND, AND WAS method.
When Data Class Tables are expanded with any of these methods, they are termed
'Expanded Data Class Tables'. As a Data Class is further and further expanded
with any of
the above methods, particularly in its Administration fields, more and more of
the methods
and mechanisms of the full Data Relation Table become available. For example,
record types
such as Conditions, Software Modules etc can all exist, but all of these state
data about only
the particular Component they concern and/or act on only the Component they
concern.
Some examples of uses for Expanded Data Class Tables are as follows:
1 ) To contain a definition of the component, exactly as a dictionary defines
a word, the record defines the Component exactly.
2) A full Language Processor uses Expanded Data Class Tables that are
expanded to full Data Relation Table size, both to contain definitions of
Components
and Words, and to contain the rules it needs to detect which meaning of a work
is in
use. It also uses such Tables to contain Grammar rules for formatting outgoing
Components into grammar language. A Language processor uses AND records to
state the Spoken Language Word, and a number of AND WAS records to state all
the
different meanings (Components) in that word together with records that state
the
rules for detecting each of the meanings. The Language Processor uses the
record
397
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
number of the appropriate Component - i.e. that Component's reference number -
to
write the Data Relation Table it composes based on the input.
3) The Activity of a software Data Component - i.e. a Logic - can be
controlled in a very fine manner using an Expanded Data Class Table. The
following
are some examples to show types of records that could be used in such a table
to
control the functioning of an individual Logic
1 ) Quality record - Can contain Conditions that specify a particular quality
of how a logic is to be done - fast slow etc
2) Data Record - Can contain information about the Logic - programmer's
notes, date it was written or installed etc.
3) Action Record - Can specifies Conditions that render the Logic Active
or Inactive under specific circumstances or Conditions or times.
4) Time Record - Can specify times at which whatever the Logic is active
or Inactive. For example, (providing that Software Modules are being assembled
each time before they are used) one Logic could be used at a certain time of
the
day, and another one used at another time of day, and this could be achieved
by
changing the marking in the Active field of the two Logic Component records,
to
make one Active and other Inactive.
5) Location Record - Can specify a location where a Logic is to be active
or to be kept. For example, Active in this fixed machine, inactive in that
portable.
6) Matter Record - Can specify the device that a logic is to use depending
on Conditions stated in Associated Condition records, etc.
The methods just described for expanded Data Class Tables shows an of the Any-
to-
Any machine, namely that even a single Data Component can be infinitely
expanded, by
turning it into an infinitely expandable Data Relation Table record (i.e. in
an Expanded data
Class Table expanded to full Data Relation Table size). Equally, any one datum
can be
infinitely contracted, by grouping Data Relation Table records to the point
where a single
character or digit is the name for an entire Data Relation Table or set of
Data Relation Tables.
Note that, when several different types of Component are recorded in a single
Data
Relation Table field, one Data Class Table is used to stores each Component
type, or,
alternatively, the Data Class Table contains a field that states the type of
that particular
Component.
DATA ASSEMBLY TABLES
A Data Assembly table is also a miniaturized Data Relation Table, and the
remarks
made for Data Class Tables and their expansion apply in general to Data
Assembly Tables
398
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
and are not therefore repeated here. The differences between a Data Class
Table and a
Data Assembly Table are:
Data Class Table records
1 ) Translate one Component into another
2) State data about a Component
3) Controls the functioning or use of a Component
Data Assembly Table
1 ) Does not translate between Components. Works only in Numbers
Concept language
2) Assembles Components into higher order Component Assemblies.
Colloquially, Data Class Tables provide a microscopic view of a Component. Any
data
can be assembled with any relationship and act to modify a Component. They can
assemble
a component. So Data Class Components go from a Component downwards into
infinitely
fine detail. Data Assembly Tables, on the other hand, work from Components
upwards and
can be used as the first stage of creating a Component Assembly.
The reason for using a Data Assembly to relate Components - which would
normally
be done in Data Relation Table records - is that some assemblies of Components
only require
a few Components, and, if this were done in the Data Relation Table as it
could be, then the
Data Relation Table records that did it would be mostly empty.
The other advantage of a Data Assembly Table is that it can act as a mixture
of a
Data Relation Table Sequence record and a Data Relation Table data record in
the following
manner, described in relation to assembling a Field Logic performing several
actions, using
software Data Components (Logics) stored in the Logic Data Class Table:
1 ) The Data Assembly Table record number serves as the Numbers
Language reference Number for the Field Logic
2) Six fields (for example) each containing the Logic Data Class reference
number for different Logics. These fields are named with the number of the
Software
Module Name field in the Data Relation Table field, in the manner previously
described for Data Class Tables, which use several fields from the same data
Class.
3) A Content, Text, field for notes about the Field Logic
4) One or more Time Fields to state the time the Module was written
5) A First Name and a Last name field to show who wrote it, etc
All main Data Relation Table methods and record types are available for use in
a Data
Assembly Table, but when so used - just as a Data Class Table states data
about, and
controls the behavior only of the Components contained in each of its records -
so a Data
Class Assembly Table states data about and controls the behavior only the
Component
399
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Assemblies contained in a each of its records. The Component Assembly itself,
in the above
example above, is contained in (2) - the six fields stating the reference
numbers of Logics.
When creating a Data Assembly Table - such as the one in the example above -
that
contains more than one field for one specific Data Class - number (2) in the
example above -
attention should be paid to maintaining the unlimited nature of the Any-to-Any
machine.
While the six field for Logics in the example above may be sufficient for most
occasions, they
may not be sufficient for all occasions, and therefore, it is desirable to
include an AND, AND
WAS mechanism to join two fields together and a Record Converter adapted to
the table that
can made joined fields into a logical whole.
Second, level, third level, and an infinite number of levels of Data Assembly
Tables
can be created in order to further assemble Data Components that have been
assembled by
the first level or preceding level of Data Assembly Tables, and the question
of whether to
perform the assembly in a Data Assembly Table dedicated to that type of
assembly is a
question of judgment of the following factors:
- The increased complexity of logic created by each additional
level of table that is introduced
- Space that is saved in the main Data Relation Table.
Generally, assemblies of Components where the individual components do not
need
to be accessed frequently, or are not used frequently to locate assemblies of
which they are a
part, can be placed in Data Assemblies. The additional computation load to
find Components
in them is balanced by the fact that it does not have to be done very often,
and the rest of the
main Data Relation Table activities are faster due to the decreased Voad
produced by
removing potentially large numbers of records to the Data Assembly Table. For
this reason,
Data Assembly Tables are much more suited to assembly of Software Field Logics
than they
are to assembling user data. Software Components and Component Assemblies tend
to be
related to one another once, by the programmer, and thereafter function in
their assembled
form. User Data Components, on the other hand are continuously related to one
another by
the user, and therefore, are mostly best assembled in the Data Relation Table
where they are
easily available to be related to other Components and Component Assemblies.
Sometimes, Data Components requires a certain level of assembly before the
assembly is useful in the Data Relation Table. Field Lvgics may need to
perform more than
one single action are an example. The Logic Data Class Table contains only a
Logic - a
piece of code - that performs only one action, and a reference number for that
Logic.
However, if a field in Software Module requires more than one action to be
done by the code
handling that field, then a number of Logics should be assembled together
before use in a
Data Relation Table field and a Data Assembly Table is a convenient way of
doing this - it is
400
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
optimal to perform the first level assembly of Logic Components into Field
Logics in Data
Assembly Table that is outside the main Data Relation Table.
One of the unusual examples where it can be optimum to perform the first level
of
user Data Component assembly outside the Data Relation Table itself is in the
case of
people's names. Any person's name can be made up from a combination of values
in the
First Name and Last Name Data Classes. However there is no advantage in
recording in
every Data Relation Table record made by a specific person or that concerns a
specific
person, the fuH list of names that he may have. Therefore, it_ is more optimum
to assemble
the person's name in a Data Assembly Table and then ascribe that person a
reference
number - a User Number which is the record number in that data Assembly Table -
and use
that reference number in each Data Relation Table record that concerns that
person.
The example of a Data Assembly Table given just above illustrates that Data
Assembly Tables can exist in one of three forms in which a Data Assembly table
can exist:
1) As a miniaturized Data Relation Table data record, in which
~ there is only one of each Data Relation Table field type.
2) As a miniaturized Data Relation table Sequence record, which is
a list of Components or component Assemblies all from the same Data Class.
3) In the combined form, combining both (1 ) and (2) above, which
was the case in the example just described.
Note that, because of the parallelism of fields - the field (number) names and
data
types contained in them are absolutely identical between Data Assembly tables
and the Data
Relation Table, any record in the smaller table Data Assembly Table (or in the
Data Class
Table for that matter) can be copied into the main Data Relation Table (if it
contains
Sequence fields, then these should, at the same time, be copied into a related
Sequence
record). Equally, any record in the main Data Relation Table can be moved or
copied in into
the smaller Data Assembly table (or Data Class Table for that matter). If the
Data Assembly
Table is a type 1 or type 2 table (referring to the numbers above) then
records in the one can
be copied or moved into the other if it were useful to do so, and
occasionally, it is indeed
extremely useful to be able to do so. (The same point applies to Data Class
Tables, with the
exception that the host structure would need to be capable of accepting mixed
data types, but
the usefulness of doing so is likely to be less). The main point, is that it
can be done if
needed, and this illustrates the interchangeable nature of data between one
table type and
another, as essentially, they are all just smaller or larger versions of the
same thing.
Note that, while it is not difficult to use a mixed record type of type (3)
(described
above for Data Assembly Tables) in a Data Relation Table, it is not advisable
either. If this is
done there is risk of producing false data because the reference number in the
series part of
401
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the record may well have a meaning in the field the data Class in which they
ace found, but
that reference number does not apply to that data Class. Because that can
happen, a
mechanism is then needed to designate which fields in the record are Sequence
Records and
which are not. During a lookup, such records can not be handled with the rest,
but require
mechanisms to inspect which fields are Sequence fields and which one are data
fields,
slowing dawn the whole process. It is simpler and quicker to ensure that all
data records are
Data records contain data only, and all Sequence records contain Sequences
only, and then
exclude all Sequence records from a Data record lookup, and exclude all Data
records from a
Sequerice Record lookup. This problem does not arise in a Data Assembly Table,
because
data Assembly tables should only be used for Assemblies where the Components
do NOT
need to be found frequently in the normal course of main Data Relation Table
working.
Any level of Data Assembly Table can be expanded to up to being full Data
Relation
Tables of their own type, or to any stage in between, in the same manner
already described
for Data Class tables, remembering that they apply only to the specific type
of Component
Assembly contained in them.
A Data Assembly table that is expanded to the size of a full, but separate
Data
Relation Table is effectively acting as a junior Data Relation Table to the
senior Data Relation
Table, which it is servicing.
When more than one Data Relation Table exists in this manner in a single
installation
- i.e, in one computer - data transfer between the two tables is performed by
logic and is
performed in the manner of 'reading' individual records. The actual transfer
occurs using the
computer's physical internal connected mechanisms - its buss etc. The transfer
however, is
completely transparent for the user. If one of these tables exist in a remote
location, the
transfer between tables occurs using modem or other electronic transfer lines
instead of the
computer bus, and Software Modules send their own records to another remote
Data Relation
Table or receive records from another remote Data Relation Table and use them
as though
they were records it had itself created and hence, the process is transparent,
and many such
Data Relation Table in different locations can act as a transparent whole.
Further, since all
Software Modules are also stated as Data Relation Table records, and since
records can be
sent from one Data Relation Table to another, one Data Relation Table can
receive and
execute orders from another and transmit and get orders executed by another or
others, all
Data Relation Tables acting as a transparent whole whose size is not limited.
Sending and
receiving between tables is a matter of either establishing an international
reference system
for Data Class References for words and other data, or building Converters
that convert the
Data Class Components and their references to remove conflicts with the
receiving system,
convert the changed Components in the received Data Relation Table records
accordingly
402
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
and then use them. The result in effect is that missing data in one machine
can be queried,
perhaps to a machine in Japan where the Interface Concept Language is in
Japanese,
received back and used at the local machine, without any user intervention
being required to
do so, and the original language and location of the data is immaterial to the
user.
METHOD FOR ENSURING COMPATIBILITY AND EASE OF FUNCTIONING; THE PARALLELISM
PRINCIPLE AND METHOD
Mention has been made previously of maintaining the same field number 'names'
for
the same data type in different tables in different tables, and other examples
have been given
where parallelism between records is desirable. Records that are of a
particular type, termed
Associated Records are records such that the data in a given field of each of
the different
records applies to the same thing. An example was also give of parallelism of
user Data
Relation Table fields and Software Module fields, in the sense that the logic
in field 92 of a
Software Module Execution Record acts on data in field 92 also.
The requirement to maintain parallelism is one of the fundamental teachings of
the
Any-to-Any machine.
Transistors and binary code are both Any-to-Any machines, satisfying the
definition of
an Any-to-Any machine: 'Any number of Any component can be used with Any
Number of
Any other component in a manner that is intrinsically non hierarchical and is
intrinsically
unlimited.' Transistors and binary code work well together and together form
an extremely
powerful system entirely because they parallel one another closely - both can
exist in two
states and only two states - on or off for the transistor and 1 or 0 for the
binary system. Both
are base-2 systems. It is clear that there is a close parallelism between the
controlled system
and the controlling system.
All of life, on the other hand, is coded by a base-4 system containing 4
components -
Adenine, Guanine, Cytosine and Thiamine that makes up all genes. This coding
system is
exactly paralleled by other compounds, enabling the gene coding to be
transmitted, and
again, the parallelism between the controlling and the controlled system is
very clear.
Humans manipulate data, as described on an Any-to-Any basis, and hence, as the
above examples illustrate, a system will be most easily controlled by a human
if the system
operates in a manner closely parallel to his own operation - i.e. on an Any-to-
Any basis.
Within the system controlled by the human, that which is controlled (the data)
should be
closely and exactly paralleled by that which controls it - the software, in
the same manner
that a transistor is paralleled by the binary system.
Since data, unlike a transistor or binary code, can exist in Any state and
software
acting upon it can exist in Any state also, provided that close parallelism is
maintained
between them, the resulting system can be an Any-to-Any machine operating on
base-infinity,
403
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
with a consequent level of power that is difficult to predict, but this is
only possible if
parallelism is strictly maintained,
Accordingly, one of the most desirable teachings of the Any-to-Any machine,
which is
enabled through out the Any-to-Any machine is stated in, and defined as, the
Parallelism
Principle and Method of the Any-to-Any machine, as follows:
Strict parallelism should be maintained at all times, through all fields,
records
and tables. It is infinitely more desirable to maintain parallelism to ensure
overall
power, simplicity and accuracy of logic, and total compatibility between
applications
and different instances of different applications in different locations, than
it is to save
space in a given record.
The idea exists in the state of the art that a field in a database that is
almost empty,
for example, is 'wasted space' and that to provide a large field able to take
a long entry - that
may occur on just a few occasions - is to 'waste space' in many records - i.e.
that the
absence of data is without value. The Any-to-Any machine teaches that this is
false thinking
arising from a time that no longer exists - the time when there was the
greatest difficulty in
storing and processing any information at a11. In fact, the absence of data is
just as desirable
and valuable as the presence of data. For example, if it is considered
undesirable that a third
telephone number is unlikely and therefore, providing for it is 'wasted
space', then every time
a third telephone number is required, it can not be entered and any abiiity to
relate that
telephone number correctly to the one person in the computer it belongs to is
lost. The empty
space for the third number has two values:
- It enables a third number to be recorded
- It shows, where a third number is not recorded, that a third
number probably does not exist for that person and that is itself of interest,
just as the number of middle names a person has, or does not have, is
information that can state matters of importance concerning the person.
When it is considered undesirable and 'wasted space' to include two digits to
record a
year then nobody is prompted to enter the two digits and the Y2K problem
results. 'Wasted
space' results from the concept that the ideal state for every field is that
the field is full. In
fact, the ideal state is the opposite - the ideal state for a field is that
the field is never, ever
full. When a field or record is full the entire system is only one step from a
small or large
catastrophe.
Hence, it is false economy to omit fields that could be needed and far more
desirable
to ensure all fields that could be needed, are available and this is expressed
in the Parallelism
Principle and Method. Maintaining this Principle and Method is particularly
desirable when
using more than one.Data Relation Table, as follows:
404
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Data Relation Table can contain an unlimited number of different types of
records
- records that are different in the sense that they contain references to
different combinations
of different types of data held in different Data Class Tables. One record may
contain
references to software logics, while another contains references to user data
for example. In
large applications, it may be convenient to keep each different type of Data
Relation Table
Records in its own Data Relation Table, as previously described.
When a Data Assembly Table is used, for example to assemble Logics into Field
Logics, then the Parallelism Principle should be maintained as illustrated by
the following
example. Suppose that:
1. Field 18 in the Data Relation Table is the field for the Data Class Name,
and
2. The software writer wish to create a Data Assembly Table in which he wishes
to record a First Name, then the field in the Data Assembly Table in which he
records the
First Name is numbered field 18, whether or not it is the eighteenth field in
the table or
not.
3. Data in the data Assembly Table is not recorded in its input form but in
Numbers concept Language - in the form a reference to the appropriate Data
Class Table
value. Hence if the software writer in the above example, wishes to record the
value
'John' in field 18 of the Data Assembly Table, and the reference number for
'John' in the
First Name Data Class is 122, then the value 122 is recorded in field named
'18' of the
Data Assembly Table.
Maintaining the Parallelism Procedure and Method - with regard to field
numbering -
means that queries can be extended to include the Data Assembly Tables that
are - in fact -
extensions of the main Data Relation Table. This can be achieved using a
Virtual Record
Converter Software Module that has the effect of logically joining every Data
Assembly Table
field of a given number to the same number field in the Data Relation Table.
This logical join
is done in such a manner that it is transparent to all other Software Modules,
and hence, does
not affect their functioning nor require a change in their construction.
When more than one Data Relation Table is used, and when Data Class and Data
Assembly Tables are used, it is desirable that each field used is an exact
parallel of the main
Data Relation Table, in the sense that a) Fields in both tables should be in
the identical order,
b) fdenticafly named. It is not necessary that all fields are present, but
those that are present,
should be parallel in order to maintain the Parallelism Principle.
It may be judged that records that will be in a junior Data Relation Tables
will never,
contain some of the fields in the larger table and therefore, some fields can
be left out. In this
case, then at least the remainder of the fields that are used should be
identically named to
those in the main Data Relation Table.
405
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
If separate Data Relation Tables are used, these are parallel in field format
and field
number, as failing to do so and hence failing to maintain the Parallelism
Principle is likely to
lead to unpredicted problems in the future. This means that if, for example,
field 51 is used,
52 - 54 are not and 55 is used, then the contents that are to act on or have a
relation to field
55 of the main Data Relation Table should be placed in a field numbered 55 and
not in the
next 'available' field number of 52. When this method is not followed, and the
Parallelism
Principle is not maintained, problems of the following nature are likely to
arise to result, for
example, if the Data Relation Table records of, another application are copied
into the existing
Data Relation Table, the new application may require the missing fields and
have no where to
load. Equally if a Software Module is constructed with the wrongly numbered
field as
described above, it is unlikely to operate correctly when copied to another
application that
does maintain parallelism in field numbering.
METHODS TO ENABLE DATA TO BE RELATED; DEFINING GROUPS
~ The Nature of Data Grouping
One part of the subject data manipulation is the subject of creating and
uncreating
assemblies of Data Components - i.e. relating Components to one another, and
then further
relating the Component Assemblies so produced. At a higher level, this appears
in the state
of the art and is referred to as groups, and the subject of creating and
destruction of groups.
In this light, the subject of creating an output, is the subject of grouping
data or assembling
the many Data Components to be output.
In the state of the art, the programmer dictates the grouping of data, and the
One-to-
Many construction state of the art software limits what data can be grouped,
and dictates the
only relationships of data that can be output the data. One manner to state
and define a
One-to-Many Machine is any arrangement in which one Component or Component
Assembly
has a fixed relationship with another or other Components or Component
Assemblies. An
alternate manner to state a One-to-Many machine is 'Components fixed with
other
Components in a group'. All state of the art software meets this definition of
a One-to-Many
machine.
Hence in the state of the art, a software package such as address book states:
'there
is a fixed group called an address record and it is fixed to these X members
(each of which
are types of data), and these X members are grouped in a fixed group with
these Y methods
provided to output this data.'
The most fundamental difference and innovation of the Any-to-Any machine
compared
to the state of the art, is that state of the art is built from the first
block of code upwards by
programmers as fixed groups, and the Any-to-Any machine does the exact
opposite, and
builds from the first block of code upwards with no fixed groups whatsoever.
Essentially,
406
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
because the programmer has not created any fixed groups, the user is free to
create any
groups he wishes to, including creating fixed groups if he wishes to do so.
In the terms of output from the Any-to-Any machine, it is rare that the entire
output
required is the value of only one Data Relation Table field - i.e. a screen or
print output
showing the value of one Data Relation Table field and absolutely nothing
else. Therefore, it
is fundamental to understanding the inputloutput methods of the Any-to-Any
machine - i.e.
the grouping of data for input/output purposes - that the basic principles and
methods of the
Any-to-Any machine methods to create higher level Component Assemblies-termed
'groups'
in the state of the art.- are understood.
Some groupings of Data Components are intrinsic in the manner in which they
are
recorded - for example, a basic Data Relation Table record is a grouping of
Data
Components. Some Data Relation Table records, for example, a Sequence record,
is second
stage assembly or grouping of data, and once recorded, becomes an intrinsic
part of the
recorded data. The sequence in which Data Relation Table records are recorded
is also an
intrinsic grouping, in this case, a grouping based on time.
However, a number of other groupings - i.e. relationships of data - are not
intrinsic in
the recording of the data itself, and yet are desirable in terms of
input/output. In order to
group data for Input and Output, the first requirement is a clear
understanding of what a
group is.
84) Definition of a group
Essentially a group can be defined as: 'Two or more datum or data that have at
least
one relationship one to one another.' A group is frequently stated as 'having
common
characteristics', but this 'common characteristic' can be either a Component
in common - in
which case the fact that they are the same component is itself the
relationship, or they can
have no Component in common at all, and are simply a group because someone has
stated
they have a relationship. Hence the most fundamental characteristic of a
'group' is the
existence of a relationship between the two items.
The relationship between the two items can be visible or invisible to the
computer. A
relationship that is visible to a computer is one in which at least one
Component exists in both
items. A relationship that is invisible to the computer can be created by the
human stating
that there is a relationship. One of the most common ways that humans do this
is to give the
two items a common name.
If a boss orders his secretary 'take this letter, open a file, put the letter
inside and label
the file 'Waiting', the boss has just created a group. The letter and the file
do not have any
Component in common whatsoever, but what they do have in common is a
relationship which
exists because the boss said it exists, and a name he gave to the relationship
'Waiting'. This
407
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
group has two members: 1 ) the letter and 2) the file itself. If the boss uses
the group name
and says to the secretary 'Bring me 'Waiting" he will get two physical items -
the letter and
the file. Equally, as another example, the instant a person takes a single
piece of (clean)
paper, and writes one single character on that paper, he has created a group
of two whose
members are the paper and the character. Equally, the mere action of giving
something a
name is also the action of creating a group, whose members are the things
itself, and the
name and the only reason they are a group is that the human has assembled them
together -
'Name X applies to Item Y.'
A user can impose two main types of groupings on data and the Any-to-Any
machine
accommodates both of them.
85) Declared Groups
A Declared group is a group where the membership of the group is the result of
a
human's declaration that two or more things are members of the group. A
'company' is a
group because someone says so, and others agree it is so, and then also say
so. If an
employee is fired that person is no longer a member of the group of that
company, essentially
only because a human said so. The reason for the existence of this type of
group will be
invisible to the computer unless it is told why the members of the group are
members -i.e.
what are the Specifications - the requisite components or component Assembly
presences or
absences - that are to be tested to constitute the group. But, if the computer
is told Why the
members are to be members - i.e. is given the Specification for membership -
the group can
become a Dynamic group (which will be described next) and the computer can add
and
subtract members without requiring user assistance to do so.
Hence the characteristic of a Declared Group is a group, for which the
computer has
no Specification, only the human's statement that the group exists: 'Joe is a
member of the
company'. Note that it is not very easy for a human to create a Declared Group
without
naming it. The statement: "Joe and I are together' leads to the inevitable
question 'in what' or
'why?' and some reply such as 'we are buddies' (the group name being
'buddies').
Occasionally the group is not named 'we both want to see X' - but if it is not
named, then,
there is inevitably a Specification for the group, and the Specification in
this case 'we both
want to see X' and that is what makes the two people into a group.
Hence, for a group to exist, there is either a Name or a Specification, and
there can be
both. Hence:
- Any two or more Components can be a group
- An invariable characteristic of a declared group is that it is named.
- Any two or more component Assemblies should be able to be named
by a human.
408
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- Declared groups may or may not persist for a certain amount of time
and can be destroyed by a human at any moment 'our company no longer exists.'
The membership of a Declared Group does not change unless a human states it is
changed. When he does states the membership is changed, the membership is
changed for
him, but is not necessarily changed for others.
The characteristics of Declared Groups are implemented in the Any-to-Any
machine
by allowing the user to make any pair of anything into a group and providing
for any pair of
anything to be named.
86) Dynamic Groups
A dynamic group is a group where the membership is the result of a human's
statement that anything containing (or not containing, or any combination of
these) one or
more named Components or Component Assemblies is a group. In this case, the
group may
have no members whatsoever, only a Specification that states the particular
Components or
Component Assemblies that are to be the deciding factors to as to whether
something is, or is
not a member of the group.
A human manipulates Components and component Assemblies by either by naming
them, or issuing a Specification that creates a Dynamic Group and then
manipulating them. If
several items are on a table, for example, a glass a cup and a plate, two
flowers and light, the
human does not say 'Bring me' (the manipulation) 'the glass, the cup, the
plate, the two
flowers and the light that are on the table' (which is the Specification for
the manipulation or
Execution. The human says ' Bring me' (the manipulation) 'the items on the
table.'
A Dynamic Group exists because a human issues a Specification: 'if this
characteristic
and that characteristic exists, it is a 'cat". A 'characteristic' in fact
equates to a Component
Sub-Assembly. A 'cat' is a Component Assembly, consisting of Component Sub-
Assemblies,
and the properties of these particular Component Sub-Assemblies - such as
ears, Pegs etc -
plus the Component Sub-Assemblies that are the actions done by the cat -
running jumping
etc. If a particular Component Assembly is more similar in its Component Sub-
Assemblies to
another Component Assembly that has been named 'a cat', than it is to any
other Component
Assembly anywhere in the universe, it is a cat. While it may sound ludicrous
to describe a cat
as a 'Component Assembly', doing so is helpful to enable a computer to
recognize objects.
This example also illustrates the importance of allowing and enabling a human
to ascribe a
name to any Component or Component Assembly - i.e. to any data whatsoever in
the
computer. If a human had not, at some point in time, given the name 'cat' to a
certain
recognizable Component Assembly, then a 'cat' as such would not exist, even
though the
animal itself would exist. One human seeing what we call 'a cat' running
around, and asked
409
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
what it was, would be forced to reply something like' well it's an animal that
runs around here,
we have few of them'.
Dynamic Groups may have no members whatsoever at the time they are created,
and
the members with Components or Component Assemblies meeting the Specification
can be
purely imaginary. if a boss says to a secretary 'bring me every day at 9.00 am
all the e-mails
you have received', the boss is stating a Specification for a Dynamic Group.
The membership
of the group will not be constant - while everything the secretary bring him
will meet the
Specification, the actual members will be different each time, and no members
exist at all at
the time he creates the group by issuing the Specification.
Dynamic groups may or may not be named, but are often not named, or the
effective
name is the Specification itself. Hence, the boss might say at 09.10 am to his
secretary
'where are the e-mails?' Dynamic groups may be extremely impermanent and only
exist for
seconds. A boss may say to a secretary 'get me all the e-mails Joe has
written'. He may
look at them briefly, not name the group at all and never issue that
Specification again for
many years.
Each single word in a language is an example of a named, declared group. The
dictionary definition of a word effectively states 'if this Component Assembly
and that
Component Assembly exists with these relationships, the symbol for that - the
word for it - is
word X. It is also noticeable that one or more members of all five Data
Categories may be
present in the definition of a word, and that no part of the definition of a
word can be found
that is not a member of one Data Category (and hence of a Data Class) or
another. Hence,
and of interest when constructing a Language Processor intended to take data
out of a Data
Relation Table and turn it into normal spoken language, doing so this is the
process of
determining which spoken word has a Component Assembly that matches the patter
of the
Components and/or component Assemblies that the Language Processor wishes to
output in
the form of spoken language. Effectively, the process of constructing Dynamic
groups as
described here is the fundamental process or method enabling a computer to
speak a spoken
language - i.e. take data entered in any form and output it as clear and
recognizable speech,
whether written or converted to speech by a Text-to-Speech engine..
The characteristics of Dynamic Groups are implemented in the Any-to-Any
machine
by allowing the user to make any Specification into a Dynamic group, thereby
causing it to
persist if he wishes it to, and by allowing the user to name the group if he
wishes, without
requiring him to do so.
The Any-to-Any machine distinguishes between these two types of groups as the
methods required to determine their memberships are different for the two
types of group.
410
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Declared Groups exist on the basis of name only, and Dynamic Groups exist on
the basis of a
Specification and may also have a name.
87) Mixed Groups
Mixed groups are groups containing both Declared members and Dynamic Members.
A group consisting of 'e-mails received' plus 'my summary of e-mails', has
Dynamic members
- the 'e-mails received' - and a Declared member - 'my summary of e-mails'.
When a mixed group exists, a name for its also exists.
The Any-to-Any machine implements mixed groups by allowing the user to create
groups in which both types of members can exist and enabling the user to name
the group
and thereafter, manipulate it by name.
88) Movement of Group Members Between Group Types
Any member of a Dynamic Group can be made a member of a Declared group, simply
by a user stating that it is a member of a Declared group. A boss may say to a
secretary 'For
now, put that last e-mail from Joe in my e-mail folder when you bring it to be
daily.'
A Declared Group member may be made into a Dynamic Group by the human issuing
a Specification. A boss may take a paper out of a physical file, hand it to
his secretary and
say: 'bring me anything else you get like this.'
The Any-to-Any machine implements the movement of group members by allowing
any group member to move from one type of group to the other.
89) Groups and Hierarchies
The vast majority of grouping methods and groups used by humans are non-
hierarchical, and only occasionally are hierarchical groups imposed, such as
when organizing
a company, for example - this department reports to that division.
Hierarchical groupings are
typical of command situations such as a company or organization, and non-
hierarchical
groupings are typical of non-command situations - i.e, typical of most of the
rest of life
situations.
Humans create Dynamic groups that persist for mere seconds: 'Put everything on
the
table in the kitchen' (a Dynamic Group). 'Now being me the flower vase that
was on the
table':
- One Dynamic Group created by the Specification 'Put everything on the
table', and no hierarchy was stated.
- That group was instantly destroyed by moving all the items to the
kitchen - the table was no longer a member of the group
- A new Dynamic group was created - the items which had been on the
table (minus the table) were moved to the kitchen and made into a new group
with
the kitchen.
411
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- That Dynamic group too was also instantly destroyed, by removing the
flower form it.
The creation and destruction of Dynamic groups, as the above shows, is a rapid-
fire
process and applies equally to computer manipulation of data as shown by this
example of a
user order, paralleling the above example of items on the table: 'Put all the
e-mails from Joe
('held in memory' (= group 1, memory + the e-mails) onto my screen (= Group 2,
destroying
Group 1). OK, show me the third one full size' (Group 2 is now destroyed).
Thus, the majority of human activity consists of creating groupings, most of
which are
Dynamic, and almost none of which are hierarchical.
A human, very occasionally - compared to his total use of groups - creates a
hierarchical group when it suits a particular purpose to do so. He will put
cups and saucers in
a certain cupboard, thereby creating a hierarchical group of cupboard - cups -
saucers. He
will state Department X reports to Department Y, and thereby create a
hierarchical group.
The entirety of data manipulation is some manner of grouping. Only a small
portion of
human grouping activity is hierarchical. In the state of the art however, it
is close to difficult to
find anything in a computer from software to data that is not in a hierarchy.
A human cannot
say to his computer - for example - 'record the name Joe Brown' without going
through the
hierarchy of 1 ) Open address software 2) Fife 3) Open. 4) New Record 5) Joe
Brown.
However, supposing a boss says to his secretary, the name 'Joe Brown' for the
very
first time - he has never said that name to her before; the boss says 'Joe
Brown' and nothing
more. The secretary is likely to reply 'What about Joe Brown?' Her reply shows
that she has
already recorded the name 'Joe Brown', without requiring any hierarchy
whatsoever required
to do so - the only action the boss had to take - the only user intervention
required - was get
the secretary's (computer's) attention. If the user does create a hierarchy
and place
something in it - for example by saying: 'Place this letter to Joe Brown in a
folder marked
'Clients", in a boss/secretary situation, the boss can still also access the
letter not
hierarchically. He may say to his secretary 'bring me the Joe Brown letter'.
Hence, in human
data manipulation, placing data in a hierarchy does not prevent other, non-
hierarchical
access, whereas, in the state of the art, it does prevent any other non-
hierarchical access.
(For example, the user now should go through the hierarchy of an explorer or
find mechanism
- he can not just say directly - get me the Joe Brown letter'.
Hence, one of the methods of the Any-to-Any machine is the complete
elimination of
any and every compulsory hierarchy, except for the requirement for the user to
get the
computer's attention, a requirement that is acceptable as it is also found in
inter-human data
manipulation. Additionally, the Any-to-Any machine grouping methods, allow any
data to be
placed in a hierarchy - but do not compel it to be placed in a hierarchy - and
even when
412
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
placed in a hierarchy, enable any part of the data to be accessed non-
hierarchically. Part of
the method of the Any-to-Any machine for eliminating hierarchies other than
those humans
impose, is to store all data in the tables of the Any-to-Any machine - the
manner described -
in such a manner that, as far as the human is concerned, these tables are a
transparent
whole.
90) Unlimited Nature of Group Membership
In the days before computers, humans frequently stored documents in paper
files and
metal filing cabinets, and thereby found themselves subject to the inevitable
problem created
by any storage hierarchy - namely" that an item in one hierarchy becomes
immediately
unavailable for storage in any other hierarchy. Extensive use of photocopiers
provided a
solution with its own problems, and enabled a copy of a document to be placed
in multiple
files.
Computers, in the state of the art, have copied this essentially only semi-
workable
mechanism and the result is seen as the widespread 'directory file system'; in
copying the
system, the system's problems were thereby copied also.
As the description of a Dynamic Group above demonstrates, a given document or
item
may be Specified by the human to be a member of ANY group based on ANY
Component, or
Component Assemblies or combinations of Component Assemblies, and these can
also
include the Components, Component Assemblies and Combination of Component
Assemblies existing outside the item itself - for example present at its
creation, or any time in
between. For example, the user could say 'get me the spreadsheet I did on my
portable
during the flight to New York.' The only part of the Specification internal to
the item is the
word 'spreadsheet' and all the other Component Assemblies are exterior to the
item.
Additionally, an item may be ordered to be a member of Any thing else, based
simply on a
human saying it is a member of a group with that other thing.
In effect, the number of copies of any one item that can be required is
potentially
unlimited.
Also, when a human wants to group a document with something else, he may
either
want to group what that document is, or what it used to be. In the state of
the art, if a user
wants to the group a document in the form in which it now is - i.e., the
latest modified, saved
forms - this requires linking one document to another. Since the potential
requirement is for
an unlimited number of copies, this potentially implies an unlimited number of
links to an
unlimited number of documents - and a degree of complication that is equally
unlimited.
Therefore, it is evident that to serve the human requirement for Any one datum
or data
to be able to made into a group with Any other datum or data, there can only
ever be one
instance of each one thing. It is the reference to that one instance of that
one thing that
413
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
should be grouped and not the thing itself, since the reference can be grouped
an unlimited
number of times, without affecting that which it references in any way.
Hence, the Any-to-Any machine method of grouping only ever groups a reference
to
something, and does not group the thing itself, for as soon as the thing
itself is grouped, the
potential complexity becomes logarithmic, with consequent logarithmic increase
of failures of
the linking mechanism, due simply to the complexity required.
91 ) Groups and Group Names are User-Dependant not Data-Dependant
A group may exist in a company called 'clients', with the common
characteristic that
'clients' are people or companies who have bought something from that company.
A boss
may issue an order: 'Show me the clients." If he gives the order to his
accountant, he will
probably be shown a list of client names and amounts paid and owed, printed on
several
sheets of paper in a certain format - a View in the terminology of the Any-to-
Any machine. A
View is essentially, a certain grouping of data for input or output purposes.
Each time the
boss asks the accountant for 'the clients', he is likely to get the same list
similarly formatted.
For the accountant, this list is 'the clients' - 'the clients' is the name of
that list - the name of
that View.
But if the boss gives his salesman the identical order 'show me the clients',
he is likely
to get something completely different - a list of names showing the names of
the clients and
their purchases last month. To the salesmen, this list is the 'the clients' -
'the clients' is the
name of that list - the name of that View.
Neither the accountant nor the salesman are likely to give the boss literally
what he
asked for - i.e. bring in the client physically one by one and parade them in
front of the boss,
or take the boss physically to see the clients one by one.
In the two examples, the grouping of data is not at all the same, but the name
is the
same. The grouping that is designated by the name of the group is dependant on
the user,
not on the data.
Hence, the Any-to-Any machine method of grouping treats group names as
dependant on the user, and allows different users to name the same data
different ways and
to use the same names as one another for different groupings of data.
~ METHODS TO ENABLE A COMPUTER TO INPUT & OUTPUT DATA
MANIPULATED BY AN ANY-TO-ANY DATA ENGINE
~ Requirements to Reduce User Intervention in input l Output
OUTPUT NEEDS TO BE ABLE TO BE CONTROLLED BY DATA
Displaying data by an Any-to-Any data manipulation engine as described in this
Any-
to-Any machine has, as one requirement, that the data and the display of the
data should not
414
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
be wired together, but, on the contrary, that Any display (our input/output)
can be used with
Any data.
The Any-to-Any machine requires some description of interface, the ability to
record
and manipulate any data in relation to any other data in a data manipulation
engine such as
the Any-to-Any machine is itself useful, but is more useful if the abilities
also exist to enable a
user to:
1. )nput data to engine in a convenient manner and,
2. To see the results of the manipulation in a convenient output such as on a
screen or in printed or other output.
When a great deal of data is potentially available - as for example in a
single pair of
Data Relation Table records that are the minimum required to record a
communication from
one person to one other person - there is necessarily a requirement to be able
to select and
display from this data, the data that is required to be visible. This
requirement has a corollary
requirement that the data that is not selected should not also be made
visible. If there are
300 or so fields in the two records, there should be a method to display just
those fields that
are relevant and to avoid displaying those that are not relevant. For example,
a user might
wish to select communications based on particular data in the following Data
Classes:
1. Who they were from
2. Who they were to
3. When they were sent
4. A brief view of the contents
The above request can take up all or a large part of available screen space.
However,
he might also wish to see the following list derived from the identical Data
Relation Table
records on the basis of his selection:
1. Title of the sender
2. Title of the receiver
3. Location to which sent
4. Location at which received
5. Type of communication
6. A brief view of the contents.
This request might also take up all a large part of available screen or output
space. In
the state of the art, this kind of problem is often handled by making the user
intervene and
select the columns required andlor by manually changing between 'views'. Such
a solution is
not satisfactory because f ) It requires user intervention 2) User
intervention requires user
understanding, and hence this procedural method both prevents Automatic
Software
Execution (Execution proceeding without user intervention - in this case, with
requiring user
415
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
intervention to state a Specification such as column selection or a view) and
3) increases the
difficulty of use as well. Consequently, there is a requirement that the
user's request for data,
or (in the case of input) his statement of data itself needs to be able to
control to the display.
DATA AND ITS DISPLAY SHOULD NOT BE CONNECTED IN A FIXED RELATIONSHIP
When a boss gives an order to a secretary requiring her to carry out a number
of
steps, he does not usually do so, then move into the secretary's office, and
watch her carry
out each step. However, in the state of the art, when an order is given to a
computer that
chains together a number of commands, the practice is to take over the screen
while the
- commands are executed, preventing the user from continuing with other work.
For example,
in the state of the art, if a number of unopened documents are printed as one
order, the
screen flashes with each document as it is opened, printed and then closed;
and other work is
difficult in the meantime, and this occurs because the screen is irrevocably
connected by the
programmer to the data. The screen display is unnecessary, as the user can
see, or be told,
whether his documents have been printed successfully or not. Consequently,
there is a
requirement that the display of any data can be turned on or off as
appropriate.
FIELD AND FIELD LABEL SHOULD NOT BE CONNECTED IN A FIXED RELATIONSHIP
It was previously stated that the data recorded in a particular field of the
Data Relation
Table - i.e. in a particular Data Class - is likely to contain a number of
different sub-types or
Sub-Data Classes. It was also remarked that when this occurs, the Sub-Type of
that data
needs to be recorded in a corresponding Data Sub-Class field.
It is evident that when this is done, the Label that needs to be displayed or
output for
the requested data is the actually the Sub-Type of the data - i.e. the Label
to be displayed
for the field depends on the data itself and should be able to be controlled
by the data. If the
user asks 'what is 818 333 1449?' the computer should be able to answer by
displaying the
Label, which in this case is the type of Reference Number: 'A Telephone
number'.
Consequently, there is a requirement that the data itself has the ability to
control its own
display or output. However, this is not normally possible in the state of the
art, where the
label to be displayed for a field is fixed and cannot be changed without
changing the field
name for everything that field displays.
Hence, some of the requirements for display/output control of Any-to-Any
manipulated
data are that Input/output displays need to be to be controllable:
a) by the nature of the user's orders,
b) By the Data itself
c) So it can be switched on or off and
In order to achieve these, Input and Output of data should be separated from
the data
itself, so that Any input/output can be used with Any data.
416
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
~ Method to Enable Input and Output of Any-to-Any Manipulation; Preserving
the User-Independence of Data
User data, particularly in a multi-user environment such as a company, is not
user-
dependant. The data is what the data is, no matter who created it, who views
it, or who
manipulated it. Problems arise when this fact is not respected in software
construction.
State of the art software mostly treats data as user-dependant. As an example
of this,
if a user creates a certain piece of data, such as a spreadsheet, what the
spreadsheet looks
like depends on that user - how he saved it - and has become user dependant.
If a second
user wants to look at this data the same way and also differently - for
example, with the same
data manipulated by different calculations - the only available choices are
themselves
problems:
3. Save the spreadsheet with a new name and make the changes on
another sheet of the new name spreadsheet. There are now two versions of the
same
data in the company. If one version is changed, the other is now wrong and
this can
become a problem.
4. Change the original user's spreadsheet - to which the original user is
likely to object and this can become a problem
5. Save a new version and link all the data in the second version to the
first version. This is tantamount to re-writing the spreadsheet and this
creates one
problem - the additional work required - and a second problem if the first
user changes
or deletes some data. The change or deletion by one person can render
meaningless
or incorrect the work of the other.
As a further example in the state of the art, company data that can be seen by
certain
users and not by others, is placed in a specific directory and then, and
access rights are
assigned to certain users to use those directories. As soon as this step is
taken, the data that
can be known to exist depends on the user and has become user-dependant. If
another
user, who should not have access to all the data in a directory, needs access
to one file in it,
a problem is immediately generated and the only choices are themselves
problems:
1. The user can view the data on a machine where someone other than
the un-authorized user has logged on with rights to that document, so that he
can view
the document he needs to view. However, the problem now exists that
unauthorized
viewer now has access to everything that the log-on user has access to - and
hence to
things to which he should not have access - in addition to the one he was
intended to
be allowed to see.
2. Someone can stand over the user while he views the one document he
is allowed to see. This is a problem as it wastes people's time.
417
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
3. A New directory is created to which he and the others have access, and
the single document in placed in it. This creates the problem that everyone
except
that user can think the document has vanished, and requires communicating the
new
location of the document - and a further problem is that creating and reading
the
notification is a waste of people's time.
As a final example, users, particularly salespersons tend to keep data private
concerning their contacts and this is possible because the state of the art
software system is
user-dependant. Not infrequently, if salesperson leaves, his clients leave
with him and may
not even be known to the remainder of the company, and this can cause a
problem
The importance of user independence of data is embodied in the User
Independence
of Data Principle and Method, which is defined as follows:
The existence and nature of any data in a computer is a fact that does not
depend on any person and hence, needs to be kept in a user-independent manner.
Who views that data, how they view the data, and who manipulates that data and
how
they manipulate it, are all user-dependent and consequently should be able to
be related to
any user or users by the simple fact of a user or users so ordering it.
equally, for
convenience in the state of the art, one user is treated as being the same as
another - i.e.
users are treated in groups and assigned to directories they can and cannot
see. However,
data does not fall into such convenient blocks. In effect what is required,
that is not possible
in state of the art, is that data should be able to be restricted from certain
people or restricted
to certain people, and because one document has a certain pattern of
restriction that is
required, does mean the next document has an identical restriction pattern. In
order to track
with human handling of data, Any restriction needs to be able to be applied to
Any item, to
restrict it to, or from any user or group of users without affecting the
existence or nature of the
data that is viewed or manipulated.
Confidentiality of data - and its opposite, broadcast of data is has nothing
to do with
the data itself, and is uniquely a matter of the output of data.
The above Principle contains two points 1 ) that the existence of data is not
user-
dependant and that 2) Viewing or outputting data is user-dependant and should
not affect the
existence or nature of the data viewed. Expressed colloquially, the data is
one thing, and how
it is viewed is another. A Book exists. One person can read every page,
another can read
the page that interests him, photocopy them write on his photocopies and show
them to
others, photograph them and - whatever he wishes. But, doing any of these
things does not
affect the book itself; the practices of tearing pages out of books, putting
lines through
paragraphs or writing in the margins are not generally considered desirable
habits. Software
should avoid them, in order to act in a human-like manner.
418
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Failing to provide mechanisms in software whereby data can be viewed and
manipulated in a user-dependant manner has the immediate result that the state
of the data -
and potentially the existence of the data also - becomes user-independent. If
data a user
cannot output data without changing the data itself, then the data has become
user-
dependant, with the ensuing problems.
~ Methods to Enable Input and Output of Any-to-Any Data Manipulation
SELECTION He DISPLAY
The selection of data and the subsequent display or output of data based on
the
selection may or may not be identical.
A user may ask to see 'the letter to Joe' - in which case, the selection of
data and the
display of data are identical.
Alternatively, the user may ask to see 'letters sent to clients in New York.'
In this case,
the selection ' clients in New York' is one selection, and the subsequent
display of data -
letters - is a second selection that is different to the first'selection and
is the one actually
displayed. If a user made the above request it would be optimum to fill his
screen with the
letters he requests and not take up much of the space showing one tabular
field headed 'type
of relation' where every field shows the value 'client' and another field
headed 'Town' showing
the value in every field of 'New York'.
Hence, a part of the Any-to-Any Input/output methods of the Any-to-Any
machine, is
Any Specification lnputlOutput display can be used with Any display or output
of the resulting
manipulation.
INDIVIDUALITY OF DISPLAY/OUTPUT
In a group environment such as a company, the same data may be of interest to
a
number of people who work in that company. Assuming that most of a given group
of people
who wish to see given data have different jobs and therefore, different
purposes, the optimum
manner to view any given data will differ from one to the other. An accountant
may wish to
see amounts owed by clients in an extremely prominent position, with the data
sorted in the
order of who owes most first. A salesperson may be best served by seeing the
same data
with recent payments to the account made most prominent, sorted by who paid
least showing
first. In these examples, the view of the data does not change the data
itself, and the data is
not dependant on the user, but the required view of the data is dependant on
the user.
Hence, another part of the Any-to-Any Input/output methods of the Any-to-Any
machine are that Any Input and Any Output of Any data can be adjusted to Any
and every
user's requirements, without affecting the data itself.
419
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
INDIVIDUALITY OF DISPLAY/OUTPUT
Early in the state of the art, screen output and printed outputs differed, and
this
difference was unpredictable - it was not possible to see what the printed
output would look
like without actually printing it. This problem was solved with WYSIWYG - What
You See Is
What You Get, and this method created a fixed relationship between screen
output and
printed output. In the state of the art, different forms of output are fixedly
related to one
another, in a One-to-Many relationship - One screen format, one or many
examples of that
formats output on a printer - the printer output is fixed to the screen output
with a fixed
relationship. While this may be desirable some of the time, it is not
desirable all of the time.
By reason of this fixed relationship it not possible to modify one output,
without also modifying
the other output. For example, if a user wishes to see two pages of a document
on the
screen at the same time, so that the pages are in portrait mode, arid, from
time to time print it
landscape, he can not change the print output without also changing his screen
output. Even
if he does so, and then returns to his screen format, he should repeat the
process in order to
print the document in portrait mode. In effect, the output of the data can
only be changed by
changing the data itself - in this case the appearance of the data.
Constantly changing the look of the data in order to make it suitable for a
given output
requires not only user intervention - and hence user understanding - but also
thereby
prevents Automatic Software Execution.
Hence, another part of the Any-to-Any Output methods of the Any-to-Any machine
is
that Any Data can be output in Any number of different formats and, if
required, at the same
time. Thus, any given data - for example, the document referred to above - can
have one
format for the screen, a second for one printer, and a third for a projector,
and, if required,
output to all of these simultaneously, without requiring user intervention
after a specific output
format has been set up once. In effect, this also means that while the screen
shows one
thing, the output to a projector or Website, for example, can be a completely
different view of
the data. Hence, a Specification for a manipulation is shown on one screen,
while the
manipulation resulting can be shown on another, possibly distant screen. This
ability provides
advantages such as using one screen to input data and order manipulations,
while using
another to watch what the Software Modules are actually doing as a result of
the manipulation
orders.
THE NATURE OF LANGUAGE
As soon as any two of anything are assembled together into a group, a
relationship is
established is established between them and a relationship now exists between
those
assembled Components. In computer terms, where the computer is dealing with
symbolic
representations of those two things rather than with the things themselves,
stating the
420
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Components and stating the relationship between them, states the thing itself
in a computer-
recordable form.
Hence, the subject of an 'understanding computer' is the subject of recording
symbols,
each of which is a Data Component (as it represents one meaning) and then
recording the
relationships of Components.
Spoken and written Language as used by humans communicates relationships of
concepts - of meaning Components.
Language and can be analyzed as a compressed multi-multi-level assembly of
Data
Components with each assembly consisting of more and more meaning Components.
As described previously, a word is in fact a group. Most words have several
meanings, and hence a word is a group that is an assembly consisting of a
symbol plus the
meaning Components grouped with the symbol. Additionally, the meanings of a
given word
are defined in terms of other words, each of which is also a Component
assembly and
potentially a multi-level Component Assembly. Hence, even an apparently simple
structure
such as 'a word' is in fact a multi-stage Component Assembly.
Hence a 'a word' can be considered one assembly stage of meaning Components.
The first stage of assembly in the course of human-human information
transmission is
followed by a second assembly stage in which the word is transmitted with a
specific physical
relationship to another - as will be described below - and this stage of
assembly follows a
method, and this method is embodied in the Any-to-Any machine in computer
terms as the
'Co-reducing Concept Principle and Method.
Finally, there is a last stage of assembly of the transmission that is 'spoken
language'
and this last stage is performed by the words themselves acting on other words
at a physical
distance from their own physical position. The first two levels of
assembly/disassembly can
be done by this Any-to-Any machine, but the third and final level requires a
full Language
Processor in order to disassemble and assemble it. For example, a person
saying: 'He
jumped that.' illustrates the third stage of assembly:
1 ) One assembled package of meaning that is represented by the
symbol 'he'
2) A second package of meaning that includes past time and a
package of meaning represented by the symbol 'jump'
3) A third package of meaning that is represented by the symbol
'that.'
This third level of assembly in the course of human/human transmission
requires a full
Language Processor to disassemble it for.storage, and to take stored Component
and their
relationships and output them as speech such as 'he jumped that.'
421
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
In practical terms, the teaching of the Any-to-Any machine that enables
language to
be 'understood' by a computer is that language should be disassembled into its
Components
and stored (recorded) as a) its Components and b) relationships of Components.
Storing
component and their relationships also specifies their assembly when
required.. This
teaching solves the problem in the state of the art, where attempts at
'Language Processing'
fail to achieve the objective of understanding what the user 'means'. This
failure occurs
because state of the art Language Processing attempts to use as its
computational unit,
multi-level Component Assemblies called 'words' and from this to compute the
relationships
stated by the words. The Any-to-Any machine teaches that attempts to
understand what the
'10 user 'means' require use of the Any-to-Any machine method - i.e.
disassembling language
into its Component Assemblies, and further disassembling Component Assemblies
including
words, into Component meanings and their relationships.
As far as a computer is concerned, 'understanding' the user requires the
ability to
disassemble language into Components as part of the input process.
'Understanding the
user' in its ultimate form also requires the ability to reassemble Components
into language.
In effect, input into an Any-to-Any data engine is a disassembly process and
output is an
assembly process.
Every assembly and disassembly stage consists of 1 ) Components and 2)
relationships of Components.
As stated above, one of the stages of assembly of language is stated by the
physical
relationship of one word to another word. The physical relationships of user
communication
units such as words is unavoidably the province of the Input I Output
interface to the Any-to-
Any machine.
The part the interface is required to play, in order to accomplish its task in
the
assembly/disassembly process, should be clearly understood in order to:
Construct input output methods and mechanisms correctly
2. Construct the Any-to-Any machine in such a manner that it can provide
the interface with information the interface requires, and that only the Any-
to-Any
machine has available.
The part played by an interface in the assembly and disassembly of data is
embodied
in the Spatial Relationships of data as follows:
THE RELATIONSHIPS OF DATA ARE PARTLY COMMUNICATED BY THE SPATIAL RELATIONSHIPS
OF DETECTABLE DATA
As far as a computer is concerned, humans partly assemble their data
transmission
(speech etc) using spatial relations to state part of the relationship between
transmitted
Component Assemblies (words).
422
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
As an example of this, suppose that one human says to another:
'Get. This e-mail is a problem - I really do not like it. You know, Bill, we
really
should not have sent it. Joe.'
Bill, who is listening, will understand something from the above statement.
But his
understanding is likely to be the same as if he had heard the following
instead:
'Get Joe. This e-mail is a problem I really do not like it. You know, Bill, we
really should not have sent it.'
The relationship of the Component Assembly (word) 'get' to the Component
Assembly
(word) 'Joe' is stated by the fact of the spatial relationship of the one word
to the other - i.e.
1 Q the fact that the one word is physically - spatially - next to the other
word. In the above
example, the spatial relationship of the spoken words consists of a certain
physically
measurable pattern of air movement that is detected as 'Get' being immediately
followed at a
physically measurable distance by another physically measurable pattern of air
movement
that is detected as 'Joe.'
Similarly, if the word 'Joe' is shown at the top of a computer screen, and
'Brown' at the
bottom, with other data in between, the user's reaction will tend to be 'which
Joe?' 'which
Brown?'. But if the same two data are displayed spatially next to one another:
'Joe Brown',
the reaction is more likely to be 'Oh, him. Yes, I know Joe Brown.'
This method generally used by humans to state the part of the relationship of
transmitted data as described above is not the only possible method, nor is it
the only method
used by humans. Words themselves are one method (they state a specific
relationship of
their Components), the Co-reducing Concept Principle is another, the highest
level of
language assembly is yet another. The conductor of an orchestra uses a
completely different
method to state the relationship of one note to another note - he uses time to
relate them,
and the baton as a way of stating that time.
In practical terms, stating and recording in a computer the relationship of
one
Component to another, or the relationships of assembled Components, requires
that there is
only ever one instance of any given Component or any given Component assembly.
As
previously described, if the thing itself is physically related to other, the
process eventually
become impossibly complex, and the only workable solution is to have one
instance of any
item, and thereafter, create relations to that item by using a reference that
states it or names
it..
As soon as there can be N instances of a given data A, and X other data to
which the
data A is - in actual fact - related, each of which has M instances, then the
number of
relationships that have to be able to found or traced, is X""'. It becomes
effectively difficult, in
practical terms, to trace or state relationships and considerable confusion
results. If these N
423
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
instances of data can occur in Z places - inside different directories, and
inside different
letters for example- then the number of relationships to be found or traced
becomes XNnnz.
Finding the relationships that actually do exist - whether they can be found
or not -is an even
more impractical proposition. However, this is the situation in state of the
art software
construction, where, for example the name of one single person can occur in:
N instances of the name in letters in Z directories
N instances in emails in Z directories
N instances in account software in Z directories
N instances in N people's address books in Z directories
N instances in spreadsheets in Z directories
N instances in databases in Z directories - etc
Finding all instances of just one piece of data - one person's name - is a
practical
impossibility. Recording the relationship, once all instances have been found,
becomes
equally difficult, especially if the only way of doing so is the state of the
art method of
physically connecting one Component Assembly to another. This already
difficult situation is
made even more of a problem in the state of the art, because the security
permission system
means that the only people in the entire company who even have the necessary
permissions
in the computer to even attempt to find all instances of anything, are perhaps
half a dozen
senior executives and the computer Administrator. Hence, the state of the art
method of
allowing any number of instances of any data effectively prevents
relationships of data that
exist in reality from ever being found. Secondly, it should be noted that the
state of the art
method for restricting access to data is intrinsically incompatible with the
requirement to relate
any data to any data. The state of the art security methods in use, by
themselves alone,
prevent the relations that actually exist in data from being able to be known.
Since, as it has been shown, a human, in terms of manipulating data, works
entirely
by manipulating meanings and relationships of meanings, the problem in the
state of the art,
is that the state of the art methods prevent relationships that exist from
being discovered,
hence prevent them from being manipulated and hence prevent a computer from
emulating
human data manipulation.
The Any-to-Any machine provides methods to control access data that preserve
confidentiality, and at the same time do not interfere with discovering the
relationships that do
exist in recorded data. While this will be described in detail later, the Any-
to-Any machine
enables this to be done, partly with the method of separating the manipulation
of the data
from the display of the data. Confidentiality requires restriction of data
output, not restriction
of data manipulation, and consequently, data can be manipulated by software
without regard
for confidentiality. Hence, in the Any-to-Any machine, confidentiality
restrictions operate just
424
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
before output; additionally confidentiality restrictions can be applied from a
single field
upwards, and any confidentiality can be applied to any output, to any people,
and to any
group of outputs or groups of people. Additionally, the Any-to-Any machine
methods a)
permit the user to know what has been restricted, and by whom and to apply
automatically for
permission and b) permit non-confidential outputs to be generated on the basis
of confidential
inputs. For example, the total sales figure for a company in given period may
be non
confidential, while the total sales to each individual client (on which the
total sales figure is
based) is confidential. The Any-to-Any machine's methods for ensuring
confidentiality and
data security accommodate such requirements while not preventing relations
between data
that do exist from being found and used.
The Any-to-Any machine methods also solve the second problem described above -
namely that in the state of the art, the practice of allowing multiple
instances of any given data
makes it effectively difficult to discover the relations between data that
actually exist. There is
only every one instance of any given Data Component and only one instance of
any given
data assembly, and that one instance is only ever in one place. All further
uses of that one
instance are always and only in terms of a reference to that one instance, and
those
references themselves can only ever be in one place. Hence, with the Any-to-
Any machine
method, the number of relationships that have to be found or traced is X'.
(Note that as
previously described, a number of Data Relation Table and other tables can
exist, and these
are not necessarily in identical locations. However, as also described, when
this is the case,
Converter Software Modules have the result that data is one logical place as
far as other
Software Modules are concerned),
However, this method of the Any-to-Any machine - ensuring that there is only
ever
one instance of any given datum or combination of data - places an unavoidable
requirement
on the interface. The interface should be capable of spatially relating every
single instance of
any given data to the single instance of any other given data when outputting
any data, in
order to state for the user the relationship of those data that actually
exists in the Data
Relation Table.
In summary, the requirement to find relationships imposes the requirement for
there to
be only a single instance of each data for which the relationship may need to
be found. The
requirement that there can only be on instance of each data imposes the
requirement on the
interface to be able to physically, spatially relate that one instance of the
one datum to the
single instance of another datum. Colloquially, the interface should be able
to output the one
instance of a phone number next to the one instance of a name and thereby
communicate to
the user the relationship of the data - i.e. that this is the phone number of
that person. The
interface may be required to output this spatial relationship of these two
data to a certain
425
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
physical place on the output or screen. Then, perhaps seconds later, the
interface may be
required to put that same instance of that same phone number in another
physical
relationship, in another place on the output or screen. For example, at one
moment, the
interface may have to display the phone number spatially next to a person name
to
communicate the relationship that this phone number belongs to that person.
Instants later,
the interface may be required to output the single instance of that telephone
number on a
screen that looks like 'a letter', so that the spatial relationship now
communicates that this
phone number is the phone number for Company X. However, the interface, in
each case, is
only outputting the single instance of that one phone number that exists in
the computer.
In the state of the art, in contrast with the above requirements in order to
manipulate
and input output data in any Any-to-Any manner, a given phone number may
perhaps be
found in the data of several software packages and equally, several times
within a given
package. In a company environment, a given address of a given company may
occur in
hundreds or even thousands of instances within addresses, invoices and e-mails
recorded on
different hard disks around the company. The physical, real world reality,
however, is that
there is only one phone number and there is only one address, and the Any-to-
Any machine
methods reflect this reality. In real life, a given phone number may be
related to a certain
person and to a company and to a building - those are its real relationships.
A second
person may meet the first person, and then the phone number is additionally
related to both
of these people. While a given telephone number may be normally related to a
given person,
it is not intrinsically related to any person. The Any-to-Any machine has the
ability to reflect
this reality. In the Any-to-Any machine, the single instance of that phone
number is not
intrinsically and fixedly related to anything (and so can be related to
anything), in contrast to
the state of the art, where it is intrinsically and fixedly related to a name.
Hence, in the Any-
to-Any machine, because the single instance of that one phone number is not
intrinsically
related to anything, it is free to be related to anything - i.e. to one, or
two or more people.
Thus, if relationships of data are to be able to be recorded in practical
terms, it
becomes a requirement of the interface that it is capable of stating its part
of the relationship
of data, by using the spatial statement method - the same method that a user
also uses to
state the same part of the relationship of data.
Hence, the ability to state a relationship of data by controlling spatial
Input/output
relationships of data is a concomitant requirement to the ability to
manipulate data on an Any-
to-Any basis. However, in the state of the art, the Input/output part of a
given software
package - screen displays etc - are fixedly related to both the manipulation
of the data by the
package and the storage of the data, making it difficult to meet this
requirement. Further,
attempting to display the result of Any-to-Any data manipulation with state of
the art methods
426
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
requires the programmer to construct one screen display for each of every
possible
combination of relationships of data. This again is a problem because it is a
practical
impossibility.
For a computer to be enabled to both relate any data to any other data, and to
communicate the relationship, the computer needs to be able to create 'Spatial
Data Relation
Statements.' A 'Spatial Data Relation Statement' is defined as:
A physical input or output of data in which the physical relationship of Any
one
part of the Input/output data, to Any other part of the Input/output data
conveys part
of the relationships of those data.
Creating a Spatial Data Statement requires that the software has the ability
to control
the physical placement of each datum in the Input and also in the Output,
since exactly where
each datum is placed physically in relationship to another datum or to other
data states, for
the human, part of what their relationship is.
The Any-to-Any machine includes methods that enable an interface to make
Spatial
Data Relation Statements. These methods cover all types of input and Output.
Colloquially,
they are methods that enable suitably constructed interface - Input Output -
software to know
what data to display and where to display it so that the spatial relationships
of the Input and
the Output convey that part of relationship of the data that is normally
conveyed by spatial
relationships.
Considering the term 'interface' to describe those mechanisms that input data
to be
manipulated and output all data that has been manipulated, then the
requirement for an
interface to an Any-to-Any data manipulation engine it that it is capable of
Any-to-Any input
and output. 1n the case of an interface, 'Any-to-Any' means that it can accept
any number of
one instance of something and relate it spatially to any number of one
instance of any other
thing, in a manner that is not intrinsically hierarchical and which is
intrinsically unlimited.
In order to achieve the above, such an interface needs certain support and
services to
be provided by the Any-to-Any data manipulation engine, as follows:
~ Method to Enable a Computer to Perform Spatial Data Relation Display
Control
The general method of the Any-to-Any machine to support the input and output
of data
is as follows:
1 ) To treat any and every input and output as a selection of (translated)
values contained in a selection of Data Relation Table fields and records
and/or a
selection of field and records from other Tables in the Any-to-Any machine.
Hence, the basic input/output unit is the (translated) value contained in or
to be
entered into a single Data Relation Table field (after translation), or to a
field in
427
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
another type of Table in the Any-to-Any machine. (The word 'translated' is
stated
above, as data entry and output normally uses the spoken language whereas the
Data Relation Table only contains Numbers Concept Language, and hence any
input or output intrinsically includes the process of translation into and out
of
Numbers Language).
2) To treat every output or output as an assembly of field values from
records contained in the various tables of the Any-to-Any machine
The value contained in (or to be entered into) any field or fields in any Any-
to-Any
machine Table needs to be able to be displayed in a specific spatial
relationship to the value
contained in (or to be entered into) any other field or fields. Similarly, the
value to be input
into any Any-to-Any machine Table field needs to be accepted from the user in
an area or at
a time that has a specific spatial relationship to whatever output is used to
tell the user a input
can be accepted and the type of the input that is acceptable. This is achieved
as follows:
1 ) Each single field (as described above) is displayed in its own and
corresponding area of the screen (or output). The corresponding area of the
screen or output is termed an 'Active Element'.
2) An 'Active Element' is an input and/or output Logic Assembly such that
any one Active Element acts as a channel to one single field at any one time.
3) An Active Element consists of a number of different logical parts, each
of which is a software Component assembly assembled from Logics. Collectively,
the Assemblies of Logics in an Active Element are termed 'Active Element
Logic'.
4) An Active Element that appears visually in input or output is a copy of
the recorded Active Element. Accordingly, the number of Active Elements of a
given type that can be used at any one time is not limited.
5) A particular Active Element (copy) can act as a channel to a number of
different records at the same time, but, generally, acts as a channel to the
same
number of field in each of the different records. In other words, an Active
Element
can service more than one record at a time - for example, one part of the
Active
Element can accept data form the user, another part can display a Label, and a
third part can displays a color format that makes the Active Element look like
an
Icon.
6) Each Active Element Logic is itself contained (as a reference) in a Data
Relation Table record that acts to specify the Active Elements Logics to be
used
for each field of a given Input or Output that is to be serviced. Other data
that an
Active element Logic may require - such as colors to be used etc - are stated
in
428
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
other record Data Relation Table record types used by that Active Element
Logic.
Such records are termed 'Associated Records'.
7) Each different Associated Record that is used by an Active Element is
handled by a separate Assembly of Logics. These can either be combined into a
single Execution Record, or if preferred, separated into individual Execution
records, so that one Active Element Execution record services a particular
type of
Associated Record.
8) An Active Element can input to only one Data Relation Table field at
one instant of time.
9) The content of any Data Relation Table field or the content of any field
of another table can be displayed simultaneously by any number of Active
Elements.
10) The physical position of each Active Element in relation to another
Active Element - i.e. the Spatial Data Relationship Statement - is controlled
by a
particular type of Data Relation Table record that specifically states this
spatial
relationship. Because the computer can control the position of one Active
Element
in relation to another in input and output (and hence control the position of
the data
displayed by the Active Element) the computer is enabled to make Spatial Data
Relation Statements.
11 ) Active Elements are not necessarily square or rectangular, but can be
any shape the programmer wishes to create. Generally, borders and the simpler
shapes such as arrows, call-outs and other shapes found in office suites are
actually Active Elements where the edge of the Active Element is not
transparent,
and hence appear as an outline which outlines or acts as a border to the shape
of
the Active Elements and so gives the impression of being a box, or an arrow,
etc.
Images that are more complex are treated as data contained in Image Data
Relation Table records, and can be displayed by a transparent Active Element.
Text, from a Data Relation Table record, can be displayed in relation to such
an
image by superimposing a transparent Active Element displaying the text on the
Active Element that is displaying the required image.
12) Any Active Element can activate any Software Module when clicked,
and is normally connected to an appropriate Software Module; for example, an
Active Element displaying a phone number, when clicked, can call a Software
Module named 'Dial' and hence dial the number. The user can change the
Software Module connected to any Active Element, selecting the one he.wants
from a list of all installed Software Module
429
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
13) Generally, any Label, Prompt message or Help Message displayed by
an Active Element can be over-written by the user so that he can adapt such to
his
preferences, and this results in the appropriate Data Relation Table records
being
saved in relation to his name. Normally, such over-writes are highlighted and
the
user asked to confirm them, immediately before exiting a particular display.
14) Any and every Active Element can, when clicked, call a Software
Module that performs an Execution
15) When an Active Element is uses as a menu button - i.e. its main
purpose is to call a Software Module - the label it displays is the name of
the
Software Module in the Software Module's Execution Record's Software Module
Name field.
The control of Input Output in the above manner is enabled using Software
Modules of
a particular type, termed 'Interface' Software Modules. Interface Software
Module are a
collection of Software Modules that between them act to control and to input
or output of
collections of Active Elements that are assembled into Sub-Views. Sub-Views
are further
assembled into 'Views'. One or more Views is further assembled into a User
Master View.
All of these assemblies of Active Elements are particular input/output
assemblies of a given
selection of data that is related to a specific input/output channel or
channels, and is also
related to a specific user or users.
A given output - such as a screen or a printed letter or report - consists of
one or
more Views assembled together and this is termed a View Collection.
Hence, if given data is made to appear on the screen in three ways, and also
to
appear on two printers, each in two different ways and also to be played to
the user through
Text to Speech, each of these is one View Collection of that data. Hence, Any
given data can
have Any - and hence many - View Collections. Any View Collection can be
related to Any
data to be displayed, and to Any user, and to Any output channel, and to Any
combination of
these.
(Note that in the above - for simplicity of description - inputloutput is
mainly refereed
to as being to or from Data Relation Table records, as this is mostly the
situation of greatest
interest to a user, who will not frequently require to see Data Class table
Contents etc. In
fact, input output can be to or from any field of any table in the Any-to-Any
machine).
~ Method to Construct Any-to-Any Interface Support
6. Methods to Construct Interface Software Modules
This detail description of Interface Software Modules will be confined
principally to
input and output to screens and printers. The same principles apply to all
other inputs and
outputs and the construction methods for Interface Software Modules that are
not described
430
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
herein can be extrapolated by a competent programmer without undue
experimentation from
the teachings of the Any-to-Any machine and the description of the methods of
the Any-to-
Any machine.
Input and output is managed and controlled by different types of Interface
Software
Modules. Like all other Software Modules, Interface Software Modules are built
from software
Data Components and Data Components that are assembled in Data Assembly Tables
and
then further assembled into different types of Data Relation Table records. An
assembly of
Data Relation Table records that performs a specific function useful to the
user - in this case
an Interface function - is termed a Software Module.
In the case of screen input and output, in method of the Any-to-Any machine,
the
entirety of the screen is used by the Any-to-Any machine for input and output
and the
operating system does not output to the screen directly, only, if necessary,
through the Any-
to-Any machine's associated interface. Equally, if operating system control is
required, this is
achieved by the user giving the order to the application built with the Any-to-
Any machine -
which records the order - and then uses suitable Software Modules to order the
operating
system. Ideally, the operating system itself is built with the Any-to-Any
machine methods, and
is a seamless part all Any-to-Any machine-type applications that are in use.
Accordingly, a
screen may consist of Menus, as well as input areas and output areas, all of
which are
displaying assemblies of Data Relation Table fields presented to the user by
Active Elements.
The term 'View Collection' applies to any one grouping of input and/or
output.for a
given input output channel, for a given user, that may require to be
manipulated as a group.
A screen, or a printed or projected output may consist of several Assemblies
of Interface
Elements - Sub-Views that are working together. For example, a user might see
on a screen
one grouping one Sub-View - that consists of a part of the screen to select
data, and another,
associated part of the screen - another Sub-View - showing the results of the
selection.
These two Sub-Views might be associated together with a View and if so, can be
manipulated
separately, or manipulated together by manipulating the View. Hence, a 'View'
and is
approximately equivalent to a 'a Window' in state of the art parlance. Another
part of the
screen - or printed or projected output - could be a further Sub-View showing
a photograph
and a photograph title, potentially with another Sub-View - its own small
collection of menu
icons (Active Elements performing menu functions) and these two Sub-Views
could be
collected in another View. The two Views present on the screen as described
above, form a
View Collection. Different to the state of the art, where a screen can show
multiple 'Windows'
at the same time, but normally, only print one 'Window' at a time (unless
doing a screen print)
the Any-to-Any machine method allows the contents of any number of 'Windows'
(Views) to
431
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
be printed or projected or otherwise output at the same time, to the same, or
different
destinations.
Hence, all input and output for screens, projectors and printers, or
concerning Voice
Recognition input output, electronic input or output (such as e-mail, File
Transfer Protocol file
transfers) and incoming or outgoing telephone calls handled by the Any-to-Any
machine, all
consist of one of more Views or View Collections. Hence, Views, contain Sub-
Views and
each Active Element in a Sub-View, inputs user data to, ar receives user data
from a specific
field in a specific record in a specific table in the Any-to-Any machine. At
the same time, it
read and uses other fields in other records, which control what it looks like
and how it
behaves. Hence a Sub-View is outputting from, or inputting to, one or more
Data Relation
Table or other records. In the case of more complex data assemblies such as
'an address'
several Sub-Views, combined into a View that is named 'an address' is
inputting to our
outputting from, (or both) an assembly of Data Relation Table records. As is
normal in the
Any-to-Any machine, fixed relationships do not exist, so a Sub-View that is
used in one
situation - as part of 'an address' for example - can also be used elsewhere -
i.e. related to
another View, for example, as part of 'a spreadsheet' where it displays
exactly the same data
in exactly the same format as it did when part of 'an address.' Any number of
Sub-Views can
be used with can be used with Any number of (other) Sub-Views.
An example of a View could be what is in the state of the art termed 'a
letter'; with the
methods of the Any-to-Any machine, 'a letter' is a number of assemblies of
Active Elements
that is displaying or outputting the assembly of Data Relation Table fields
that together
comprise 'a letter'. One Sub-View displays the sender's address, another sub-
View displays
the addressee's address, and a third Sub-View displays the remainder.
Equally, an assembly of Active Elements - serviced and controlled by various
Data
Relation Table fields - that is outputting sounds - music, for example - from
Content, type
Sound Content, is also a Sub-View. A further Active Element in the Sub-View
could display
the title of the music from the Data Category Matter, Data Class, Content
Title and still
another Active Element perhaps display a photograph of the artist. Finally,
another Active
Element could display the Data Class Content - a history of the artist's life.
Another Sub-
View could be printing the title and the photograph of the artist at the same
time, while a third
Sub-View transmits the music over the network to another location such a
network-enabled
amplifier driving speakers elsewhere in the house. Together, all of these Sub-
Views could be
collected into a View and therefore, manipulated as a whole as well as
individually, and when
something is handled individually, it does not affect the remainder.
This example demonstrates the flexibility of an Any-to-Any interface and the
Spatial
Data Relation method for creating input and output. It is not necessary to
inject data in one
432
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
format from one software package into another data format controlled by
another software
package - it is only necessary to display them with the correct spatial
relationships at output
time. Hence the principle of Spatial Data Relation, that was described in
terms of placing one
word next to another, is equally valid at all levels of input and output, from
pairs of words, to
the assemblies that make up complete screens and other outputs or inputs..
As a consequence and unique advantage of this Any-to-Any machine method, at
input/output time, Any data can be related to Any other data, on the screen,
and in all out
input/output channels, and the failure-prone complexities of injecting one
thing into another is
no longer required. Because the Visual Interface can relate Any data to any
other data it can
A) Track with the human who relates data on an Any-to-Any basis and b) track
with the data
engine of the Any-to-Any machine that also manipulates data on Any-to-Any
basis. In this
manner, the Any-to-Any machine further maintains the Parallelism Principle, in
this case,
between the human, the interface, and data manipulation engine.
A View is made up of Any number and Any combination of Sub-Views, but if the
quantity of Sub-Views is zero, then it has nothing to output and no View will
be in use.
A Number of different types of Interface Software Modules together enable a
computer to control an Any-to-Any interface, and these types are as follows:
CONTROLLER INTERFACE MODULES
A 'Controller' Interface Module is and this Module:
1. Identifies and logs-on and logs-off users
2. Determines which of its users is inputting or outputting at a given time
3. Allocates resources amongst its logged-on users
4. Directs input and output appropriately. For example, one user may be
using a computer in the normal manner, while another is perhaps dictating a
message
to the same computer and a third user is answering a phone call that is being
directed
through the computer. Or, in another possible situation, several users are
giving
orders to the computer more or less simultaneously, or in interspersed manner
using
Voice recognition software. In such cases, the Controller Interface Module
determines
which input is from which user and directs it appropriately.
Like other Interface Modules, a Controller Interface Module - which is itself
a Software
Module - uses and controls a collection of Software Modules to perform its
tasks. Colloquially
speaking, the organization of the Any-to-Any machine in terms of Software
Modules is similar
to an army, in which each task is performed by a specialist (a Software
Module) and only by
that specialist, with the advantage that, in a computer, the specialist
(Software Module) itself
is not used, only copied, and the number of copies of any one specialist
(Software Module)
433
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
that can be used simultaneously is only limited by the size of the housing -
i.e. the computer
and its memory.
A Controller Interface Module is responsible for all input and output to and
from a
given computer during the time that computer is switched on.
The Controller Interface Module identifies users and directs the input or
output
concerning that user to the appropriate User Master View Module, including
activating a User
Master View if the appropriate User Master View Module is not already active.
Hence, a User
Master View Interface Module is the immediate junior of, and controlled by, a
Controller
Interface Module.
Identification of a User by a Controller Interface Module is performed by the
Controller
Interface Module Logic using User identification methods that are described
later, together
with their operation, as part of the description for the User Number field of
a Data Relation
Table record.
As soon as a specific user is detected, the Controller Interface Module
activates the
User Master View for that user. If simultaneous multiple users are nvt
permitted for
commercial yr other.reasons, then the Controller Interface Module is disabled
to the extent of
only allowing one user to input or output at a time, and this is done by
specifying the number
of users that can use it in its User Number Administration Field. The
Controller Logic in the
Controller field of the Controller Interface Module checks the value in this
field and acts
accordingly. The Controller Interface Module mechanisms allow the computer to
change from
one user to another, without closing or removing the first user's work. When a
second user
has finished working, the Any-to-Any machine methods allow the first user to
return to his
work, and find it is in state in which he left it.
USER MASTER VIEW INTERFACE MODULES
A User Master View is responsible for all input and output on behalf of a
specific user
for a specific Input/output channel. Hence, for each user, there can be one
User Master View
Module controlling the screen, one controlling printing, another one
controlling sound, etc.
User Master View Modules are Interface Modules with the following
characteristics:
Several User Master Views may be active at one time, both on behalf of
one user (or, if permitted) on behalf of different users, but normally, only
one has
control of the screen and receives keyboard and mouse input at any one time.
If more
than one screen is installed then the option exists either to control all
screens with one
User Master View, or to control each screen with a different User Master View,
thereby
enabling different parameter settings to be used on different screens, as
described
later under 'Device Setting Data Assembly Table / Records. If more than one
User
Master View is in use for one device such as a screen, this permits a user to
have an
434
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
unlimited number of alternate 'screens' available, each displaying their own
data at
their own settings.
2. Each User Master View can contain any number of Views and all the
Views in one particular User Master View are termed a View Collection. When an
interface activity uses two interface channels simultaneously - for example,
simultaneous output of sound and text, while one may pass data to the other,
each
has its own Views and operates under the control of the appropriate User
Master
View. Several Views may be active at the same time, some of them (for example)
may be concerned with screen display, while others are concerned with
printing, and
another takes care of message - perhaps through a telephone line and Text to
Speech, without any display at all.
3. In many cases, particularly concerning the screen, the user may want
to keep certain data visible at all times - for example - a master menu bar
and/or
specific data - while changing the remainder of what he sees, For this reason,
a
Master View may itself contain Sub-Views that remain in use even when the
Views it
control change.
VIEW INTERFACE MODULES
Similarly to a User Master View Interface Module, the user may require to keep
a
menu bar available in a particular View. However, in this instance, a menu bar
is just another
Sub-View, and hence, one of the Sub-Views that the particular View Interface
Module is
controlling. It should be noted however, that the Any-to-Any machine enables
any and every
View, and any and every Sub-View to have its own menu bar if required, and any
number of
menu bars can be assembled and used anywhere at any time
VISIBILITY OF INTERFACE MODULES TO THE NORMAL USER
Controller Interface Modules
Controller Interface Modules, User Master Views and Views are all Interface
Software
Module that are used to manage input and output. The actual Input and Output
is done by
Active Elements in Sub-Views.
Controller Interface Modules have no physical appearance to the user, other
than
when a user logs-on to the machine, when the Controller Interface Module uses
a Sub-View
to interface with the user.
User Master View Interface Modules
These Interface Modules have a limited visibility for the user. User Master
View
Interface Modules may display a menu bar - that persists even though Views are
changed
and that can be used to set aside a particular User's work to enable another
user to use the
machine: 'Setting Aside' the work simply means collapsing the display for that
user using the
435
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
methods of the Any-to-Any machine, and, if necessary to create enough space in
memory,
storing all records in use with a reference for the group that enables them
all to be re-
activated as a group. User Master View Interface Modules - like any Interface
Module - can
present borders, background colors and images such as screen savers or
wallpaper.
Additionally, a User Master View can have a User Communication Sub-View to
provide a
communication channel with the user, both to give him messages and to receive
instructions
from him and it can be convenient to centralize all user messages through such
a Sub-View.
This utilization of a User Master View will be described when describing the
'Personality' Data
Relation Table field. When a User Communication Sub-View exists, a User Master
View acts
as a Communication channel between the user and anything else in the computer
or on the
screen. A User Communication Sub-View can be used as a channel to an
underlying
Language Processor and can present any data relation table record (translated)
content to
the user - for example, from the Label, Prompt or Help field of the Associated
Records of a
particular Active Element. Each View can also have its own User Communication
Sub View if
desired. This means that a Personality, who looks and acts and talks like an
accountant,
receives orders concerning the financial matters in one View, and gives
messages concerning
them, while another Personality, who looks and talks and acts like an Office
Manager appears
in the user Master View, while a third, with the Personality of an artist, is
visible in another
View, where the user is making a drawing. Because the Any-to-Any machine
methods enable
every Active Element to have its own Help, the Help is appropriate to the
data, and hence, the
Personality can appear to talk act in character. Many inexperienced users are
frightened of
computers, and using a human-like Personality can provide re-assurance,
provided that the
Personality acts in a human-like manner, which this Any-to-Any machine's
methods make
possible.
View Interface Modules
View Interface Modules also have a limited visibility for the user. They may
display
and present borders, background colors, 'screen' savers, menu Sub-Views and
User
Communication Sub-Views. However, they do not themselves present data to the
user, but
use Sub-Views to do so.
Sub-View Interface Modules
Sub-View Software Modules, on the other hand, always do present data to the
user or
receive data from him, and so are the type of Interface Software Module of
which a normal
user is most aware. Sub-View Software Modules directly control the data the
user sees - or
talks to if he is using any kind of voice interface - and directly control
what the user can input
and where and how.
436
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- Types of Sub-Views
SINGLE SUB-VIEW AND MULTI-SUB-VIEW
Occasionally, a user only wishes to see one of something and at other times,
he may
wish to see several of something - several e-mails, several addresses, etc.
When the user does select more than one of something, he may wish to output:
1. All of each item in sequence (or a large part of it) and nothing else.
This is termed a 'Single Sub-View'
2. The same thing about each of the several items selected - a tabular list
of some aspects of each item and nothing else. This is termed a 'Multi Sub-
View
For this reason, when a programmer constructs basic Sub-Views for a user, he
constructs a matching Multi Sub-View for each Single Sub-View and a matching
Singfe Sub-
View for each Multi Sub-View, and preferably provides an Active Element that
the user can
use to change easily between the two.
RELATIONSHIP OF SUB-VIEW TO ONE ANOTHER
A user may frequently need to look at several Sub-Views at once. For example,
a
user may wish to see together on his screen at the same time:
1. A Sub-View showing his 'Find' Specification, as well as Boolean
operators and perhaps sort orders also. He might, for example, specify
'fetters from
Joe about bananas'
2. A second Sub-View - a Multi-Sub-View - showing in tabular format
various Data Relation Table field values for the items found by his 'Find'
Specification.
In this Sub-View the user might want to see the date the letters were sent and
who
by, and where they sent them, each in different columns.
3. A third Sub-View that is a Single Sub-View showing one or more Data
Relation Table fields from the chosen selection, for each of the items in turn
that he
highlights in the Multi-View. This is termed a 'Partial Single View'. For
example, as
the user highlights each of the letters found by the 'Find' Specification,
that are
displayed as a list by the Multi-Sub-View, he might wish to see as much of as
possible
of the contents of each highlighted letter, one at a time.
White the user may want to see all three of these together, he might also wish
to
handle them together - for example, give a single order that sets them all
aside, or reduce
their screen space by 50% so that he can see another View altogether showing
Joe's
payments to the company.
Hence, a number of Sub-Views may need to be related to one another in this
manner,
and handled together as a group. The mechanism of the Any-to-Any machine to do
this is to
group them together in a 'View'. Hence, a View Software Module is a Software
Module that
437
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
can control Any number of Sub-Views, and handle them as block under the user's
control.
Equally, when a programmer creates Sub-Views of particular data for a user, he
should also
create the three Sub-Views listed above. In addition to making them available
separately,
they should also be made available together in a View Interface Module.
DISPLAY OF FIELDS FROM ASSOCIATED RECORDS TO DATA RECORDS
A single user data item record in the Any-to-Any machine has a minimum size of
a
single Data Relation Table record. Any communication automatically has at
least two
records, one for the sender and one for the receiver, as practically every
Data Class value is
different for both of them, except the actually Content transmitted between
them. Some items
- such as 'an address' are a considerable number of Data Relation Table
records assembled
together.
The Physical Universe Data Categories all display a particular phenomenon,
namely
that a value in one Data Category cannot be applied to another - the Integrity
Principle of
Data Classes. One cannot say for example 'It is now Monday Wednesday today'.
It is of
course possible to say 'it is a Monday-Wednesday-like day' - but in this case,
Monday
Wednesday is no longer a day at all, it has been transformed into a Quality.
However, Data Classes in the Life Data Category do not display this
phenomenon,
and almost the values from almost any Data Class in the Life Data Category can
be applied
both to any of the Physical Universe Data Categories and Data Classes as well
as to one
another, and clearly disobey laws that the Physical Universe Categories obey.
Hence, a
Quality - 'good' for example, can be applied to anything at all and Modify the
concept that is
communicated.
Hence, Life Data Category Data Classes each have their own record type, and
any
number of these can be used as an Associated Record showing Field Parallelism
with a Data
Record. This means that potentially a single item may be composed of items in
many data
records and many such Modifier records, bringing the potential number fields
that can be
required to display an item into the low hundreds.
Hence, if a Views or Sub-Views may be required to display Life Category
records that
are Associated records to data records, in order to reduce screen clutter, it
can be useful that
field of an Associated record should display when tit has a value and does not
display when it
does not have a value and this ability should be constructed as part of the
logic of an Active
Element.
PROGRAMMER PROVIDED VIEWS AND SUB-VIEWS.
As described above, any kind of input or output from a computer requires
control of
the spatial relationships of the data - either
438
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Spatial control of the input area so that user, by choosing to enter data
in appropriate screen areas, in effect enters the correct relationships of
data into the
Data Relation Table, or
2. Spatial control of the output. This spatial control is needed in any
Output, whether it be to the screen, printed projected or spoken.
While a skilled user could begin creating screens in an application using only
data
entry Active Elements to begin specifying what he wants, the programmer
assembles a
number of suitable screens and output formats (i.e. output spatial
relationships) simply to
give the user a place from which to start adapting the output to suit his
particular needs. A
unique difference between the methods of the Any-to-Any machine and that state
of the art
software in this respect, is that in the state of the art, the screens
provided with an application
by the programmer are more or less a finishing point, and are capable of only
minor
adaptation by the user. However, with the methods of the Any-to-Any machine,
the screens
provided by the programmer are only a starting point, and the user can,
without programmer
intervention, modify any screen himself, so that, if he wished, he could
modify ten completely
different screens and make every one of them identical to the other or
equally, make every
one of them unrecognizably different from the original.
Because it is not desirable to require even a skilled user to create the basic
-starting -
screens he will need, a programmer who creates an application, should provide
the user with
the following, to give the user a starting point:
1. At least one Find Sub-View enabling the user to specify what he wants
found with an arrangements that is suitable to the types of data created by or
pre-
loaded in the program. A 'Find Sub-View' uses the normal 'Find' Software
Module, but
provides it with a Data Relation Table data record that contains pre-written
field values
that act to limit the selection to data produced by his program. If there were
a number
of useful basic ways of finding data produced by the program, the programmer
would
help the user by producing more than one Find Sub-View and some sample Find
Specifications. (A Find Specification is a Data Relation Table record Sub-Type
of the
Data Specification field that contains the Specification for an item or items
to be found,
containing the values that are to be matched by the Find Module). He can also
provide Active Elements that are Icons enabling the user activate, easily and
directly,
the different Find Sub-Views that he provides.
2. At feast one Single View. A Single View contains adequate Sub-Views
to show all of (or as much as possible) of a single complete item - for
example, of 'a
letter'. If there were a number of useful basic ways of looking at the whole
of a single
data entry in his program, then programmer would help the user by producing
more
439
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
than one Single View. He can also provide Active Elements that are Icons
enabling
the user activate, easily and directly, the different Single Views that he
provides.
3. At least one Multi Sub-View and matching Single Sub-View, showing a
list of items in full. If there were a number of useful basic ways of looking
at a number
of single data entries in his program at the same time, then programmer would
help
the user by producing more than one Multi Sub-View. He can also provide Active
Elements that are Icons enabling the user to activate, easily and directly,
the different
Multi Sub-Views that he provides. Each Find Sub-View is provided with at least
one
corresponding Single Sub-View and a Multi-Sub-View, and these are also made
available together as a View as well as separately. The programmer should
provide
Icon buttons in such a manner as to enable the user to change from one to
another
directly, so that he can change from a Single View to a Multi View, or from
one Multi-
View to another for the same data selection.
Additionally, the programmer should consider the data that is likely to exist
on his
customer's computers, which would be useful if related to data provided by his
program. If he
finds reiationships that are likely to exist, then he should provide his users
with suitable Views
and/or Sub-Views to relate these, and thereby enable his users to extract more
value from
their existing data.
As stated previously, programmer-provided Views and Sub-Views are only
starting
points for a user. A programmer who provides his customers with a good
selection of Views
and Sub-Views will thereby inform his users and show them the some of the
types of ways he
can look at his data. In this manner, programmer-provided Views and Sub-Views
are
primarily an instruction tool for the user, and provide the user with a
starting point that he can
adapt to suit his own data, and his own purposes.
MErvus
In the method of the Any-to-Any machine, a 'Menu' is Sub-View that is an
assembly of
Data Relation Table fields, where each Icon or Button is an Active Element
that is displaying
as its Label the name of a Software Module contained in the Data Relation
Table Software
Module Name field of a Software Module Execution record. Normally one Software
Module
name displayed by an Active Element is termed 'Action' or similar. one effect
of the 'Action'
Icon can be to take over the entire screen - i.e. change the View in use in
order to display
the name of every (user) Software Module, each in its own Active Element.
Active Elements
can contain logic that specializes them for different purposes and some Active
Elements are
generally specialized to display Images. A particular sub-type of Active
Element specialized
to display images are termed Image Active Elements, and a sub-sub-type of this
sub-type is a
440
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Personality Image Active Element that displays a Personality image.
Personality Image
Active Elements can be used in, or outside a Menu.
SPREADSHEETS, DATA BASE OUTPUT, ETC.
An area of the screen or output that is displaying what the state of the art
terms as 'a
spreadsheet', 'a database', 'a drawing' 'a Presentation', 'a photograph' are
all Sub-Views and,
as stated previously, any Sub-View can be output in combination with Any
number of Any
other Sub-Views.
OTHER TYPES OF SUB-VIEWS
Programmers can create whatever Views and Sub-Views suit their purposes. Some
examples are Organizational charts, statistics, charts and graphs etc.
RESULTING SIMPLICITY OF A VISUAL INTERFACE
It might be though that the result of a programmer following the above would
result in
a very large of number of screens being needed. However, it should be
remembered that
when software is written with the methods of the Any-to-Any machine, the state
of the art
concept of a 'software package' no longer exists in the same form. For
example, a typical
office application might contain bulky software packages as follows: word
processor,
spreadsheet, database, presentation application, e-mail application, drawing
application etc.
Each of these contains its own tools - Software Modules in the terminology of
this Any-to-Any
machine, and many of these are duplicated in the different packages. A 'make
text bold'
function - equivalent of a Software Module - will probably exist in
practically every package.
When such an application is re-written with the methods of the Any-to-Any
machine:
There are no duplicate Software Modules. There is only one 'make it
bold' in the entire application for example
2. There is no division between packages. There is the screen, and there
are Software Modules that can act on it, and any Software Module can act
anywhere.
3. Hence, one part of the screen can appear to be 'a word processor',
while another part appears to be and looks like it is 'a spreadsheet' while
another part
appears to be 'a database', another part is 'a presentation'.
4. All Software Modules are available all the time, to act on any data and
hence any or all of the data can be assembled into a view and e-mailed, or
turned
green in color etc.
Because of this transparent wholeness of an application written in this manner
- such
as an 'office' application - it is found in practice that the number of
different 'screens' (View
Collections) that are required. is not increased, but greatly reduced, making
the use of 'office'
application simpler for the user. The entirety of an 'office' application in
this form can be
manipulated with only three basic Views Collections ('screens') which is fewer
than the
441
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
number of screens in a similar state of the art package. A Single Sub-View
with minor self-
evident variations can show any 'office' document, a Multi-Sub-View shows a
lost of 'office
documents of all or any types, and a Multi-Sub-View collects together and
shows the user
everything he has done, and plans to do. In such an application:
1. Any work that is in progress on the screen can be sent elsewhere by
any available method - specialist fax or e-mail programs are not required.
2. A single screen is adequate for the creation of any 'office' document
type, and such a screen can be used to create several different 'office'
document
'types' at the same time - for example, a document can be created from a
single
'screen', and then sent to several different recipients by different methods -
one can
receive it by e-mail, another as a mailed letter, and a third as a fax, etc.
In effect, the
user has created the different document 'types 'an e-mail', 'a letter' and 'a
fax'.
92) Methods To Construct The Different Types Of Interface Software Modules
7. Functions of Different Types of Interface Software Modules
As previously explained, Controller Interface Module Software Modules control
all
input and output for a specific computer, and User Master View Software
Modules control all
input and output for a specific computer:
1. For a specific type of input output channel
2. For one specific user.
3. For the View Collection - i.e, all the Views - under the control of that
User Master Interface Module
Similarly, View Software Modules control all input and output:
1. For a specific type of input output channel
2. For one specific user,
3. For a specific collection of Sub-View Software Modules that a user may
need to handle or control as a group. While a View may control only one Sub-
View
Module, it is often likely to control several Sub-View Modules at the same
time.
In addition to their specialized functions already described, Controller
Interface Module
Software Modules and User Master View Software Modules have the following
additional
functions:
1. Controller Interface Modules enable the entirety of a user's input and
output to be controlled as a block,
2. User Master View Modules enable the entirety of one type of a,user's
input output of one type to be controlled as a block,
3. View Modules enable groups of Sub-Views to be controlled as a block.
442
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
4. Controller Interface Modules, User Master View Modules, and View
Modules all participate the allocation of resources to their dependant
assembles.
Thus, a Controller Interface Module Software Module allocates computer
resources to
User Master View Modules. If there is only one User Master View Module of a
particular type
that is active, it allocates 100% of that resource to that User Master View
Module. Hence,
also, if a computer will only ever have one user, the Controller Interface
Module only should
identify that user at start-up and then immediately allocates all resources of
each type to that
user's User Master View Modules.
As per the normal method of the Any-to-Any machine, all the data and functions
comprising an Interface Software Module are stated in terms of Data Relation
Table records
that are assemblies of Data Components. Each of the different types of
Interface Software
Module uses their own sub-type of several different Data Relation Table record
types as
follows:
- Active Interface Module, Data Relation Table Record Type
An Active Interface Module record is a Sequence type Data Relation Table
record that
is used by an Interface Software Module to find the junior Interface Software
Modules it is
directly controlling. An Active Interface Module record contains in each of
its data fields the
Data Relation Table record number of the Execution Record of each interface
Module that it
is being controlled by the Interface Module that is using that record. The
Active Interface
Module record is the record that states the Component Assemblies in a
particular interface
construction, and thereby acts as the guiding record type for a number of
other records -
termed 'Associated Records' - that are used together with it. The term
'Associated Records'
denotes a particular way of using records, in which any given field number in
all records that
are Associated Records all apply to the same thing. Taking the example of an
Active
Interface Module record, if field number 30 states the Execution record number
of a particular
Interface Module, then all other field number 30s in all Associated Records
also apply to that
same Interface Module, while all field 31's of the Associated Records apply to
the next
Interface Module. When each particular field number in a series of records ail
apply to the
same thing, the fields are said to show 'Field Parallelism'. Thus, for
example, a Software
Module Execution record that is acting on a data in another record, is -
temporally - an
Associated Record with the data record, and their fields show Filed
Parallelism - the Field
Logic in field 30 of the Software Module acts on the data in field 30 of the
data record. Field
Parallelism is an desirable general method of the Any-to-Any machine. A field
showing Field
Parallelism is said to be aw 'Parallel Field'.
While a particular Interface Module may use one Active Interface Module record
- or
more that one if necessary - such records will not necessarily be full. If a
View Interface
443
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Module has only one Sub-View it is controlling, then the data fields of the
Active Interface
Module Record will contain only one entry - the Execution Record number for
that single Sub-
View Execution record. But even when a particular Interface Module is
controlling only one
junior Interface Module, all the needed records to control more than one
junior Interface
Module are always present. This is because it is not possible to predict what
other junior
Interface Modules a user may add, and therefore, in order maintain the
Unlimited Principle
and ensure the application is Unlimited, the methods used need to be such that
the user can
add more of something. For example; even if there is only one Sub-View
required in a
particular View for an application, a View Module still exists for it and is
still provided with a
complete Active Interface Module Record, View Sub-Type. It is not possible to
predict what
other Sub-Views a user may choose to add to a View consisting - at the moment -
of only
one Sub-View, and therefore, provision is made to enable a user to add more of
something, in
this case to add further Sub-Views.
A user may decide, for example, that every time he is looking at photographs,
he
wants to play music, and also decide that he does not normally want to play
music when he
looks at anything else. In effect, he may decide that he wants photographs and
music
together, but wants to be able to put both of them aside as a group when he
wants to do
something else like reviewing performance ratings with a junior. In this case,
a View that
began with one Sub-View to display photographs in a certain manner, will
acquire another
Sub-View that plays music.
Hence for example, the Active Interface Module, Data Relation Table record
type, sub-
type View, is a record that states the Sub-Views that make up a View. An
Active Interface
Module, Sub-Type Master View is a record that states a) Any Sub-Views directly
controlled by
the Master View and b) the number of the Execution Records of each View it is
controlling.
Similarly, an Active Interface Module, sub-type Controller, states the number
of the Execution
Records of the User Master Views it is controlling. ,
The Active Interface Module Record, in addition to containing the information
on which
junior Iriterface Modules are under the control of the senior Interface
Module, also serves a
second purpose.
An Active Interface Module acts as a lead record or guiding record for the
junior
Interface Modules being controlled by the Interface Element to which it
belongs. Every junior
Interface Elements needs controlling information that states what it should
look like, where it
should be placed and how it should behave. Each different type of controlling
information is
stated in its own record type - and sometimes in combined record types. The
Active
Interface Module Acts as a guiding record, because, if a particular field in
it - number X -
contains the Execution record number of Interface Module Y, then each
different type of
444
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
controlling information is stated in its own record type, and field number X
in those records
types contain further information also pertaining to Module Y. Records that
are aligned in this
manner - Field number X in different records all apply to a Y stated in a
leading record, are
termed 'Associated Records' In this case, because the Associated Records are
associated
with a Active Interface Module Records, they are termed 'Active Interface
Module Associated
records.' Thus, Active Interface Module Associated records, contain, in each
of their data
fields, information pertaining to whichever Interface Element is stated in
that same field of the
Active Interface Module record.
- Methods to Minimize User Intervention Required for Control of Screen Display
As previously discussed, it is desirable to avoid User Intervention wherever
possible.
Whenever user intervention is required by a computer, the computer should stop
and cannot
proceed with a verbal order - given through a Language processor for example -
until the
user has intervened. In effect, Automatic Software Execution is prevented.
Requiring user
intervention can result in the computer stopping Execution - to wait for user
intervention -
when the user does not expect it and hence, producing the feeling of
unreliability. One area
in which this can be a considerable problem in the state of the art is the
area of screen
display, where a great deal of user intervention is today required in order to
display data the
way the user wants to see it.
There are two requirements that should be met in order to avoid user
intervention to
control screen display, and these are:
The user himself should be able to control the way the screen displays,
by giving orders - such as 'equalize those two windows' 'show me A and B and C
and
D'. The method should enable him to control directly - in a non hierarchical
manner -
any and every aspect of the display that could, theoretically, be controlled,
as
otherwise he may specify something that can not be controlled, or cannot be
controlled directly in a non-hierarchical manner, and thereby, unexpectedly
require
user intervention. It is desirable that the user is able to access these
controls - i.e.
give orders about the screen display - ih a direct, non-hierarchical manner.
As soon
as any hierarchy whatsoever is introduced into any control procedure (or
elsewhere)
the user should remember what that hierarchy is, as otherwise the control - or
data -
is inaccessible. Hence, hierarchies of any kind are instantly and immediately
create
difficulty of use and it is noticeable that humans do not use hierarchies when
giving
orders to one another. A Company hierarchy, for example, serves only to
establish a
Condition for the order - that the listener is required to accept the order
and serves a
purpose similar to computer logon. But once a boss is 'logged on' to a
secretary, no
hierarchy is used in giving the order. The boss does not say 'Secretary, (the
software
445
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
package equivalent) Listen (=open), Communications (=address book), Joe,
Telephone Number, Telephone.' The boss says 'Call Joe' - there is no hierarchy
whatsoever in the order. Hence, any and every aspect of the screen that can,
or
should be able to be controlled, should be able to be controlled, and should
be able to
be controlled in a direct, non-hierarchical manner.
2. If a Language Processor is installed, the user may not begin with a
screen at all, but rY~ay give an order to display something that is nothing to
do with
what is on the screen now - for example an order to 'show me A and B and C.'
In this
case, the nature of the data requested by the user should be able to control
the
display. If the data cannot control the display, then the data engine can
produce the
user's requirements for the interface, but, the interface will not know what
to put up in
order to display it. If A is a 'a spreadsheet', B is 'a letter' and C is 'a
photograph', the
screen display requirements and areas for each of these will be totally
different than if
A is 'a name' B is 'a presentation; and C is 'an e-mail'. Hence, the data
itself should
be able to control the screen - i.e. input output appearance.
The following is an overview of the Any-to-Any machine methods that enable a
Visual
Interface to meet the above requirements. These methods are described in
relation to
screens but apply equally to any other visual input or output. A screen is
used in the
description, as it is more complex than other input or output - for example, a
printer. A
screen should do both input and output at the same time, and also act as a
working area
flexible enough to accommodate the user's working needs and hence, the control
of the
screen is therefore more complex than controlling the output for an output-
only device such
as a printer - for example. Input/ Output methods that enable a Visual
interface to meet the
above-listed requirements are:
1. Methods for a senior Interface Module to assign a space to junior
Interface Module - 'Grid Records'.
2. Methods to connect one Interface Module to another so as to make the
correct Spatial correct Spatial Data Relation Statement - 'Connect To'
records.
3. Methods to construct Interface Controls that control the behavior of
Interface Elements and can be used to reduce their space requirements
4. Methods to set the Minimum Standard Size. This is a method that
enables the smallest size for an Interface Element to be calculated so that
the user
can still read it, with or without using size-reducing Interface Controls.
5. Methods to find what the user is looking at. User Attention Records.
6. Methods to calculate and request the space required by what the user
wants to see, and the space requirements of what he does not have his
attention on
446
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
now, with and without space-reducing Interface Controls operating. Request
Space
records.
7. Methods to calculate and assign spaces and positions to Interface
Elements 1 ) based on where the user attention is and was, and b) also based
on the
Minimum Size
Essentially, the general principle is that junior Interface Elements
communicate to
senior Interface Elements the space they want, based on the data they have to
display.
Senior Interface Elements communicate to juniors the space they can have, and
where that
assigned space is, based on where the users has his attention, and taking into
account the
space that the junior Interface Element's requested. All Interface Elements
use the same
record types and types of field values, so that a senior Interface Element
nearly always has
the same structural pattern of records that it uses, as a junior Interface
Element, with each
using their own version of a particular record type or value type.
The further general principle is that a junior Interface Module, when it
requests an
area, just requests a size - an area - but does not take account of exactly
where that area will
be placed. The senior Interface Module does its calculations for its juniors
and then assigns
them a specific area and location. Colloquially, the junior Interface Module
says 'I need a
space 3 by 2 for what I've got to show' and the Senior Interface Module
replies, using Grid
Records, 'You are assigned the space from point X to point Y, make the best of
it.' (Point X to
Point Y, could, for example actually interpret as an area of 2.75 x 1.9 at the
top right of the
screen or output for example).
These methods, taken together, enable a computer to achieve the previously
stated
requirements, because both the user and the data itself are able to directly
control the display
or input/output, and in such a manner that the data is as visible as possible.
The first of these methods is a method to state areas in a given input/output,
and then
to use this method in such a way that:
Senior Interface Modules can assign specific location and location sizes
to junior Interface Modules
2. Junior Interface Modules can request areas from senior Interface
Modules
- Grid Records, and Method to Assign Available Space to Interface Module
Output areas - such as a page or a screen - are managed by a User Master View,
which contains Views, and Views contain Sub-Views. Sub-Views contain Active
Elements
that display the data. If a Controller Interface Module is set up so that
several users can use
a given screen or output at the same time, a User Master View would only have
part of the
available output area assigned to by the Controller Interface Module, and this
arrangement
447
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
might be used for example, if two players are playing a game simultaneously on
one screen
as often is done in Arcade Games.
Under more normal circumstances, a User Master View usually has allocated to
it all
of an available resources such as the space on a screen. However, it's junior
Interface
Modules can not know in advarice, how much space they will be allocated, or
where, and
therefore, their size requests - areas and spaces - are specified in terms of
'Available Space'.
Colloquially, 'Available Space' means 'whatever space is given, requested or
used'. Thus for
example, every Interface Module considers that its 'Available Space' is
divided into 1,000,000
units horizontally and 1,000,000 units vertically, and these units are termed
'Available Space
Units'.
A senior Interface Module specifies exact places in an output to a junior
Interface
Module by using two Coordinate Sets, each consisting of a Horizontal and a
Vertical
coordinate. The principle is the same as in a spreadsheet, where column A row
1 (A1 ) to
column C row 3 (C3) is expressed as A1 to C3 and specifies a specific place
and area of the
spreadsheet. The equivalent of the spreadsheet 'A1 / C3' notation for an
Interface Module
are termed 'Coordinate Sets'. Thus, a junior Interface Module receives two
Coordinate Sets
from the senior Interface Module and then looks these up in a table to see
where exactly that
means it should display in this instance.
The same Available Space Units method is also used to create Coordinate Sets,
as
follows:
1. The actual top left corner of the Available space is considered to be a
point (not a cell as in a spreadsheet) that is numbered 1, while the furthest
point to the
right of the Available Space is numbered 1,000,000. The point at the top left
corner -
that was just numbered as '1' - is also the first point on the vertical scale,
which
finishes at the bottom left hand corner of the Available Space and is numbered
1,000,000. When Available space units are used in this manner they are termed
either Horizontal Displacement Units or Vertical Displacement Units. In order
to make
a Coordinate Set, Horizontal Displacement Units are specified first and
Vertical
Displacement Units are specified next.
2. Thus the Coordinate Set of 0,000,001 0,000,001, specifies the top left
hand corner of the Available Space, while a Coordinate Set of 1,000,000
1,000,000,
specifies the bottom right hand corner of the Available Space. A pair of
Coordinate
Sets-for example 0,000,001 O,D00,001 1,000,000 1,000,000, - specifies the
space
from the top left-hand corner of the Available Space to the bottom right-hand
corner of
the Available Space - i.e., the entirety of the Available Space.
448
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
3. Hence, a Senior Interface Module specifies a location and an area to its
junior Interface Modules in terms of a pair of Coordinate Sets that are
related to
specific locations by the junior interface Module
4. Hence, a junior Interface Module makes requests for space in terms of
Coordinates Sets that specify an area, but these are not related to any
specific area -
they are just a space request, and are not a location request also.
5. The figure of 1,000,000 for Space Units in the above description is
chosen arbitrarily. The figure chosen should be large enough to be able to
specify the
finest resolution that is likely to be possible.
Data Relation Table records that are Active Interface Module Associated
records and
are termed 'Grid Records' are records that can contain one Coordinate Set in
each of their
data fields. Because two Coordinate Sets are required to state a specific
(rectangular or
square) location and area, Grid Records normally are used in pairs, with one
Grid Record -
named the Grid Starf record - stating the starting coordinates for an area,
and the other Grid
Record - the Grid End record - stating the ending Coordinate Set. In this
manner, a
particular field number in a pair of Grid records contains the starting and
ending Coordinate
Sets for the Interface Module whose Execution record number is specified in
the same field
number in the Active Interface Module Record with which they are Associated.
In the above examples, a pair of Coordinate Sets can specify a square, a
rectangle,
(or a line if interpreted in that way) in a specific location within an
Available Space. However,
space requests and assignments do not have to be square or rectangular, but
can be any
shape. When they are any other shape than a square, rectangle or line, then
additional
Coordinate Sets - and additional Grid Records - are needed to specify them.
When a large
number of Coordinate Sets are required to state a particular Interface
Element, this can be
done using a Data Relation Table Sequence record, Coordinate Set type, in
which the data
fields of the record ace used to lay out in sequence all the Coordinate Sets
for a specific
Interface Element. In this case, the Grid Starf record contains in each of its
data fields, the
record number of a Coordinate Set Record. The 'Number in the Sub-Type Field'
for the Grid
record is a reference that states that this Grid Record is a Coordinate Set
type. When a Grid
Record, Coordinate Set Type is used, it replaces the Grid Starf Record, and
the other Grid
record in the pair - the Grid End record is blank.
In a Grid Start record, each data field contains the number of one Horizontal
Displacement Unit value and one Vertical Displacement Unit value concatenated
together to
make a Combined Number. Referring to the previous example, the first data
field of the Grid
Start Record will contain the Combined Number 0,000,001-0,000,001 (punctuation
has been
added to the number to facilitate understanding, but would not normally be
present.).
449
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Interface Module logic treats the first seven digits of the Combined Number as
applying to the
Horizontal Value and the second seven digits as applying to the Vertical
Value. Again
referring to the above example, the Grid End record will contain, in its first
data field, the
Combined Number produced by the concatenated Ending Displacement Units, i.e.
1,000,000-1,000,000 (again, punctuation has been added to the number to
facilitate
understanding, but would not normally be present.). The values in a Grid
Record data field
are termed 'Coordinates Sets' and are referred to as 'Start Coordinates' in a
Grid Start
Record and 'End Coordinates' in a Grid End Record.
In Grid Records, a specific number of data field contains the Start Coordinate
for a
particular area, while the paired Grid End Record contains, in the same number
of data field,
the End Coordinates for that same area.
In the case of a computer that has only one user, the Controller Interface
Module Grid
Start and End Record - for example, for the screen - will only contain data in
one field of each
of its Grid Record pair. However, if at any time further users need to be
added, no changes
are required other than to permit the Controller Interface Module to accept
more than one
user simultaneously (or the same user operating in more than one manner) and
that only
requires changing the number of users it is permitted to service by changing a
marking in one
of its Administration Fields. This illustrates the one method, which is to
build an application
with the Any-to-Any machine is such a manner that it can handle all possible
demands, and
then, if commercially desirable, turn off some of the facilities. The reason
for this is that while
it is relatively easy to decrease the power of an engine such as the Any-to-
Any machine, it is
far more difficult to add power to an engine that was not built from the
beginning to
accommodate that power.
A Controller Interface Module assigns space - for example on a screen by -
assigning
Coordinates using a pair of Grid Records to state the Start and End
Coordinates for the User
Master Views that it is controlling.
Similarly, a User Master View Modules dictates the Assigned Space for each
View
Module it is controlling using its own pair of Grid Records. If a User Master
View Module only
has one active View Module, then the space it assigns to that View Module
using its Grid
Records, will be identical to the values in the Controller Interface Module
Grid Records.
Similarly, a View Module dictates the Assigned Space for each Sub-View Module
it is
controlling using its own pair of Grid Records. If a View Module only has one
active Sub-View
Module, then the space it assigns to that Sub-View Module using its Grid
Records, will have
the identical to the values in the User Master View Grid Records of the User
Master View that
is controlling it.
450
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Thus, a Controller Interface Module can dictate Assigned Space to a User
Master
View Module; the User Master View Module can dictate Assigned Space to its
View Modules,
and a each View Module can dictate Assigned Space to its Sub-View Modules. At
the same
time, each of these can place requests for space to the Interface Module that
is controlling it,
using the Request Space Data Relation Table record type.
Connect To Records, And Methods To Connect One Interface Module To
Another
As previously described, an Any-to-Any interface should be able to place a
single
instance of unique data with a certain spatial relationship to another single
instance of unique
data, without limit, and the spatial relationship that is used is a Spatial
Data Relation
Statement and conveys part of the relationship of those single data instances
that are
displayed.
The ability to place on Active Element - and hence the data it displays - in a
specific
spatial relationship to another is performed by a Data Relation Table 'Connect
To' record. A
Connect To record specifies the manner in which one unit - such a View or an
Active Element
that is controlled by an Interface Module is connected - i.e. physically
related to - to another
unit - such as a View or an Active Element - controlled by that same Interface
Module. User
Master View Modules, View Modules and Sub-View Modules each use their own sub-
type of
Connect To record to enable them to record these physical relationships.
Connect To
records are Associated records, associated with the Active Interface Element
Record.
Connect To information can be specified as an Absolute Position - in
which case the Coordinate Set specifies an Absolute Coordinate relative to the
top left
hand corner of the Available Space. In this case, the Active Element (or
Interface
Element) remains in a fixed position relative to the Available Space. If for
example, an
Active Element is placed, with this method, a third of the way along the top
edge of the
Available Space, no matter how large or small the actual space turns out to
be, the
Active element will be a third of the way along the top edge of whatever space
is finally
used.
2. Alternatively, Connect To information can be specified as a Relative
Position. If this method is being used, then the Relative Position for the
very first
Active Element to be placed by a programmer is specified relative to the top
left hand
corner of the Available Space. The second Active Eiement to be placed has its
Relative Position specified relative to the first Active Element - and so on.
If another
element is moved nearer to the top left hand corner of the Available Space
than an
Active Element that was previously closes, then the Connect To record is re-
written,
so that the Element nearest the top left-hand corner is related to that
corner, and the
451
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
next nearest. Interface Element is related to the one nearest the top left-
hand corner.
Relative Position Coordinate Sets for a given Interface Element can be
Horizontal
Relative Position - in which case an Interface Element is connected to the
Interface
Element to the left of it, eventually creating a line of data. Alternatively,
Vertical
Relative Position can be used, in which an Interface Element is connected to
the one
above it. Hence, a tabular format can be constructed by constructing a first
line using
Horizontal Relative Positions, and the remaining lines are constructed using
Vertical
Relative Position, so that each position of each Interface Element in the
second and
further rows, is related to the position of the element above it.
As previously described, Available Space is divided into 1,000,000
Displacement Units
Horizontally and 1,000,000 Displacement Units Vertically, starting from the
top left hand
corner. When an Absolute Position is to be recorded in a Connect To record,
the 14-digit
Coordinate Set states the number of Displacement Units - Horizontally and
Vertically - that
the top left hand corner of the Interface Element is displaced from the top
left-hand corner of
the Available Space.
When a Horizontal Relative Position is to be recorded in the Connect To
record, the
Coordinate Set states the number of Displacement Units -Horizontally and
Vertically - that the
top left-hand corner of the Interface element is displaced from the lower
right-hand corner of
the Interface Element to which it is connected by a Relative Position
Coordinate Set. A
Vertical Relative Position is recorded by recording the displacement of the
top left-hand.
corner of an Interface Element, from the lower left-hand corner of the
Interface Element
above it.
Absolute Position and Relative Position Coordinate sets are distinguished form
one
another by an additional digit that codes for Absolute or Relative Position.
When expressing
Relative Positions, Horizontal Displacement Unit values are positive if they
are at or to the
right of the right hand edge of the previous Interface Element and negative if
they are to the
left of the right hand edge of the previous Interface Element. Similarly,
Vertical Connect To
Displacement Unit values are positive if they are at or below the lower edge
of the previous
Interface Element and negative if they are above it.
In order for an Active Element to calculate where it should be using a
Relative Position
Coordinate set, the Active Element needs to know where the bottom right-hand
corner of the
Active Element it is connected to actually is. This information is stated in
an End Point
Record that is an Associated Record with the Active Interface Element Record,
in which the
Field Logic of the Active Element states and keeps updated the Coordinate Set
stating the
position of its lower right-hand corner. The first Active Element Field knows
where it is in
relation to the top left-hand corner; it also calculates,- i~n the manner to
be described, how
452
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
large it is, and from that can calculate and state, in terms of Displacement
Units of Available
Space in an End Point Record, where it's lower right-hand corner is.
Succeeding Active
Elements repeat the process.
Because a Connect To record is a record that Associated with the Active
Interface
Module Record, the Connect To information for a given Interface Eiement such
as an Active
Element, is placed in the Connect To record field number that corresponds to
that Active
Element (or Interface Element) in the Active Interface Module record.
Controller Interface Modules, User Master View Modules, View Modules, Sub-View
Modules and Active Elements are referred to collectively as 'Interface
Elements' and as
described so far, are each composed of similar types of Data Relation Table
records, tailored
to the responsibilities of the individual Interface Element. Consequently, all
Interface
Elements have Connect To records, and each Connect To record states - in the
manner just
described - the physical relationship of the immediate junior Interface
Elements that is
controls.
With these methods, if a particular Active Element expands or contracts due to
the
quantity of data it should display, any other Active Element that is related
to it by a Relative
Coordinate in the Connect To record, will maintain the same relative position
and spacing.
Using this method, a two Active Elements displaying a name such as 'Jon Mill'
will be
correctly spaced, and same two Active Elements displaying the much longer
name:
'Abrahamson Forthingram' will also be correctly spaced relative to one
another. The ability to
automatically maintain correct spacing can be desirable, when, for example, a
name appears
on an envelope, or as the signature of 'a letter'. In the example of 'a
signature', the position
of the first signature Active Element field containing 'Abrahamson' will be
related by its
Connect To record Relative Coordinate to the Active Element displaying the
Sign Off
Statement field - for example, 'Yours sincerely,'. The Sign Off Active Element
will in turn be
related to the Content field by its own Connect To Relative Coordinate.
Regardless of the
size of the Active Elements concerned, they will still maintain the correct
position relative to
one another. Interface Modules such as Active Elements can also be layered by
giving them
suitable Relative Coordinates.
The programmer, or the user, may subsequently move an Active Element or an
Interface Element, requiring that the value in the corresponding field of the
Connect To
Record needs to be re-written. This is done - together with any other
management of
Connect To records - by a Connect To Execution Record, which is a one record
Software
Module. Normally only one Connect To Execution record is required, and is used
whenever a
Connect To record is operative. When the physical relationship of one
Interface Element is
changed relative to another - by mouse movement iri a Visual Interface or by a
Language
453
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Processor- the Interface Element that is moved supplies its new position to
the Connect To
Execution Record, which re-writes the corresponding Connect To record to
record the new
position.
When an Interface Element such as an Active Element is added or removed, a
number of behaviors can be incorporated in the Connect To Execution Record,
for example:
1. The Interface Element that was connected to an Interface Element that
is removed takes over the Connect To reference that was recorded for the
removed
element. This requires the Connect To record to be re-written, and has the
effect that
the removal of an Interface Element results in the remaining Interface
Elements
closing up to fill the gap.
2. The user - as opposed to a programmer or a user acting as a
programmer - always begins from an existing, programmer-created Interface
Element. Hence, for the user, adding an Interface Element such as an Active
Element
is always a case of adding an Interface Element where at least one Interface
Element
always exists. The user may afterwards remove the original Interface Element
and
thereafter the one remaining - new - Interface Element will be attached to the
upper
left-hand corner of the Available space. When an Interface Element such as an
Active
Element is added - either by the user giving an order or by the user using a
Visual
Interface and mouse to do so - the added Active Element is likely to intrude
between
two existing Interface Elements. The manner in which this intrusion is handled
depends on the Interface Controls that are assigned to an Interface Module -
such as
an Active Element - either by the programmer or by the user. The term
'Interface
Control' covers any actions done by an Interface Module - such as an Active
Element,
or by data - when a specific Condition occurs - such as the intrusion of a new
Active
Element described above.
Interface Controls are Executions, and their corresponding Conditions and
Specifications that state how an aspect of the interface looks or behaves.
Many Interface
Controls however, need to be stated in relation to the capabilities of the
device concerned,
and these capabilities are stated in Device Setting, Data Relation Table
Records (or,
alternatively, using a Device Setting Data Assembly Table and records), as
follows:
- Device Setting Records or Device Setting Data Assembly Tables and Records
A 'Device Setting' is defined as a particular combination of controllable
parameter
settings for a given device that is part of, attached to, or accessible from
any given, computer.
Hence, a Device Setting Record states a particular combination of all
parameters that can be
configured for a single device, one parameter setting per field. In addition,
a Device Record
states a parameter combination in relation to 1 ) a particular user 2) a
particular computer and
454
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
3) in relation to a particular device, such as printer or screen named with
the name the user
gives them.
A standard Data Relation Table record contains a 'Device Setting' field as one
of the
fields in the Matter Data Category. As with Data Relation Table or Data Class
Assembly
Tables, field contents are either pure numbers, or references numbers that
either refer to a
pure number, or to a Data Class Table that provides the translation of that
number into a
spoken Concept Language
In the standard method of the Any-to-Any machine, any Data Relation Table
field can
have a record of its own type, and therefore, one method is to record the
combination of
parameters in a Device Setting Data Relation Table record, and then record the
number of
that Device Setting Record in the Device Setting field for any Data Relation
Table record
where it is required. For example, if a particular Data Relation Table record
or records are
printed at a particular setting, the Data Relation Table record that records
the Execution of the
order will contain the number of the Device Setting record in its Device
Setting field, that
states the particular printer parameter combination that was used. In the
state of the art, if a
document is printed with certain device settings, and then these are changed
and the
document is printed with other device settings, in order to print the item
again with the original
setting, the user should intervene and change the settings himself. However,
with the method
of the Any-to-Any machine, a document, for example, can be reprinted in the
manner in which
it was printed previously, simply by repeating the previously order-which
contains the device
settings used at the time - and unnecessary user intervention is avoided.
Alternatively, Device Setting Records may be created in a Data Assembly Table
termed the Device Setting Table, supported by any necessary Data Class Tables
for the
purpose of translating from a spoken Concept Language to a Numbers Concept
Language.
Alternatively, Device Setting Records can be created as a Data Relation Table
record type,
also supported as needed by a one or more Data Class Tables.
Certain devices may have sufficient parameters that more than one Data
Relation
Table record is required to state them all. Additionally, a Device Record
whether created in a
Data Relation Table or in a Data Assembly Table, is likely to require a
corresponding Label
Record, that states in user language the names the user applies to each
parameter and this
Label Record - which will be stated in terms of Number Language - will require
a Data Class
Table to record the translation of the Number Language in a spoken Concept
language. A
Label Record is desirable if the user is to use either a Visual or Language
Processor interface
to control the parameters, as the Labels themselves act as the name of the
parameter to be
controlled, Additionally, when any of the Device Setting parameters are to be
controlled by
ass
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the user, a Sub-View will be required to display the appropriate Device Record
with its
Associated Label recordls.
Most devices can only support one combination of parameter settings at a time,
and
consequently, each User Master View Interface Module normally uses one Device
Setting
Record at a given moment of time. However, a User Master View have more than
one
Device Setting Record at a time, provided that only one of them is marked as
'Active' in the
Device Setting Record's 'Active' Data Relation Table field. If a User Master
View is to change
between Device Setting Records for given data in this manner, then:
The User Master View will need to provide the Visual Interface user
with appropriate buttons in the form of Active Elements in order to change
between
Device Setting records, and thereby change the device parameter combination,
2. The User Master View Execution Record will need to contain provision
to remove the Active marking form the Device Setting record that was active,
and write
an Active marking into the Device Setting record that is to be active now.
However, as pointed out previously, a single user can use more than one User
Master
View - for example, for a particular screen - each with its own Device Setting
Record - and
can therefore, have one 'screen' that displays given data with one combination
of parameter
settings, and another 'screen' on the same physical screen, displaying other
data at other
screen parameter settings.
The particular Device Setting record that is in use at any one time by an
Interface
Element is recorded by the User Master View Execution Record Logic in the
Device Setting
field for all Interface Elements it controls directly or indirectly. In this
manner, the Device
Setting (which also includes a field stating the device itself) is available
to each Interface
Element under the control of a User Master View, and additionally is already
recorded when
an Interface Element is closed, and is therefore also available when it is re-
used at a later
time.
The Device Setting Record, as it contains the particular device in use, is
also a
statement of where the output is to be directed. If the operating system
itself is not written
with the method of the Any-to-Any machine, then the programmer should provide
logic to
connect and direct the output ordered by a particular Interface Element to the
appropriate
physical device.
The Device Setting Record, when it concerns a visual device - a screen or
printer for
example - contains a statement of the space that is available for a single one
of its output
units - a page in the case of a printer, or a single full screen in the case
of a screen device.
This statement of Available Space is then used by the User Master View
concerned to
allocate space to the Interface Elements it is controlling.
456
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- Method to Set Minimum Standard Size
The following are two types of display problems that occur in the state of the
art and
which inevitably lead to (unnecessary) user intervention to resolve them:
1. Screen areas that are too small to display the data the user wants to
see can require user intervention. For example, a field may show a user only
part of
Company Name, or only three quarters of the name of a town with a long name.
As
another example, splitting a 'window' into two, often results in one or both
of the
resulting panes being too small to read - when reading the divided pane was
the
purpose of splitting it in the first puce.
1 p 2. Screen areas that are too large for the data to be displayed require
the
user to intervene, in order to reduce the space they occupy and thereby make
visible
other things the user also wants to see at the same time.
These types of problems require undesirable user intervention; resolving them
requires the part of the interface that is displaying any given data is able
to detect the physical
quantity of data that it is required to output from a given Data Relation
Table field, or that is
being -input into a given Data Relation Table field. If the particular part of
the interface
concerned can detect the volume of data it should display, it then becomes
possible to
calculate how much space it needs to display that data in a readable manner.
In order to
display data 'in a readable manner' the interface also needs to know what
constitutes a
20 'readable manner', and this is achieved using the Minimum Standard Size
Method as follows:
The term 'Minimum Standard Size' is defined as 'The minimum size at
which a type of data can be displayed in order for that particular user to
consider it
readable or usable.' Hence, a particular 'Minimum Standard Size depends on 1 )
the
data 2) the user and 3) the particular input/output method, 4) the
input/output device
25 concerned and 5) the particular resolution at which that input/output
device is
operating.
2. A Minimum Standard Size, Data Assembly Table contains fields for 1)
the user number 2) A reference number that designates the type of data (text,
graphics, sound, etc) 3) The inputfoutput device name as stated by that user
4) the
30 reference number of a Device Setting Record, plus 5) fields in which the
Minimum
Standard Size itself is stated.
3. Types of Data: the Data Class Table itself, to which a given reference
in the Data Relation Table refers, contains only one data type, and therefore,
the Data
Class Table number of the reference itself acts as a reference for the type of
data it
35 contains. In fact, most Data Classes contain text, and a few of the
remainder - mainly
in Content Data Sub-Classes - contain different types of non-text content
(such as
457
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
audio video and drawings) hence the number of different data types is not
large.
When a Data Relation Table fields contains more than one type of data, it is
obligatory
that part of the reference number in the Data Relation Table field is a
reference to the
particular Data Class Table to which that reference refers. Hence, either a
given Data
Relation Table field contains only one data type, in which case the field
number itself
is a statement of its data type, or it contains several data types in which
case, the
reference numbers in its fields state which Data Class Table they-refer to and
hence,
the Data Class Table number is a statement of their data type.
4. The terms in which the Minimum Standard Size is specified depends on
the type of data that is to be input or output. For text, it can be convenient
to state the
Minimum Standard Size in terms of a font size, but if so, a field is required
that states
the average Character Size, in such a way that this states a concrete amount
of space
to use - in terms of pixels or similar. The name of the particular also need
to be
specified - different fonts in a given font style - such as bold or italic -
require different
sizes in order to display them clearly. In the case of an image such as a
photograph,
the Minimum Standard Size can be specified in the same terms that are used to
specify the real total output area.
5. Minimum Standard Size can be specified for all types of inputs and
outputs and an equivalent of 'Minimum Standard Size' exists for every data
type,
although a different descriptive term may often be applied to it. For example,
in the
case of audio, 'Minimum Standard Size' is in fact a minimum volume. If a
Minimum
Volume is recorded, then, in a way similar to the method to be described
whereby a
visual interface Element can change its size to make room for another
Interface
Element, Minimum Standard Size in relation to audio levels can be used to
reduce the
sound level automatically to the Minimum Volume when a competing and more
urgent
sound source appears such as someone addressing the user, or a telephone call.
Hence the method used to determine the minimum Standard Size of data to be
displayed is:
1. Only Active Elements display actual data. The Controller Logic of the
Execution Record of the Active Element that is to display or receive data
determines
the data type as described above.
2. It looks up the Minimum Standard Size Table looking for the record
applying to the data type, the User Number and the Device Setting that are now
in
use. If it fails to find such a record, it repeats the operation, specifying
User Number
field = empty in order to find the default record. In the case of images or
non-text
458
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
output, the Minimum Standard Size Specification will stated in terms of an
absolute
Specification that specifies a specific size in the actual output area.
3. Assuming that text is to be displayed, one of the Field Logics of the
Active Element calculates counts the number of characters to be displayed or
being
entered, counting a space as a character. This figure is termed the Character
Count.
Another of the Field Logics multiplies the Character Count by the Character
Size, to,
obtain a Requested Size
4. The Requested Size is placed in the field of the Associated Active
Interface Module Record termed a 'Request Record', which will be described
shortly.
The above method effectively detects the size of the data - using text as an
example -
to be output or being input. The senior Interface Module can use the data in
its Request
Record, - which states the area requested by each of its junior Interface
Elements - plus the
data in the Connect To record, plus data in Interface Control records now to
be described, to
work out the actual area that is needed to display all its junior Interface
Elements at the
Minimum Standard Size. The Interface Element, after working out the total
Space it's junior
Interface Elements require, places its total requirement into its own field of
its senior Interface
Module's Request Record. In this manner, all Minimum Standard Sizes are added
up for
each Sub-View, each View, and presented to the User Master View in the User
Master View's
Request Record.
Values for Minimum Standard Sizes are stated in the Minimum Standard Size Data
Assembly Table by the programmer and are referred to by all Sub-View Modules
in order to
calculate the physical space they require for a given input or output. Because
these Minimum
Standard Sizes are stated and referred to in the Minimum Standard Size Table,
if a user has
difficulty seeing data when it is displayed at the programmer's choice of
Minimum Standard
Size, he can change the Minimum Standard Size by any available increment, and
changing it
for him, does not also change it for any other user. One user can be see given
data at one
size that suits him, while another user sees the same data a the different
size that he finds
most suitable. If the user is to make such changes, then the programmer needs
to provide a
Sub-View with which to make the change. Thereafter, with the methods of the
Any-to-Any
machine, any display can be made at the user's selected Minimum Standard Size
if physically
possible.
The calculation of the minimum screen area required by an Interface Element
based
on Minimum Standard Size is one of the parameters needed to calculate the area
to be
occupied by a given Interface Element such as an Active Element.
459
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- Method to Construct Interface Controls
'Interface Control' is the term used to cover control of the parameters that
Interface
Modules need available in order to control the format, appearance and behavior
of the visual
aspects of the interface. Interface Control includes control of parameters
such as color to be
applied to text or to backgrounds on a screen or in printed or projected
output, or to borders
that create boxes that are the equivalent of 'windows'. Similarly, Interface
Control can cover
control of changing the shape of an Interface Element and how Interface
Elements behave.
Most Interface Controls apply in one manner to the data displayed and in
another
manner to the Active Element that is displaying the data, although the
Interface Control is
both cases the same type of thing. For example, a Specification for a
particular color of blue
can be applied to an Active Element to outline it so that it looks like a box,
or to the data
displayed -for example, some text, so that the text is colored the exact same
blue. The
Interface Control Specification for that exact color of blue is the same in
both cases and only
needs to be specified once in the Any-to-Any machine and then can be applied
to anything
that can be colored - a text, a background, an outline, an arrow etc. The Data
Component
that is that color of blue can be specified once, in a Data Class Table for
color, and then
assembled in Data Component Assemblies that color text, or a background, or an
outline or
an arrow, etc. While the Data Components themselves - one exact color of blue
for example
- do not apply to anything in specific - they are simply a Component - once
assembled they
do apply to something specific. Hence, once assembled in either a Data
Assembly Table or
in a Data Relation Table record, that Data Assembly Table or Data Relation
Table record can
be related to something specific - such as 1 ) An Active Element and 2) A
particular border or
borders for that Active Element. Such assemblies can then be classified - for
example with a
field stating that this particular record pertains to Active Elements, or to
displayed data.
The general construction method for an Interface Control follows the standard
and
fundamental method of the Any-to-Any machine for creating anything in the Any-
to-Any
machine, namely:
1 ) Disassembling the data in question into Data Components that meet
the Any-to-Any machine definition of a Component.
2) Separating Data Components into types.
3) Storing each of these Component types in a separate Data Class Table
named for that Component type.
4) Assembling Components into useful assemblies by specifying the Data
Class reference numbers of the Component to be assembled, using either a Data
Assembly Table (if each assembly consists of relatively few Components) or a
Data
Relation Table record (if that type of assembly consists of many Components)
460
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Hence, the method for constructing Interface Control Data Relation Table
records for
an application is as follows:
1 ) List every Interface Control that is preferable for the application in
question. Pay attention to ensuring that the listed Interface Controls cover
both Views,
Sub-Views and Active Elements that display the data, and as well as the data
itself.
2) Review each of the Interface Controls that have been listed, and
completely disassemble each one of them into Data Components meeting the
definition of a Data Component as described previously. If an Interface
control is an
assembly of Components - for example 'object position' - i.e. if the Interface
Control
does more than one thing or serves more than one function or is specified by
more
than one parameter, - then the assembly should first be broken down into Data
Components per the definition of a Data Component. Frequently, it will be
found that
a different Control uses the same Component, but in a different manner - for
example, a color will be used in a number of different controls, 'left margin'
wilt apply
to a letter, a screen, within an Active element and so on. While duplicates
should not
be recorded - only one of each Component is needed - it is useful to note all
the
different Interface Controls in which a Component is used as this is of
assistance with
the last stage, which is the assembly of Data Components.
3) Create Interface Control Data Classes by dividing the Interface
Controls, now in the form of Data Components, into groups in which each member
of
the group is more similar to the other members than it is to any other member
of any
other group. If something that is supposed to be a 'Component' is found not to
be
similar to any other member of any group then it may still be an assembly and
require
further disassembly, If the 'Component' cannot be further disassembled in any
manner and still retain a part of its original function or meaning, then it is
a member of
a new group. When a supposed 'Component' appears to belong in more than one
Data Class, this is usually because the supposed Data Component is not
actually a
Component at all but is still an assembly of Components and this has resulted
in it
having the characteristics of, and similarities to, members of more than one
Data
Class. The solution is to examine the supposed Data Component and attempt to
further disassemble it. An example of this kind of problem is the data
assembly that is
the word 'letter'. 'the word 'letter' is an assembly of a number of Data
Components,
one of which is the symbol itself, assembled together with a number of
different
meanings - each of which is another Data Component. Thus 'letter' can be an
action
- ' letter that name on the door' - or a thing - 'where is the letter from
Joe?'. The word
'letter' is.at one moment similar to words of action, and at another, similar
to words
461
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
describing things. It has similarities to both groups, because one ofi its
Components is
similar to other actions, while another, different one of its Components, is
similar to
other Components that describe things. The similarity to two or groups comes
above
because of the different Components in the word. The result of this step is
that the
Data Components for Interface Control are divided into Interface Control Data
Classes, each of which consists of a list of similar types of Component..
4) Each of the Interface Control Component Data Classes are then
assigned to one of the five Data Categories.
5) Comparing each of the Interface Control Data Classes in a given Data
Category to the Data Classes in the main Data Relation Table, will normally
show
which Data Relation Table Data Class the particular Interface Control Data
Class
corresponds to. In other words, it will be found that an Interface Control
Data Class is
a specialized, and probably re-named version of one of the main Data Relation
Table
fields (i.e. Data Classes). On the basis of this comparison, the Control Data
Classes
are placed in the same order versus one another, as they appear in the main
Data
Relation Table.
6) Placing the Interface Control Data Classes into order in this manner
actually assembles them into a miniaturized version of the Data Relation Table
Data
Class, The Interface Control Data Classes are now compared to the main Data
Relation Table to see which fields appear in the main Data Relation Table but
not in
the Control Data Class assembly. Each field appearing in the Data Relation
Table but
not in the sequence of Control Data Classes should be examined to see if it
could
actually be required to help control the Interface. Frequently, it will be
found that at
least some of the Data Relation Table fields that are in the Data Relation
Table but not
in the Control Data classes are actually required or at least potentially
useful, and
hence, should be included.
The result of this procedure is that a number of Interface Control Data
Classes exist
Interface Controls in general are controls that work with a particular
Interface Element
and are therefore Associated Records - they are associated with a particular
Interface
Element such as an Active Element. When a number of Data Classes exist, and
all of then
act only in Associated Records, the Any-to-Any machine method for using them
is as follows
(using Interface Controls as the example):
Record Type Field No 1 ~ Field No 2 Field No 3 Field No 4
462
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Active InterfaceExecution Execution Execution Execution
Module RecordRecord Record No Record No Record No
No for for for
for ModuleModule 2 Module 3 Module 4
1
Interface y 2 3 4
Control
1
Interface 1 2 3 4
Control
2
Interface 1 2 3 4
Control
3
Interface Control ata Ass bly Table
Interf I terface Interface
Record Numberce
Co trol ontrol No
Cont of No 2 3
No 1
1 ~ 1 \ 1 1
2 2 2 2
3 3 3 3
4 4 4 4
1. An Interface Control Data Assembly Table is created, containing one
field for each Interface Control Data Class, plus a record number. A record in
this
table then, can contain one value for each possible Interface Control - each
Interface
Control Data Class.
2. A single record in the Data Assembly Table contains values for each of
the fields for one of the Interface Elements concerned. Referring to the
following
diagram, record number 1 in the Interface Control Data Assembly Table contains
values for each of the Interface Control Record types (Interface Control 1, 2
and 3
record types) that are Associated Records to the Active Interface Module
Record.
Data Relation Table
This type of Data Assembly Table - where one record in the table provides all
the
references referring to one of something in the Data Relation Table - is
termed Reciprocal
Data Assembly Table.
Two methods exist for using a Reciprocal Data Assembly Table:
1. The Reciprocal Data Assembly Table record numbers can be used in
single Associated Data Relation Table record - this method is not shown in the
diagram above.
463 '
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2. Alternatively, the Reciprocal Data Assembly Table can be used to
supply the reference numbers needed for each of the record types that are
Associated
- records types Interface control 1, Interface Control 2, Interface Control 3,
in the
above diagram.
An Interface Control Data Assembly Table can be extended to include fields for
the
Execution Record of an Interface Element - such as an Active Element - and all
other record
types that are Associated records for a given Interface Element. However,
while an Active
Element and its controls can be assembled this way, it is not desirable to do
so, because
then, a specific Active Element can no longer be used with ANY Interface
Control
Combination.
Hence, the one method is to create an individual Active Element is as follows:
1. An Active Element Data Assembly Table is created, whose purpose is
to assemble Logics into Active Elements.
2. The record number in the Active Element Logic Data Assembly Table is
used in an Active Element Data Assembly Table that assembles 1 ) The Active
Element Logic 2) An Interface Control Record number. 3) Other fields as
necessary.
In this manner, any Active Element can be used with any Interface Control
combination.
Interface Controls may apply to an Interface Module - such as an Active
Element that
is displaying the data - or to the data itself. For example, a particular
color of blue may apply,
as mentioned, to a specific text, or to an Active Element border, so that it
appears as a blue
box. When an Interface Control can apply to the Interface Element and also to
the data
displayed by it, then there will need to be different Data Relation Table
record sub-types for
the Interface Control - one in which it applies to the Interface Element, and
one in which it
applies to the data displayed by the Interface Element. When Active Elements
are
transparent - i.e. borderless and colorless - Interface Controls do not need
to be applied to
the Active Element, only to the data.
- Types of Interface Control Records
Two types of Interface Control exist:
1. Passive Interface Controls, such as Bold, Italics, colors, indents. These
are usually assigned initially by the programmer, and afterwards changed by
the user.
They are termed 'passive' as they do not change in response to anything - for
example, they do not change in response to a particular value or range of
values
being displayed, etc. Passive Interface Controls are specified using an
Interface
Control Data Assembly Table and appropriate Data Relation Table Associated
record
types as already described.
464
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2. Active Interface Controls. These are Interface Controls that do
something - change in some way - in response to specific Conditions' this type
of
Interface Control will not be describe din more detail.
An Active Interface Control is defined to mean 'any action done by an
Interface
Module - such as a View Module or an Active Element Module - in response to a
particular
Condition, that results to a change in the display itself.' Thus Active
Interface Control actions
are Executions that are done by the interface in response to Conditions, in
accordance with
Specifications. These behaviors can be such things as the displayed data
andlor the Active
Element or View turning red if data within a certain range is displayed
Hence, the parts required to construct an Active Interface Control are 1 ) a
Condition,
2) A Specification and 3) an Execution.
One of the most useful types of Interface Control those that allow an
Interface
Element to economize screen space if desirable. It has previously been
described that:
The spatial relationship of one Active Element to another is a desirable
part of conveying to the user the relationships of different data one to
another,
2. )nterface Modules including Active Elements can re-size themselves
depending on the data they are displaying.
Additionally, as will be described, one Interface Element - such as a View -
can
squeeze itself into a smaller space to make way for something more desirable
on which the
user has his attention.
Because of these factors, Interface Modules need to know how Active Elements
can
be moved or changed so as to economize space - i.e. to display the maximum of
data that
the user wants to see, while using the minimum of space to display items the
user is not
concerned with at a given instant, but does not wish to dispose of either.
Generally in the
state of the art, provision is made to:
1. Make something smaller or larger, but without changing the size of the
contents, so that when the item - a Window for example - is made small, the
data that
can be seen is reduced in quantity, and the data that is visible may not even
be
recognizable or intelligible. For example, a field displaying 'John Brown' can
be
reduced in width, but my then display 'Joh......'. As a separate operation,
the size of
the text can be reduced, so that the user can now see 'John B...' but whether
this
means 'John Brown' of 'John Bailey' can be unclear and even actively
confusing. In
effect, the display element, such as a window, and the data displayed by the
display
element 'John Brown', cannot be re-sized as a single nit, and enlarged and
reduced
together in one step. This requires user intervention that is essentially
unnecessary.
465
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2. State of the art interfaces also provide for replacing a large version of
something - a Window for example - with a smaller, but unrecognizable version
of the
same thing - an icon for example. This transformation can be sufficiently
radical that
the untrained user does not know and cannot guess that the icon is a
transformed
version of a larger window and he can think his window has simply vanished.
Provision generally does not exist in the state of the art to enlarge or
contract all of
any chosen grouping. For example, 'zooming' the contents of a window does not
change the
size of the entire item, only the data displayed in the window.
When the size of the area used by Active Element is variable - depending on
the data
to be displayed and also depending on what the user is doing - the Interface
needs a method
to know which positions of a specific Active Element are most desirable, which
positions are
permissible and which positions are not permissible. Additionally, it needs to
have available
as many methods of economizing space as possible, so it can reduce the space
consumed
by interface elements that are not essential at the moment. Effectively, the
requirement is for
a behavior that is analogous to passing a 'contracting glass' - the opposite
of a magnifying
glass - over items that are not of immediately interest, leaving enough space
to see clearly
those that are of interest.
When such methods are available, the logic in an Interface Module can re-
position or
change the Interface Modules it controls = such as Active Elements - when
able, and thereby
accommodate the data to be displayed to the available space in an optimum
manner.
Some useful Interface Controls are as follows:
ALLOWED POSITION
Normally, when adequate space exists, it is possible to display data - such as
a name
- in full as follows:
John Brown
In this example, 'John' would be displayed by one Active Element and 'Brown'
by
another. However, when horizontal space is short, it may be desirable to
display the name
as:
John or as Brown
Brown John
However, it would not be desirable to display 'John' at the top of the screen
and
'Brown' at the bottom of the screen, as the Spatial Data Relationship
Statement would be
changed so much that the part of the relationship of the two words conveyed by
their spatial
relationship would no longer be transmitted. In effect, when the Condition is
met that the
available space is not enough to display desirable data at Minimum Standard
Size in the way
it was previously displayed, then sometimes, it can be permissible to re-
position data and
466
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
when that is permissible, it may be permissible to re-position data in some
ways, but not in
others. For example, a user may want to see more columns than can be visible
at one time in
a tabular output display. He may introduce further columns, but then faces the
choice that
either he can no longer see a column he wants to see, or he can only see a
part of the data
he wants to see in one or more columns. In the state of the art, the absence
of the ability to
state how data may be repositioned requires the user to intervene, and, as
discussed, user
intervention should be avoided. Repositioning Active Elements - as described
above - can
avoid undesirable user intervention requirements.
Allowed Positions are stated initially by the programmer placing an Active
Element
firstly in the Desired Position - for example with a mouse, an Interface
Control Sub-View (or
Language processor) allows the programmer to state this is the Desired
Position. The
Desired Position is stated as Relative Position, stated as a Coordinate Set in
the Connect To
record. The programmer can then move the Active Element to another position
and record
one or more alternative Connect To, sub-type 2"d (3'd, 4tn) Choice records,
again using an
Interface Control Sub-View to state that this is an Allowed Position. Allowed
Positions are
recorded - as a Displacement Coordinate Set - directly in one or more Connect
To secondary
Position records that are both Associated Records with the Active Interface
Element record,
and are Companion Records to Connect To Records. (A 'Companion Record' is a
record that
works together with another and may - as in this case - present an
alternative). Recording an
Allowed Position is done by an Allowed Position Interface Control Software
Module that
records the secondary Connect To records when activated by the programmer or
the user
clicking on an Active Element labeled 'Allowed Position' in the Interface
Control Sub-View.
A secondary Connect To record for a specific Interface Element is an
Associated
Record with the Active Interface Element Record that the Interface Element is
using to control
its juniors.- An Allowed Position, because it is a Coordinate and hence it is
a number, can be
recorded directly into the Data Relation Table. However, if the Allowed
Position may need to
be translated into words such as 'Above' 'Below' etc, - as required by a
Language Processor
- then a Data Class Table will be required to do this. As in the case of all
Data Classes
where the Data Relation Table entry is a number - a Relative Coordinate Set in
this case - it
is not necessary to use a reference number, but the Numbers Language
translation of the
Spoken Concept Language can be directly stated in the Data Class Table.
In the example given above, one re-arrangement of 'John' 'Brown' was:
Brown
John
This is an example of where not one, but two (and potentially more) Active
Elements
should change to different Allowed Positions, and one of them changing without
the other
467
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
would cause a problem. This problem can be solved with the standard methods of
the Any-
to-Any machine, of which the following are two examples:
1. A Companion Sequence Record called Must Change record can state,
in each field, those fields that should either change together, or not at all.
Thus the
first field in such a record could state for example (punctuation added for
clarity)
014,019,111,139 to indicate that if any one of the fields 14, 19, 111 or 139
changes to
an allowed position, they should all change. Further fields in the Must Change
record
can state other.combination of fields that should change their Desired
Positions
together, or not at all.
2. A code number can be added to each Connect To secondary record
field, pointing to a Data Assembly Table that specifies in its records, the
particular
fields that can change together.
Every Execution has the basic format of 'Under Condition X, Do Action Y to
Specification Z' An Allowed Position is an example of an Interface Control,
where the
Specification Z - the Allowed Position - is held in the secondary Connect to
record, while the
Action X - the part of a Module that does the Execution - is not necessarily
closely
associated with it but in this case is part of a Software Module that
calculates Spaces.
Meanwhile, the Condition X, is actually part of the another and senior
interface Module that
effectively states to its junior Module ' Condition X (i.e. space is short) is
met.
Allowed Positions are executed an Allowed Position Execution Module.
ABBREVIATION EXCHANGE
Abbreviations are an desirable and useful part of the language, but equally, a
computer cannot use them unless they have been recorded somewhere.
Abbreviations class
into different types:
Abbreviation by Rule
Some Data Classes - First Name for example - can be abbreviated on the bases
of a
rule, and hence, 'John Brown' can be abbreviated to 'J. Brown' or to 'John B.'
or even to 'J.
B.' Which of these - if any - a user finds acceptable can be ascertained when
the application
is installed, while at the same time finding out which date abbreviations and
other such
abbreviations the person finds acceptable.
Abbreviations of this type - Abbreviation by Rule - are dependant on the Data
Class
and not dependant on the value in the Data Class. When Abbreviation rules are
obtained
from the user at installation, they are stated in a Data Assembly Table called
'Abbreviation
Rules' fields for 1 ) The Data Class to which the rule refers 2) an 'Active'
field to show whether
that abbreviation is active or not 3) the number of the Software Module that
does the
abbreviation, 4) An example o~f-the unabbreviated data in the Spoken Concept
Language and
468
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
5) The example after abbreviation. A Sub-View displays this table, -sorts it
in a suitable
manner and allows the user to choose which of a number of alternatives to make
Active.
Abbreviation by Statement
Many abbreviations do not follow any particular logic. While BSc. is 'Bachelor
of
Science' PhD for example, if expanded in the same manner becomes Philosophy
Doctor and
if abbreviated the same way as BSc should be DPh. Hence many abbreviations in
most Data
Classes are a matter of convention, leaving no alternative but to record them.
For this
reason, Data Classes in most applications need to contain not one field for
the Spoken
Concept Language statement - one for the full expression, and one for the
abbreviation, and
when new values are entered into a Data Class, the Module entering them should
ask for an
abbreviation.
Abbreviations can be useful to reduce space in an interface. One method of
using
them is to use an additional Abbreviation Module - a one record Software
Module, that looks
up the value in each field in an output in the appropriate place - either the
Abbreviation Rules
Table or the Data Class - and places the results into a record that is a
Companion Record to
data record concerned and is called an Abbreviation Record. The Abbreviation
Module
places in the Abbreviation Record either the number of the Software Module to
use - in the
case of a Data Class that subject to Abbreviation by Rule - or the reference
for the
abbreviation in the vase where the abbreviation is recorded in a Data Cfass.
MOVEMENT
Examples of Interface Control Movements, applying to Interface Elements that
are
short of space are:
Squeeze The Interface Element reduces in size. In
effect 'squeeze' is a proportional reduction of the Interface
Element and whatever data it is displaying. Squeeze is taken to
signify an overall contraction in relation to a central point, and
has an opposite - Expand - a proportional increase in
dimension in relation to a central point.
Turn Up The Interface Element hinges upwards in
the horizontal plane, as though its lower edge had been lifted
up. A rectangle, Turned Up, shows as a thin rectangle, as
though the original rectangle has a thickness and is now being
seen as though looking at its lower edge. Turn Down is the
opposite of Turn Up and rotates the upper edge downwards.
Turn Sideways The Interface Element hinges to
the left in the vertical plane as though its right hand end had
469
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
been pushed away much as a door might open away from a
person walking through it. A rectangle, Turned Sideways,
shows as a thin rectangle, as though the original rectangle had
a thickness and was now being seen as though looking at its
right hand end. Obviously Turn Sideways Left and Turn
Sideways Right are variants of Turn Sideways.
Any 'Turn' behavior can be used to activate a secondary Active Element that
displays
- for example - the first line of the data that was in the unturned Active
Element. This can be
achieved using a second Active Interface Module Record, type Replacement, to
specify the
1 Q replacement Active Element, and an accompanying Replace Interface Element
Module whose
Execution Record receives a Token stating the Execution has occurred and that
the Active
Element Specification in the second Active Interface Module should be used to
activate the
required replacement Active Element.
Other, more fanciful movements can also be devised if required and examples
are:
Spin The Active Element spins in its position. Spin
can also have a use as a way of drawing attention to something
such as an emergency.
Walk The Active Element moves around the interface.
Walk is a behavior that can be of use to Help. A Module with
Walk behavior and displaying a suitable image can be used to
point things out to a user in a learning program, for example, or
as an aide to a first-time computer user.
Grow and Shrink are considered to differ from Expand
and Squeeze in that Grow and Shrink are expansions and
contractions where the change occurs in relation to a fixed
coordinate - for example, an Interface Element could 'grow
right' - its left margin remains in the same place, and the
expansion occurs uniformly, using up space to its right. Grow,
Shrink, Expand and Squeeze, in addition to using space when
available and reducing the space needed when space is short,
can also be useful either draw attention to something on the
screen -especially if Squeeze and Expand are alternated to give
a pulsing effect. Expand can also be useful if, for example, the
data to be controlled is very small - for example a single word.
As one use of Expand, the data can be expanded as long as the
mouse cursor hovers over it. Alternatively if a number of
470
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
buttons performing various controls need to be crammed into a
small space, Expand can be use to enlarge them and make
them more useable as long as the cursor however over them.
Squeeze, Expand, Grow and Shrink require one or more additional set of
coordinates
for the new position and potentially a Timing Data Relation Table record that
specifies the
rate of transition between them, plus an Execution Record that controls the
transition of the
Active Element or other Interface Element.
Justification - whether of texts or of objects - is treated in the Any-to-Any
machine as
a type of Expansion and Contraction. 'Equalize' as in spreading out columns or
rows evenly
within the available space is a variation of justification, but in this case,
applying to interface
Elements. Increasing or Decreasing White Space, 'Squeeze in as much as
possible' are
further and more sophisticated variants of Expand and Contract.
Turn, Walk, also need additional sets of coordinate records and Timing
Records, and
may also require a Coordinate Data Relation Table (Sequence) record type, to
list and specify
intermediate coordinates in the transition.
Movements of different kinds can be specified as follows:
Movements, like Allowed Positions, apply to a specific Interface
Element such as an Active Element and therefore are Associated Records,
Associated with the Active Interface Element record.
2. Movements consist, tike any action, of a Condition, a Specification and
an Execution for each Movement. While the Condition may be decided elsewhere,
for
example, by the Senior Interface Module under whose control the movement
occurs,
fields will be required for the reference number of the Field Logic to be used
(the Field
Logic that does this Movement) and for the Specifications which the Field
Logic uses.
Hence, Movements can be constructed in the Interface Control, Data Assembly
Table
3. A Data Class Table is likely to be preferable if Movements are to be
controlled by the user, in order to relate specific names to specific movement
Field
Logic reference numbers.
The remaining Interface Controls that will be described are all constructed
using the
Any-to-Any machine methods just described, and therefore, construction methods
for them
will not be repeated, and only the Interface Control itself will be described.
ALIGNMENT
Humans can easily move something - such as an Active Element - approximately
where they want it, but find it time-consuming to align objects exactly. When
a Visual
471
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Interface is in use, and only some of all possible alignments types are
installed, then a user
can easily be limited by the Interface itself. The Visual Interface, by
informing the user what it
can do, - for example, which kinds of alignments it can do - equally informs
him at the same
time of those it cannot do. Hence, a Visual Interface can communicate the
limits to the user
in a relatively simple manner. However, when a Language Processor Interface is
in use,
there is no simple way to communicate limits to the user. When the user finds
them by
accident - he specifies something that could in theory be done, but which the
computer
cannot do - then a) User intervention is required and b) the resulting machine
appears
unreliable because the user cannot predict its limits. The realistic solution
to causing this
aspect of apparent 'unreliability' is to ensure that the computer can do
anything that
theoretically can be done, and hence, the user's orders will not fail
unexpectedly.
Furthermore, the access the Software Module doing any of these actions should
be non-
hierarchical in manner, since the user's command-giving is also non
hierarchical. Failure to
achieve these standards means that the computer will fail - unexpectedly as
far as the user is
concerned.
'Align' is an example where the Any-to-Any machine needs to provide for every
one of
the extensive numbers of different types of alignments that may be of use at
different times.
The following are a number of examples of different alignments: Move to
Center. Align to
Center. Center Horizontally. Center Vertically. Center Horizontally and
Vertically. Align to
Left (of page/ line, margin, box,~selection etc). Align Right. Indent Left,
Right. Snap to Grid,
etc. In addition to these there are some changes of alignment that are not
found in most
state of the art applications that could be useful if enabled, such as the
ability to specify that
one thing should be aligned based on another such as 'Align left side to left
side of the data
above', 'put all data into columns.'
Alignments are a statement that one or more parts of the Coordinate Set of the
Interface Element concerned (or the data displayed by it) is the same as one
or more parts of
the Coordinate Set of something else, or is displaced from a specific part of
the Coordinate
Set of something else by a specific amount.
Since there are many possible alignments, but many of them conflict with one
another
and cannot therefore be used at the same time, one way of handling Alignments
is to create
an Alignment Data Class table that States all possible alignments, together
with a field for the
reference number of the Field Logic that does that alignment. Active Interface
Element
record can then have an 'Alignment' record that states, in each field, the
appropriate
reference number for the alignments in use. The Interface Control Sub-View can
then list the
Data Class Spoken Concept Language value for each of all the possible
alignments, and this,
when clicked, calls the Field Logic appropriate for that Alignment.
472
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The programmer can use individual Interface Control Records (Active Interface
Module Associated records) to control the behavior of the Interface Elements.
Alternatively
he can use a single Interface Control record, which states the number of
Interface Control
Data Assembly Table record that applies to each of its fields for which the
Active Interface
Element record has an entry.
In either case, the Field Logics required to use the Interface Control can
either be
incorporated in the Field Logics of the Interface Module itself, or created as
separate
interface Control Software Modules where an Execution Record is required to
manage an
' Interface Control. In the main, Interface controls that are used by an
Active Element to know
what to do, are a variety of Specification and need no Field Logic. Interface
Controls that
make an Interface Element do something - such as causing an Active Element to
turn flat -
do require a Field Logic to execute the change.
Due to the fact that with the methods of the Any-to-Any machine, each Data
Relation
Table field being displayed is displayed in its own Active Element, and each
Active Element
can be individually controlled, Interface Controls can be designed for Active
Elements that are
only limited by the programmer's imagination.
ENHANCEMENTS - COLOR, BOLD, ITALIC ETC
Enhancements such as Color, Bold, Italic, have been described as individual
Software
Modules that perform the named functions, and such Software Modules are made
available
through any level of Language Processor and/or by presenting them on a Sub-
View that is a
menu. Even at the simplest level of Language Processor (as previously
described) all such
Interface Controls can be available, and would normally be accessed by the
user writing - for
example - 'Bold' in the Active Element that serves as the data entry box to
the Language
Processor, and then indicating with the mouse which Active Elements are to
have their text
made Bold. Alternatively, the user can equally do the actions in the reverse
order - select the
Active Elements first and then write into the Language Processor entry box
'Italic, Bold, Blue'
specifying a number of Interface Controls at the same time. An advantage of
the Any-to-Any
machine is that, because every Execution in the Any-to-Any machine is
constructed in the
form of a Condition plus an Execution plus Specification, it is of no
importance which of the
required Conditions is satisfied first - whether the Specification (selected
Active Elements) is
provided first, or second, as the Execution is specified first or second. A
further advantage is
that in an instance such as this example, where the Conditions are identical
for several
Executions, - Italic, Bold, Blue - they can simply be stated one after the
other and execute
correctly, and this is possible with the Any-to-Any machine because these
Executions are not
forcibly inside a hierarchy. (In the state of the art, while Italic and Bold
would be found in one
command~hierarchy, Blue would almost certainly be found in another, and it is
the presence of
473
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the command hierarchy that prevents a user saying, or writing, or clicking
'italic, Bold, Blue'
and continuing with 'Yellow Background, Double the font size' if he wants to.
All data, including Content processed by a full Language Processor is recorded
in the
form of Data Relation Table records, and hence Content itself displays as a
continuous string
of Active Elements - that are normally not colored and hence are transparent
and invisible.
Operator Words that do not appear in the Data Relation Table Content records,
but are
added in by the Language Processor in the course of Grammar Formatting - the
process of
turning Concept Language into recognizable speech - each appear in their own
Active
Element. Because of this method, Any Interface Control that is possible for an
Active
Element can be applied to Any word. In the infrequent cases where the user
wishes to apply
a particular Interface Control to only part of word, then the word is split
into further fields, with
potentially one character of the word being split placed in each field of a
Split Word Data
Assembly Table by a Split Word Module. In effect, the Split Word Module is a
Module that is
a type of Converter Module, and turns a word into Virtual Data Relation Table
fields, so that
each field can have its own Active Element. Hence, any Interface Control can,
in this manner
be applied to any character. This method is not limited to use with Content
that is record in
the form of Data Relation Table Fields but, if the requisite Module and
supporting table is
present, can be used on the contents of any field.
Software Modules, in order to perform actions such as those mentioned above,
write
to Active Interface Element record Associated Records, of the type Interface
Control,
Enhancement sub-type. Enhancement records are handled with the exact same
methods as
described for other Interface Controls.
The programmer can provide for one Associated Record type per Enhancement, if
he
wishes, or assemble combinations of Enhancements in an Enhancement Data
Assembly
Table that provides one field for each possible Enhancement type and then use
that record
number in a single Enhancement record. In either case, Data Class Tables may
be needed
to record the translation between Spoken Concept Language and plumbers Concept
Language. All Enhancements can be placed in one Data Glass Table if it
contains a field to
specify the Type of the enhancement. However, Color as a Data Class is cannot
easily be
specified precisely with words, and therefore, color choosing mechanisms that
work well in
the state of the art should be used in combination with the Color Data Class
Table.
CONDITIQNAL INTERFACE CONTROLS
Interface controls that produce specific changes in visual aspect depending on
the
value of the data can be extremely effective in drawing attention to critical
data but in the
state of the art are generally available under comparatively simple user
control generally only
in spreadsheets, even though they can be useful in virtually any input/output.
Such controls
474
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
can be especially effective on input, to detect values that should display a
Prompt advising
the user to take certain actions. For example, supposing the Any-to-Any
machine methods
are used to construct a medical diagnostic application and the user is in the
process of
entering symptoms that match a certain Interface Control Condition record,
even before the
entry is finished; Conditional Interface Controls could lead to the entire
screen turning red, a
large Active Element displaying with the Prompt 'This indicates a potentially
serious
Condition. Lie down immediately, raise your feet on a pillow or chair and
breathe deeply and
wait. 911 has been called, I will keep you informed of their arrival."
Conditional Interface Controls are only a particular of aspect of the Any-to-
Any
machine's ability to allow the user to specify Conditions under which a
Specification Execution
or Executions are to occur on a specific Specification. User Condition records
generally are
exactly like Software Module Condition records already described with the
following
differences:
1. They are created by the user, not by the programmer
2. They can be related by the user to Software Modules and to
Specifications and activate those Modules when the Condition is met.
In effect, a User Condition record is only a Find Specification that runs
under
circumstances that are stated in some manner in the User Condition Record
itself. These
circumstances can potentially be fairly limited - as is the case for a
Conditional Interface
Conirol, where the Find to see if the Condition Record is matched only runs
periodically on
potentially on one field in a View Collection. At the opposite extreme it can
be virtually
unlimited as in the example of a User Condition record running in a large
multi-user
environment such as a company, where the Condition record states the Data
Relation Table
equivalent of 'alert me if anything is mentioned about security by anyone'. It
is under such
circumstances that considerable extra processing power becomes useful,
enabling several
thousand such User Conditions to be run continuously against the Data Relation
Table or a
mirror copy of it on another machine, as described later under the heading of
Methods to
Ensure Fail-Safe Performance.
The construction of a User Condition is as follows:
1. When the User Condition is Table Parallel - i.e, it is to be run against
complete Data Relation Table records, or combinations of records - the User
Condition is constructed as one or more user Condition records and the first
of these
states, in its Director field the reference number of the Software Module to
be run
when the Condition stated in the Condition record is met. If many Modules are
to be
simultaneously, the Director Field can point to a Director Record that
contains a code
in its Marking field stating whether all the Software Modules referenced in it
are to be
475
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
run simultaneously, or in sequence, one after the other. Conditions stated by
users
are termed a Condition records, Sub-type User, Sub-Sub type, Table Parallel.
2. When the User Coridition is Field Parallel - i.e, it is to be run against a
single field, and the Condition for the next field may be completely different
- then it is
more convenient to construct the user Condition as follows:
a. A Condition Record is used that is Field Parallel - i.e. the
Condition in each of the Condition Record's field is the Condition to be met
by that field only, and other fields contain (potentially) other Conditions,
each of which is to be met by that field only.
b. The Field Parallel Condition record is accompanied by a Field
Parallel Director Record that states the Execution Record number of the
Software Module to be used when the Condition in that field of the
Companion Field Parallel Condition record is met. In the case of
Conditional Interface Controls, this will be the name of one of the Software
Modules that changes Interface Controls, such as Bold, Italic, Blue etc.
This type of User Condition Record is termed a Condition, Sub-type User,
Sub-sub type, Field Parallel. When a Field Parallel Director Record is
used, and more than one Software Module needs to be run (when the
Condition in the corresponding field is met), each field in the Field Parallel
Director Record can point to a Director record that states either the list of
Software Modules to be run simultaneously or in sequence. Such Director
records, like any other record can be joined with the AND mechanism. In
this manner, when a single Condition is met in a single field, a massive and
unlimited amount of Execution can be launched as a result.
In the case of Interface Control, although it is usually more useful to use a
Field
Parallel Record, a Table Parallel record can also be used, to detect a
combination of
Conditions in several fields of the input/output. Equally combinations of both
Table Parallel
and Field Parallel Condition records can be used.
In the methods of the Any-to-Any machine, hierarchical space saving mechanisms
such as nested 'If Then Else' are One-to-Many mechanisms and are not used in
the Any-to-
Any machine at all, because these quickly become extremely complex - hence
failure- prone
- and it is not possible to be sure if the Condition statement will somehow be
met under an
unpredicted combination of circumstances. Hence, when a Condition is to be
stated, it is
stated as a independent Condition, in its entirety, leaving nothing out, using
as many
Condition records as needed. If needed the Condition Records are grouped
together. Then
the - potentially grouped - Condition Records are related to one or many
Executions specified
476
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
by Director Records that can also be grouped if necessary and related, as a
group to the
grouped Condition Records. When many different Conditions are to be stated
these are each
stated in full, per this method. The final 'else' statement - i.e. the
Execution to be done if
none of the Conditions are met - is itself treated as a Condition stated as
above. (Final 'else'
statements - i.e. the Execution to be performed if no Conditions are met, is
also a source of
error. Complex Conditions, stated in the state of the art hierarchical manner,
can be thought
to cover all circumstances, and hence, a final 'else' Execution can be
specified. In fact, this
method states that the Execution stated should be done under every other
Condition
imaginable and this is an incomprehensibly broad statement. Stated
colloquially, this
mechanism is equivalent to 'If someone comes into the camp and gives the
password, Then,
open the door, else, shoot him.' The 'else' may be correct most of the time
but circumstances
programmers have not predicted do occur, as when the Commanding General
appears at the
door and has forgotten the password. A computer would shoot him, but a person
would not,
and in fact humans do not use the 'if, then, else' mechanism. The human
mechanism ig close
to 'if-then; if-then; if-then; evaluate the situation', with 'evaluate the
situation' being the final
Execution if none of the Conditions are met. The If-then statements are
parallel and directly
accessible and not hierarchical. Hence the Any-to-Any machine copies the more
human
version.
There are two main uses for Conditional Interface Controls:
1. Pre-emptive input actions. During data entry, situations can arise that
require emergency actions - such as the example previously described, or
alternative
actions, or user alerts. While the Data Relation Table works in Numbers
Language, a
Visual Interface is working in a Spoken Concept Language - since the field
into which
it is entered selects the meaning of a word - and the word thereby transformed
into a
Concept Language component. Suitably written Conditional Interface Controls
can
prevent the entry into the Data Relation Table of potentially destructive or
undesirable
commands or check whether a user is entering a value by accident if the value
appears to be wrong, or redirect the value. Conditional Interface Control can
provide
the surest form of filter by preventing display of the entirety of data that
should not be
seen; for example, parents by creating suitable Interface Control Condition
records
can completely prevent display of any site they consider undesirable for their
children.
2. Output designation Actions. Conditional Interface Control can be used,
for example, to print certain types of item to one printer and other types of
output to
another printer. Any Table Parallel Condition record states combinations of
Components. Hence such a records can state any combination of Components in
the
output, for example, to detect if the output contains graphics and the
Condition record
477
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
can then be used to call a Software Module that changes the Active Device
Setting
Record in use in the User Master View Print Module, resulting in that output
being
directed to a graphics printer. Extending this principle leads to the ability
to execute
orders such as 'Print this for Joe' - when Joe is in another country -
provided that the
application has a manner to reach the corresponding Data Relation Table on
Joe's
machine. In such a case, the Condition Record re-directs the output to a
Transmit
Module, which sends the appropriate Data Relation Table records and Data Class
values to the distant machine, with the Output Device field stating a code
that is the
code for the default printer. The same principle can also be used to display
something
on a distance machine ' Show this to Joe'.
3. Attention drawing Actions such as turning text red, or enlarging an
Active Element - even to the extent of filling the screen - and making it spin
if the data
it displays or receives meets the stated Conditions.
While Interface Control Conditions themselves apply to the data, the
associated
Execution applies - at least in part - to the Visual aspects of the interface
and therefore, can
be used to change any Interface Control or combination of Interface Controls.
Hence, when
an Interface control Condition is met, the Parallel field of the Companion
Director record calls
a Software Module that performs the desired action. Additionally, an
Associated Field Parallel
Condition Specification record can be used to state the interface Control
Record values - ar
other values - that the Module specified in the Director record field should
place in the
Interface Control record fields to be changed. Any data record can be as a
Condition
Specification - for example, a screen message such as the one given in the
example above
of a medical diagnostic system.
HEADERS, FOOTERS, FOOT NOTES, ENDNOTES, TABLES OF CONTENTS, DOCUMENT
INDEXES, ATTACHMENTS
Headers, Footers, Footnotes and Endnotes are termed 'Additions' and are
treated in
the Any-to-Any machine, as user data items in their own right and a Sub-View
that is to be
periodically inserted in specific places when specific Conditions are met.
Hence, Headers,
Footers and Endnotes are created in Sub-Views that provide the user with a
choice of rule as
to where they are to be inserted. Because of the nature of the Any-to-Any
machine, the
programmer can easily provide a Sub-View that allows the user to create any
number of
Headers and Footers and designate the pages to which they apply so that they
can be
different on every page if required. There is no limit to the number of
Additions that can be
used on a page.
Footnotes and Endnotes require an Active Element in the text to display their
Number,
while the number that appears in the Foot Note or End Note is part of the Foot
Note or End
478
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Note Itself. Effective Footnotes and Endnotes are easier to manage when the
Content is
prepared with a Ful1 Language Processor.
The programmer should create an Additions Data Class Table that allows all
such
items, once created as their own Data Relation Table records, to be listed,
together with their
type name. Then, when the user wishes to add one or more Header, Footer, Foot
Note or
End Note, he can be provided with a list of those that exist and choose what
he wants.
Additions are created by appropriate Modules that use Sub-Views, which are
assigned priority
over available space. If the programmer provides a suitable Module and
associated Active
Element Button, they can be turned off in User Master Screen Views - so that
they exist, but
do not display, thereby saving space - while remaining in effect when printed
and in any User
Master print View display that is also output to the screen.
Tables of Contents and Indexes are also Additions, but are Additions that
prepared by
Modules following user parameters. Tables of Contents require users to
designate divisions
within the data, and Indexes require the user to designate items to be indexed
- one simple
method of doing this s to advise the user to designate all items to include in
the index by
Stating Them With Capital First Letters.
Attachments are similar to other Additions, in that they are items in their
own right, but
with the difference that the rules followed by the Attachment Module outputs
them as
separate items and not as part of the item itself. When attachments are shown
in a Visual
interface, they are presented as an Active Element that displays the title of
the item as its
Label, and when clicked, the Module associated with the Active Element turns
on the View for
the item, thereby displaying it.
- Method for using Interface Control Records to Control the Interface
INSERTION AND DELETION
The deletion of an interface Element such as an Active Element has already
been
described under the heading of Connect To records. Replacement of one
Interface Element
with another requires two Executions;
1. Deleting the Execution Record Number for the Interface Element to be
removed, from the Active Interface Element record.
2. Insertion of the Execution Record Number of the Interface Element that
is to replace the deleted Interface Element, in such a manner that the
Coordinate Set
used by the deleted Active Element is used by the replacing Interface Element.
Hence, the insertion, in the case of a Replacement, involves replacing the
number of
the Execution Record of the Interface Element that is to be removed, with the
number
of the Execution Record that is to replace it. The Connect To record requires
no
change. Normally, aII Associated Record values in that field should be
replaced also.
479
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The result is that any Interface Elements that had a Connect To value placing
them at
a certain relative Coordinate to the removed Interface Element, will maintain
the same
spacing with the replacing Interface Element. A Replace Interface Element
Software
Module handles replacement of one Interface Element by another.
3. Inserting an Interface Element between two other Interface Elements
requires replacing the existing Connect To record with a new Connect To
record, and
is handled by an Insert Element Module. In effect, all field values in the
Connect To
record to the right of the insertion point, should be written one field to the
right of their
previous position (assuming that the Connect To record data fields are being
used
from left to right). At the same time:
- The Connect To field value corresponding to the first of old Interface
Elements that has been displaced and is being written one field to the right
of its
original position, is copied into the Connect To field corresponding to the
new
Interface Element. The result of this is that new Interface Element preserves
the
same relationship with the Interface Element to which it is now connected, as
the
displaced Interface Element had to its original partner. At the same time the
displaced Interface Element has the same spatial relationship to the newcomer
that it did to the Interface Element to which it was previously connected.
- A new Interface Element - such as an Active Element - that is inserted
in this manner, does not intrinsically have any Interface Control field values
or any
other Active Interface Module Associated values. The programmer has two
options to handle this;
- If the Interface Elements between which the new Interface Element is
inserted both have the same values in their Associated record fields, then
these
values can safely be used - i.e. copied into - the corresponding fields of the
same
records for the new Interface Element.
- Alternatively, an Interface Control Data Assembly Table record can be
used.
- This principle can be taken further. The Active Element can include a
Condition to test for the data type it has been given to display and based on
this,
select an appropriate Interface Control Data Assembly Table record to use.
However, this requires the Interface Control Data Assembly table to have a
field in
which can be stated code numbers for the data type for which that records is
suitable. This method gives the programmer the option to make the data chosen
for display designate the Interface Control settings to be used by the
Interface
Element - such as the Active Element - used to display the data. Equally, the
48~
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
option also exists to enable the data itself to choose the Interface Element
to
display it, together with its Associated record field values - this option
will be
described shortly.
METHOD TO CHANGE INTERFACE CONTROLS
In order to change Interface Control Records using a Visual Interface,
Interface
Controls need to have a Sub-View that enables them to be changed. Such a Sub-
View can
be created using Active Elements in a tabular arrangement displaying labels
for particular
fields in the Interface Control Data Assembly Table and - and values from any
other tables -
containing user-modifiable values for any other Active Interface Element
Associated Records.
The Values that can be changed in such an Interface Control Sub-View can also
be
accessed directly by a user's order given with a Language Processor, or, in a
Visual Interface,
by (right) clicking on the item concerned to display the required Interface
Control Sub-View.
Using a Visual Interface:
1. When the user wants to change a single Interface Element, right
clicking on it displays the Interface Control Sub-View and enables him to
change
whichever values he wishes. The Interface Control Sub-View contains buttons
allowing the user to select whether the change applies to the data, to the
Interface
Element, or to both.
2. An unobtrusive Active Element exists in each Interface Element except
an Active Element labeled 'Change Appearance' or similar. Clicking this,
enables the
user to change everything in the Interface Element simultaneously if he wishes
to.
(Alternatively, the user can select any number of Interface Elements using a
mouse
and right clicking).
3. The effect of the selection is first to display the Interface Control Sub-
View and secondly - as on all occasions when a selection of more than one item
is
made - either with the Mouse or in this case by using a Change Appearance
Active
Element button - an appropriate Software Module is activated, in this case a
'Change
Appearance Module'. The first action of such a Module is to open a 'Selection
record'
in which the fields so far selected by the user are already marked, and the
second
action is to call an Active Element button labeled 'Mark Exceptions' enabling
the user
to exclude items from the selection. As soon as the Mark Exceptions button is
pressed, its label changes to 'Done Marking Exceptions'; as long as it
pressed, any
Interface Element that is clicked is removed from the Selection record.
Removals
finish when the user clicks 'Done Marking Exceptions' - upon which the
button's label
reverts to 'Mark Exceptions' so that the user can mark some more exceptions if
he
wishes to.
481
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
4. When the user uses the Interface Control Sub-View to change any
available values, the changes are applied to those Interface Elements marked
in the
Selection Record.
5. The general procedure of the change - and all similar changes - is that
the Interface Control record to be changed is first copied -giving it a new
and higher
record number - and the record from which it was copied is marked 'Inactive'
in the
Active Administration field. The new copy is changed in the manner the user
dictates,
copied into memory and used, while the record that is now inactive, is removed
from
memory and saved.
6. In this manner, if the user wishes to revert the change he just made,
the 'inactive' record exists with which to do so.
The above procedure can be used when individual Interface Control records are
used.
When a single Interface Control record is used, containing the reference
numbers of
Interface Control Data Assembly Table records, the procedure is similar but
more complex,
as new Interface Control Table records may need to be written before they can
be used.
By assigning different Interface Controls to the different Interface Elements -
such as
Active Elements - that are in use, virtually unlimited combinations of
Interface behaviors can
be created. The programmer supplying the user the initial screens for an
application,
chooses Interface Controls that are suited to the particular data that will be
input and output
by his application. Thereafter, the user may change them as he wishes.
METHOD TO MAINTAIN THE UNLIMITED NATURE OF AN ANY-TO-ANY VISUAL INTERFACE
User Attention, Data Relation Table Record Type
A further parameter required to calculate the space and position that each
Interface
Element should occupy on the screen is the parameter of what the user wants to
see - i.e.
where he has his attention on the screen, and the User Attention Record type
records this.
In the state of the art, difficulties are continuously created for the less
experienced and
less educated user, when screens he is looking at and working on, vanish
without explanation
when he does something. If the user is working in a word processor for
example, and opens
a spreadsheet, the word processing window is likely to disappear, leaving him
puzzled and
uncertain. He has no instinctive way of knowing that his word processing
window is actually
being represented by an icon at the side of the screen that bears no visual
resemblance to his
word processing window. This method of placing more things in a given space is
not one that
is found in real life, where the more usual analogy is to squeeze things
together into a given
space, but without changing the appearance of the squeezed items, so that the
squeezed and
unsqueezed item are visually related - i.e. they look like one another. When
many items are
placed in a cupboard, for example, the user knows that the cupboard has a
depth - he can
482
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
see that by looking at the cupboard sides where the side is not hidden by
items. When he
moves items aside to see what may be behind the items in front, whatever he
sees there
presents its normal, recognizable visual appearance, which is unchanged from
its un-stored
visual appearance.
Hence, in order to emulate the working methods that a human is used to, and
not
require him to learn new ones, when screen space is short, items that are not
immediately
essential need to be able to be squeezed - i.e. reduced in size without
otherwise changing
their appearance - as per the Interface Controls, Movements, previously
described.
Further, in the state of the art, a user wishing to see two windows at the
same time - a
word processing window and a spreadsheet window for example - should take
multiple steps
in order to create such an arrangement. User intervention is not only
required, but the
Windows cannot be seen without user intervention, and since their controls are
buried deeply
within the hierarchical structure of the operating system itself, direct, non-
hierarchical access
to them is hardly practical. The user, in addition to learning the necessary
steps to change
Window dimensions in the first place, also should execute those steps each
time he wants
that particular arrangement.
In order to offload this problem from the user, the interface needs firstly to
be able to
detect what the user wants to look at, and then, secondly, to adjust the
windows (Views) so
that the user can see what he wants to see at the same time. Some methods have
already
been described enabling the size of Interface Elements to be squeezed and
expanded.
Additionally, methods exist enabling the computer to detect where on the
screen the user has
his attention - mouse; user order, or with head movement detectors that are
available in the
state of the art using a camera on top of the screen, for example.
If it is known where the user's attention lies then the fact that the user
wants to see
something he is looking at - at least at the Minimum Standard Size - is
already known.
Because the user's requirement is already known it is unnecessary to make the
user perform
the additional task of re-sizing the window to a visible size (the Minimum
Standard Size) - a
task that the computer can do itself. If a user moves his attention between
(between
'Windows') then it is obvious that the user would prefer, if possible, to be
able to see both of
them at once, and again, this is something that the computer can be made to
arrange without
requiring unnecessary User Intervention to do so.
An ability of the computer to arrange View layouts itself becomes particularly
useful
when a user issues the more complex orders that are possible with a Language
Processor.
When a Language Processor is in use, a user may give an order such as the
following: 'Show
me E-mail Specification X from Joe (which is one View) and also show me Joe's
account at
483
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the same time (which is another View).' Such an order requires the ability
(described in state
of the art terminology) to:
1. Squeeze those Views ('windows') are on the screen now without User
I nterrention
2. Display both named Views ('Windows') at least at Minimum Standard
Size without User Intervention
The Data Relation Table User Attention Record type is one part of the methods
to
enable a computer to arrange Views without requiring user intervention, and
enables an
Interface Software Module to keep a running record of where the user's
attention is and what
part of the display for which it is responsible needs priority allocation of
available space and
what part does not.
A User Attention record is a Sequence type Data Relation Table record whose
Execution Record Controller Logic continuously records in its field the number
of the
Execution Record of the Software Sub-View Module that is receiving the user's
attention each
time the user changes to a new screen area. As soon as the user places his
attention on a
different Interface Element, the number of the Execution Record of the
Interface Element on
which the user has his attention is written into the next available data field
in the User
Attention record. When all free fields are used, the writing continues,
beginning again at the
first data field. This type of Sequence Record is termed a Circular Sequence
record, as it is
used as though it were a loop, with the last data field of the record joined
logically to the first
data field.
The User Master View Interface Element, has a User Attention Record,
in which are recorded the number of Execution Records for all the Interface
Elements
it directly controls (this means, any Active Elements it controls itself, plus
any Sub-
Views it controls itself, plus the Views it controls).
2. Each View Interface Element, has a User Attention Record, in which
are recorded the number of Execution Records for all the Interface Elements it
directly
controls (this means, any Active Elements' it controls itself, plus the Sub-
Views it
controls itself).
3. Each Sub-View Interface Element, has a User Attention Record, in
which are recorded the number of Execution Record for all the Active Elements
it
directly controls. (Normally, User Attention records are not so desirable
within a Sub-
View. Their main use is to enable Views and Sub-Views to be balanced
correctly, and
there is normally little need to know which Active Element is getting
attention, unless
that Active Element is displaying its label below minimum Standard Size).
484
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Because of this method of the Any-to-Any machine, each senior Interface
Element
above the level of an Active Element has a User Attention Records that is a
continuous record
of where the user is placing his attention on the screen, and this continuous
record can be
used by the Interface Elements to decide which of its junior Interface
Elements should be
given priority of screen space when there is a shortage of space, as follows:
1. The User Master View can use this User Attention Record to find out
which View is getting the user's attention now, and which View got the user's
attention
last, and this gives it the information it needs to assign space on a priority
basis to
those Views.
2. A View Interface Element can use its User Attention Record to find out
which of its Sub-Views is getting the user's attention now, and which of its
Sub-Views
got the user's attention last, and this gives it the information it needs to
assign space
on a priority bases to those Sub-Views.
3. A Sub-View Interface Element can use this record to find out which
Active Element is getting the user's attention now, and which of its Active
Element got
the user's attention last, and this gives it the information it needs to
assign space on a
priority bases to those Active Elements.
The next method that forms part of a Visual Interface ability to adjust itself
as needed
is a Request Space record.
- Request Space Record Type
While the spatial arrangements of the data from different Data Relation Table
fields
that make up printed output tend to be relatively fixed in a particular
position where the user
wants individual items to appear, a screen - analogous to a desk - needs to be
far more
mobile and flexible, and to be able to accommodate at any one time far more
data than a
person would print on a single sheet of paper. Additionally a screen is one of
the few
input/output devices where input and output are can be occurring in different
parts at
approximately the same time. Request Space records are a further part of the
method to
provide for this mobility and flexibility requirement
While a user may have a considerable number of things on the screen at any one
time, he only has his attention on one, two, or a few places on the screen at
one time. When
he has his attention on a particular area of the screen, that area needs to
display at a size
large enough for him to see it comfortably i.e. at least at the Minimum
Standard Size, while
other areas on which he does not have his attention can be reduced below the
Minimum
Standard Size, without causing him a problem but with the advantage of still
being
recognizable for him.
485
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Request Space records are used by a junior Interface Module to state to a
senior
Interface Module the amount of space they require - without stating where that
space is to be
- in order to display their data at the Minimum Standard Size. While Request
Records contain
Coordinate Sets like Grid Record, unlike Grid Records, Request Records are not
used in
pairs, but singly and the difference arises in the manner in which Request
Records are used
by the Field Logics of the Execution Record that uses the Request Record.
Grid Records state two Coordinate Sets, which the junior Interface Module uses
to
calculate the physical position an Interface Element is to occupy in the
device output.
Request Space records on the other hand, simply request an area without
requesting that
that area be in any particular position. Request Records request an area in
terms of
Coordinate Sets, but the senior Interface Module does not further relate these
Coordinate
Sets to be referring to any particular position on the screen. Because a
Request Space
record does not refer to any particular area of the output device - such as a
screen - the Start
Coordinate Set is assumed to be position 1 Horizontally and position 1
Vertically and
therefore does not need to be specifically stated, as this assumption is
included in the senior
Interface Element Logic. Hence, only the End Coordinate Set is required, and
consequently
only one Request Record is needed, and is in fact, the equivalent of an End
Grid Record.
The Request Record acts to state a specific surface area of available output
that it requires to
use, without specifying where that area is to be.
A Request Area Data Relation Table record type is a Data Relation Table record
belonging to a senior Interface Element and is an Active Interface Module
Associated record,
and therefore shows Field Parallelism with the Active Interface Module Record
in use by the
Interface Module to which it belongs. Each of the Senior Interface Module's
junior Interface
Elements - such as an Active Element- write the End Coordinate Set of the area
it requests -
calculated on the basis of the Minimum Standard Size - into its field in its
senior Interface
Module's Request Record.
However, using the methods of the Any-to-Any machine, in many cases more than
one possible arrangement and layout of Active Elements in a Sub-View may be
possible, and
consequently, the dimensions of the area required to display these layouts and
arrangements
will be different in each case. Consequently also, taking into account the
other areas that
also need to be displayed, one or other of these different area dimensions may
be a better
overall fit than another, and therefore be preferable to the others.
Therefore, a programmer
who wishes to make a screen display as adaptable as possible should provide
for and use
more than one Request Record, each one of which states an alternative area
being
requested. Such Request Records can also used to state the area required with
and without
486
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
space-reduction mechanisms such as Allowed Positions, Abbreviation Exchange,
and
Movements. -
The programmer can either include the logic for calculating Request Space in
the
interface Modules Field Logics, or create a subsidiary Execution Record for
the Interface
Module that has the sole purpose of calculating Request Space. The programmer
can
provide for as many Request Space Records as he wishes, but some useful sub-
types of
Request Space records could be Request Size based on: Minimum Size only,
Minimum Size
using Abbreviations, Minimum Size using Abbreviations and Allowed Positions,
Minimum Size
using Abbreviations, Allowed Positions and Interface Controls.
- Method to Calculate the Layout for a Given Display
Alternatively, a User Master View can mark a Device Setting Record, still in
the Device
Setting table, as 'Active', but then, all Interface Elements need to be
written to refer to the
Device Setting Table for the Active record. This can become complex if several
users are
active on the same machine, and hence, is not the preferred method. In the
same manner
that one of the methods that makes this Any-to-Any machine possible, is to
translate all data
into a common language - Numbers Language - the general method is that when
any data is
assembled by a table outside of the Data Relation Table, and when this data
needs to be
accessed, it is converted into a common format - a Data Relation Table in
memory - by a
Converter Module. With this method, all Software Modules (except Converter
Modules and
Translator Modules) only have to look in one place for their data - i.e. in
memory. If this
method is followed, every Software Module will be able to manipulate all data
that it is
possible for that particular Logic combination to manipulate.
An Interface Module calculates its Requested Area in terms of dimensions
within the
total real space available using the Device Setting Record that is marked as
'Active' in its
Active field. (This record contains the actual real dimensions of a single
unit of display such
as a full screen or a printed page). The User Master View Module can be
written to copy the
Active Device Setting Record it is using into memory. In this case, it can
also copy several
such records into memory and change between them by removing the 'Active'
marking from
the 'Active' field of one record, and placing an 'Active' marking in the
'Active field of another
record. In this manner, it can change between screen resolutions, or a User
Master Print
View can change between any of a large number of printers.
Individual Active Element Field Logics have the following data available with
which to
calculate alternate Request Spaces:
1. The size at which the data itself needs to be displayed without
compromising readability. An Active Element, for example, can calculate the
area it
requires, based on the data that it is displaying and the Minimum Size Table
record for
487
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
that data. Thus, the word 'and' displayed at the Minimum Standard Size in a
particular
resolution can be calculated to require a space of A pixels by B pixels. The
Active
Element Field Logic can write this information into 'its' Parallel Field in
the Request
Record of its senior Interface Element. When it does so it is assumed that the
starting
point for the area it requires, expressed in terms of real space is (for
example) Pixel 1
(i.e. position 1 Horizontally and Position 1 Vertically) and the end of the
area it
requests is a Coordinate Set that is expressed as being displaced X pixels
horizontally
and Y positions Vertically. (Any convenient notation can be used, but it is
desirable
that all such notations are stated in a 'Conventions' table that states, for
incoming
Software Modules and applications, the conventions that are in use, so that
they can
convert themselves to these conventions on arrival).
Any more senior Interface Element - a Sub-View, a View, or the User Master
View
has more elements available to calculate Request Space:
2. The area in pixels each of its junior Interface Elements requires in order
to display its data at Minimum Standard Size. This data is contained in its
Request
Space records) and can potentially exist as two records, one showing space
with
Abbreviation Exchange and one showing it without.
3. How each one of its Interface Elements is presently connected to the
other - i.e. what is it spatial relationship to one other Active Element. This
data is
contained in the Active Element's Connect To Record.
4. Alternate Positions that are allowed for each of its Interface Elements.
This data is contained in the Active Element's Allowed Position Record.
Each Interface Element calculates its Request Space in turn, and writes this
to its
senior Interface Module Request Records.
Hence, the User Master View for a screen, has available the following data:
Which of its juniors has most recently received the user's attention - in
its User Attention record and this is its prime input in allocating space. Any
junior
Interface Elementls on which the user now has attention automatically receives
its
Requested Allocation if at all possible.
2. Junior Interface Element's where the user has had his attention recently
are next in order to of priority to receive an allocation of space, most
normally
receiving their smallest Request Space if possible.
User Master View Logic require sophisticated algorithms - that are nonetheless
well
within the state of the art to create - to work out optimum methods of
displaying the screen.
The general principles and objectives of such algorithms provide the largest
proportion of
space to the places where the user has his attention, but allocates some space
to the
488
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
remaining items. When space is really short, a User Master View for the screen
uses second
and further screens, exactly as a printer provides more than one page.
Keyboards adapted to
the Any-to-Any machine can provide a Screen Down / Screen Up button to make
this easier
to use, as opposed to Page Up /Page Down that, by convention, works within a
document
only. The Screen Up /Down mechanism of the Any-to-Any machine also provides
the
opportunity for a user to have available two or more screens, each with
different combinations
of work - one containing his current work and another showing his Battle
Manager (a view
giving an overview of all he should do that day, showing all incoming data and
messages etc).
Clearly the algorithm in use does not make unnecessary changes and equally
uses
margins of tolerance in order to ensure the screen is not continually changing
a movie and
thereby confuse the user. Equally, sudden switch-like transitions are
confusing especially for
the less experienced users, and therefore, one method is to use a Timing
Record to set the
speed at which changes occur. Such timing can be chosen by the user at
installation by
providing him with examples, and thereafter changed by him if required, using
a Sub-View.
As a result of the User Master View Logic calculations, each Junior Interface
Element
receives an allocation of a specific space, stated in its senior Interface
Elements Grid
Records and then uses these Grid Records to display itself in its allocated
position and area,
and calculates - in a manner similar to the User Master View Module's
calculations - the
space to assign to each of its juniors. Hence, priority is given to those of
its juniors on which
the user's attention was most recently recorded in its User Attention record.
In order to
reduce itself to the space which it has been allocated, the programmer needs
to set priorities
as to which mechanisms should be used for the juniors that have no priority -
such as
Movements, reducing below Minimum Standard Size etc.
The decision algorithms used should result in at least a single Active Element
of the
original Sub-View remaining visible, and displaying sufficiently for the user
to be able to
recognize it.
While these mechanisms provide the basic methods that can be used to enable
the
data and the application to control its own display in a manner useful to the
user, none of
them prevent the user controlling any of these himself if he wishes to do so.
The user can do
this either with a mouse in a conventional manner, or with a Language
Processor giving such
commands as 'Make this much larger/ smaller', 'move this left and up' etc.
Such user orders
result in the appropriate Request Space record receiving a code number that
states that the
request is a User Request and such a user Request Space is treated by
Interface Element
Logics as having priority over any Interface Element Request.
When a change in allocation is made, the Grid records to be changed are first
copied,
the older ones marked as inactive and the newer copy marked as active and then
changed.
489
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
In this manner the previous arrangements are available for the user to return
to the previous
display if required.
Clearly, the number of variables that can affect the area required for display
by any
given data that can be accommodated by the Any-to-Any machine, and the number
of
possible combinations that are possible can become very large. However, ,some
reduction
occurs as not all Display Variables are applicable to all data, and unless the
programmer
intends the application for a powerful machine, or one that provides hardware
specially
adapted to the Any-to-Any machine, the programmer should consider severely
restricting the
number of possible Display Variables that can be applied to any given data. It
is envisaged
for example, that a programmer might provide for a Sub-View that is a menu bar
to turn flat,
and reverse that behavior when the cursor approaches it and then also provide
in the
Interface Control concerning the Sub-View that the menu bar sub-view may
overlay another
View or Sub-View. Additionally, the programmer might provide for abbreviation
of names of
people and companies, and dates, but perhaps, for little else.
The programmer should establish a scheme of priority on which these different
possibilities will be used as space becomes short, and can effectively state
his preference in
the resulting Request Record using the Data Relation Table Administration
Field 'Marking
Number'
- Methods to Ensure the Interface Remains Unlimited
One for the key parts of the definition for an Any-to-Any construction is the
phrase 'not
intrinsically limited'. For example, supposing that a user wishes to record a
large number of
telephone numbers for a specific person - 30 for example - there is no
intrinsic limit in the
Data Relation Table to the number of telephone numbers that can be recorded
for an
individual. However, if the interface can only display three phone numbers
that it is not an
Any-to-Any machine and cannot accommodate the Any-to-Any Data Relation Table
mechanisms. Therefore, in order to maintain the interface as an Any-to-Any
machine,
whenever a user enters data into data entry Active Elements, and that box is
'used', another
box opens - i.e. Another Active Element - allowing the user to enter another
one of that
thing.
A Programmer Software Module type called 'Add Another, that is an Associated
Record that is Field Parallel with the Active Interface Record, is generally
part of every Sub-
View in which data entry occurs. The Add Another Module type makes a copy of
the Active
Element that is receiving data entry, and inserts the copy into the Sub-View
in a manner that
is specified initially by the Programmer using an Add Another Position record,
that is a
Coordinate Set record similar to an Allowed Position Record. Add Another
Modules also
490
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
open a New Record to accommodate the new data if the user enters data in the
new Active
Element data entry area and group the record appropriately with the remainder.
The actions that an Add Another Module should do vary greatly depend on the
exact
Data Class Concerned. While there is usually no required to add a second date
to a letter,
there can be a requirement to add a second or third signatory. When a document
such as a
letter is created, and Add Another is used and allowed on the addressee name
field the effect
of Add Another is to create a complete duplicate of the entire document and in
effect, both
documents are done at the same time.
The general term for these methods is the 'Add Another'.
Extensions of the Add Another method allow a single document to be created
which
goes to one person by e-mail, to another by post, to another by fax, each with
their own
attachments, Confidentialities, CCs, Via-s, etc.
The ability of the Interface previously described, to calculate the space it
requires
becomes desirable when Add Another is implemented, as the Visual display can
then adjust
to the amount of data it should display.
- Sort, Sort Order, Filters and Operators
In this Any-to-Any machine:
1. Sort is defined as the direction of the sort - Ascending or Descending
2. Sort order is defined as the order in which fields are sorted - which field
is sorted first, second, and third and so on.
3. Filters are defined as any user data value supplied by a user and used
to eliminate parts of the selected data. Examples would be 'Thursday' 'New
York'
'Last week'.
4. Operators are defined as set values that modify or join filters, and are
divided into three types, termed Type 1, 2, and 4 Operators.
5. Sort, Sort Order, Filters and Operators can be combined in any
combination the user chooses. The combination of any number of any of these
that is
applied to a single Data Relation table field is termed a 'Filter Set.'
Any Filter Set can be applied to any Data Relation Table field. In a Multi-Sub-
View
display - a tabular display - every column can have its own Filter Set.
A Filter Set is an integral part of how a given user looks at any particular
data and is
therefore part of any Multi-Sub-View where the Find results in more than one
item being
found.
In this Any-to-Any machine, Operators are of three types, and are held in an
Operator
Data Class Table as follows that contains a field in which their type can be
stated:
Type 1 And
491
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Or
Not
Nor (Xor - It can be neither this, Nor that)
Type 2 Is
Is approximately
Is near to
Quite 'It is quite blue'
Almost
WithinX%of
Type 3 Equal to
Greater Than
Less Than
Larger or Greater than or equal to
Less or Smaller than or equal to
Empty
Lowest
Highest
Begins with
End with
Contains
One method is as follows:
1. 'Find' is one of the two most frequent operation done by the Any-to-Any
machine - every user order of any type begins with at least a) Opening a new
Record
to record the order and b) Finding - at least - the Software Module to do the
order.
(As described, in a Visual Interface each User Software Module can be
represented
by its own Active Interface Button).
2. Because of this, more than one 'Find' is created. While the Execution
record is the same for each of the different 'Finds', the difference is that
the New
Record that is created to record the order and hence record the Specification
for the
Find, is tailored to the specific type of Find that is to be done. This is
done as follows:
a. Each Specific Find Module has its own Specification record that
contains the values used to select Data Relation Table records and groups of
records of that particular type. For example, an 'Address Find' Specification
Record contains the values that, when used in the Data Relation Table query,
will result in only 'Addresses' being found. If the user enters no further
values,
492
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the result of the Find is to find all 'Addresses'. If the user enters values,
this
act to limit the scope of the addresses that are found.
b. When a Specific Find is started, it copies its Specification record
values into the new Record, and presents to the user a suitable selection of
the
unused fields not yet containing any Specification through a Sub-View. If the
user enters no further values, then the Specific Find finds all entries of
that
type - for example, all addresses. If the user enters a further Specification
into
the fields in the Sub-View - for example the value 'Joe' into the First Name
field, then that value is placed in the New Record and consequently, the
Specific Find finds all addresses concerning anyone with the First Name of
Joe.
c. A Non-Specific Find exists, which has no Specification Record
at all, and hence this - overall - Find if executed with adding any further
Specification, finds every record in the Data Relation Table.
Any user-started Find operation that is known in advance to be expected to
produce
more than one item, or any user-started Find operation that does produce more
than one
item, can require the service of a Filter Set, and in a Visual Interface, this
should be available.
Equally, if the Find operation only finds one item, no Filter Set is required.
Hence, Filter Sets are included in Sub-Views for all Find operations. A Find
consists
at first of a Sub-View that enables the user to enter the Specification that
he wants. The user
can choose either for the Find to execute as soon as the first Specification
value is entered -
in which case the initial result is invariably that more than one item is
found - or for the Find to
execute when the user tells it to, and thereafter re-execute whenever he
changes any Find
Specification value. In the latter case, only one item may be found and a
Filter Set is
undesirable.
fn either case, a Filter Set Sub-View - a Sub-View that enables the user to
enter any
components for a Filter Set - needs to be available as part of the Sub-View to
enter the Find
Specification, but can be removed if only one item is required
The number of Components in a Filter Set should comply with the Unlimited
Principle,
and should not limit the user in any manner in which he does not limit
himself. Filters and
Operators are used in pairs, and hence, per the method just described, as one
pair of Active
Elements permitting Filter and Operator entry start receiving data from the
user, another pair
is opened by a suitable Add Another Module. When data entry finishes, in order
to reduce
space, all except the first pair can be hidden by an Interface Control
Behavior, and re-opened
if the cursor moves near them or a Language Processor order is given to do so.
493
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The user's can enter Sort, Sort Order, Filter and Operator Specifications for
any and
every Data Relation Table field.
A Find operation begins with the creation of a New Record and this new Record
receives the Data Class values that the user wants found; this record is
termed the Find
Specification data record.
Filters - i.e. Data Class Values are entered by the user - are recorded as
Data
Specification record type, Find Specification Sub-Type, Filter Record Sub-Sub-
Type and each
such record can be accompanied by Field Parallel record containing any
combination of
Operators. Equally, the programmer can provide that all operators are combined
in one
Operator Record as a Combined Number, including coding for which part of the
number
applies to which filter record. Filter Records are numbered as 1S', 2nd, etc,
in their Marking
Number Administration Field.
Filter and Operator records are grouped together by the Find Module Field
Logics,
using the grouping methods for the Any-to-Any machine that will be described.
93) Method to Select 'Screens' Using Visual Interface
A particular 'screen' - i.e. a User Master View Record displaying a particular
combination of Views and Sub-Views - is stated by a particular Active
Interface Module
record that is designated (in its User Number field) as belonging to the same
user as the user
number in the User Number field of the User Master View Execution Record. In
other words,
a particular user, with his own specific User Number, has a particular User
Master View
Interface Module, which can have an unlimited number of Active Interface
Module Records
(however, only one of these at a time is marked as 'Active' in its 'Active'
Data Relation Table
field). As previously described, a User Active Interface Module record states
the Execution
record number of the - junior - View Interface Modules it contains and
controls; each of these
junior Interface Modules has its own Active Interface Module record stating
the Sub-Views it
contains and controls, and each Sub-View has its own Active Interface Module
record that
states the Active Elements it contains and controls. Hence, designating a
particular User
Master View Active Interface Module record as 'active' effectively designates
a particular
entire screen display.
3p STARTUP SCREEN SELECTION
When an application is started, the Field Logic of the User field of the
Controller
Interface Module calls the User IlD Software Module using a Token. The User
I/D Module,
User field, Field Logic checks the records in the Authorized User Data
Assembly Table for the
existence of any record containing a User Number in the User field, and
finding none, its
accompanying Condition / Director record pair have the effect of launching the
First Use
Module. While User IlD Module is identifying the user, the First Use Module
identifies all the
494
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
physical parameters it can about the machine - about the screen and the
printer and their
resolutions etc, writing the parameters it finds to the Device Setting Data
Assembly Table.
Since the User I/D Module did not find any Authorized User Data Assembly Table
record containing a User Number in the User field, a further Condition /
Director record paid
result in the User I/D Module launching the New User Module group.
The New User Module group consists of a series of Modules and screens that run
the
user through the equivalent of a 'Get Acquainted' session that a boss will
hold with a new
secretary to find out who he is and what he wants done. The New User Module:
1. Uses a very simple screen to find out the competence level of the user.
2. Based on the user competence level that is found the Module launches
one of several New User Modules each designed to be suitable for different
levels of
user competence, that:
a. Obtain the needed information from the user to create a User
Number and create a User Record and User Number
b. Enable the user to provide the needed information to create a
user identification record in the Authorized User data Assembly Table - this
is
the table whose records are normally used by the User 1/D Module to identify
users. This procedure includes choosing and recording the preferred method
to be used for User Identification, recording passwords for the user etc. This
2p procedure also includes choosing a normal start-up screen for the user from
those available, by recording in that User's record in the Authorized User
Table, the number of the Active interface Module Record containing the
numbers of the Execution record for View Collection of View Interface Modules
that is appropriate to that user's experience and abilities.
c. Additionally, the New User Module calls a Personality Choose
Module that enables the user to choose the Personality he wishes to use at
Startup, as described in description for the Personality field,
d. Record user preferences in the User Preference Data Assembly
Table. These various tables are described in more detail under the description
for Field 15, User field.
3. With these procedures complete, the New User Module returns a
Token to the User I/d Module stating it has completed and contains the record
number
of the new user's In the Authorized User Data Assembly table.
The User I/D Module sends Token with the User Number of the Authorized User on
to
the Controller Interface Module
495
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Controller Interface Module, queries the Authorized User Data Assembly
Table to
find the record containing User Number of the Authorized User and retrieves
the value it finds
in that record's View Specification field - this field records the Interface
Element Assembly in
use at user logoff. If the field contains an entry it activates that Interface
Assembly,
designating it as the User Master View. If the Item Specification field is
blank - i.e. the user
recorded at Logoff that he wanted to the machine to re-start with his default
screen - the
Controller Interface Module retrieves the value recorded in the Startup View
Specification -
this record reference number specifies the user's default User Master View -
i.e. his startup
screen.
Under normal circumstances, after the application has been started for the
first time
and is started again at another time, the appropriate Field Logic in the User
i/D Module
checks the records in the Authorized User Data Assembly Table for the
existence of any
record containing a User Number in the User field, and finding that there is
at least one, calls
its associated Sub-View, and uses that Sub-View and its procedures to identify
the user,
based on matching the user's input with records in the Authorized User Data
Assembly Table.
It either fails to identify the user, in which case it launches the New User
Module as already
described, or it does identify the user, in which case it launches the startup
User Master View
for that user, and, using a Token, gives the User Master View Module the
record number of
the Active Interface Module Record containing the Execution Record numbers for
View
Collection of View Interface Modules that it finds in that User's record in
the Authorized User
Table.
The User Master View uses the record numbers provided in this Active Interface
Record to activate the named Views. The View and Sub-View Interface Modules
that are
activated each contain their own Active Interface Module records, and in this
manner, the
user is presented with a screen - appropriate to his competence - from which
he can begin
using the computer. A user who has been identified in this manner, and for
whom a User
Master View has been started, is termed an Active User.
The computer Operating System is so arranged that the only connection between
a
user and all input devices - including removable disks, modems and network
cards - is via a
Controller Interface Module or a User Master View Module. Then, until a user
is identified, no
matter what input a person may attempt, the only Software Module that is
active is the User
I/D Module and the computer is effectively deaf to anything else. The
provision of a
Smartcard reader can be used to enable an Administrator to turn on any chosen
input device
during boot.
496
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
TRANSPARENT USER IDENTIFICATION
In order to follow the Any-to-Any machine method of avoiding user intervention
whenever at all possible, a transparent user recognition method is used, such
as Face
Recognition, Voice Recognition or the close presence of a particular badge or
several of
these at the same time. If such a transparent user recognition method is used,
then
Transparent User Recognition Software Modules are used and called by the User
I/D Module
to perform the User Identification using the hardware concerned. Thus the User
l/D Module
calls the Transparent User Recognition Modules if installed and if not calls
its own Sub-View;
equally, if Transparent User Recognition fails, the User I/D Module,
identifying this by means
of a Condition record, can activate the Software Module named in the
associated Director
Record and then terminate. The Director record starts a new instance of the
User I/D
Module, but its associated Specification Record contains a Token stating that
its Sub-View is
to be switched on - with the result that both Transparent User Recognition and
normal Sub-
View screen-based recognition are operating simultaneously.
A Transparent User Recognition Module runs permanently in the background and
checks frequently during times the machine is otherwise idle to ensure that
the logged-on
user is the same person that is using the machine, thereby providing
additional security. A
useful identification method is to use Face Recognition combined with Voice
Recognition, as
together, Face Recognition can be used to enable a computer to identify which
users are
present and thereby start User Masters Views for each of them preferably
before they are
actually ready to address the computer, and then, using Voice Recognition,
identify which of
the users is now speaking to the computer, and use this dynamic identification
to change to
the appropriate User Master View. These methods of the Any-to-Any machine,
combined
with a full Language Processor can be used to enable a computer to take orders
from, and
give User Messages (Labels, Prompts and Help) to several users in the same
time period,
swapping between them dynamically as desired.
If a Transparent User Recognition Module is running permanently in the
background,
and finds that the only person in front of the machine is a different person
to Active User,
then, in combination, the Controller Interface Module, User i/D Software
Module and
Transparent User Identification Modules:
Set aside the current screen by marking the Active User Master View
as Inactive, thereby effectively de-activating all input, as even if there is
input, there is
no active Interface Element Software Module to receive it - the effect is that
of a
person who has suddenly gone deaf. If required, the ability to turn the
display of any
Interface Element on or off can be used to bunk the screen also.
497
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2. Attempt to identify the person now in front of the computer and if
successful, activate that user's User Master View as it would for any
authorized user.
3. If they fail to identify the user, they can either continue to attempt to
identify an Authorized User, or activate the New User Module. A useful method
is that
once a first user has been registered for an application, in order to add any
other uses
to a machine - following normal human procedure - an introduction is required.
In
terms of the application, an 'introduction' means that, there are only two
ways to call a
New User Module:
a. If there is no Authorized user in the Authorized User Table, then
the Condition /Director record pair of the User I/D Module call the New User
Module. But if one or more Authorized User, exist they do not.
b. Hence, the only other way to call the New User Module is for an
Active User - who has therefore already been as an Authorized User - to call
the New User Module himself.
Hence, with these methods, including the use of a combination of recognition
methods
- with a minimum of two methods or two passwords being used together
unintended access
to an application is difficult.
In order for the user to preserve the screen that existed when a user logged
off - so
that when he logs on again the screen is reconstituted in its logoff state -
the following
method is used:
1. The Logoff Module activates Active Elements that allows the user to
toggle whether the screen on restart should be the screen he is presently
using, or the
standard starting screen he prefers - i.e. the User Master View Active
Interface
Module Record specified in the User Master View Active Interface Module Record
field
of that user's record in the Authorized user data Assembly Table.
2. If the user wants to start the next time with his default screen, the View
Specification Field Logic of the Logoff Module deletes any entry in the User
Master
View Active Interface Module Record field of that users record in the
Authorized User
Data Assembly Table, and the Data Specification Field Logic deletes any value
in the
Data Specification field.
3. If the user wants to start the next time using the screen that exists at
Logoff, the Logoff Module writes an View Specification Record for the User
Master
View, Views and Sub-Views in use - this is a record or records that
essentially specify
the full arrangement of Interface Elements in use for a single user.
Additionally it
writes a Data Specification Record for the data in use in Interface Element.
498
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
4. The Logoff Module writes the number of the View Specification Base
record it has just written into the Re-Start View Specification field of that
user's record
in the Authorized User Data Assembly Table, over-writing any value that is
already
there. Additionally, it's Data Specification Field Logic writes the Data
Specification
Base record number into the Re-Start Data Specification field. It's
Personality Field
Logic writes the Personality Number in use into the Re-Start Personality
Number field
of user's record in the Authorized User Data Assembly Table.
(Alternatively, the Logoff Module can copy the users record in the Authorized
User
Data Assembly Table, mark the old record Inactive in a Status field that
should then be
provided in the table, and enter the new values into the appropriate fields of
the new
record. This procedure, if accompanied by a suitable Software Module, can
enable users
to keep and use an unlimited selection of startup screens, or to return to and
use any
previous start-up screen).
5. The Logoff Module terminates the User Master View for that user, with
the result that the user concerned is can no longer enter data or orders and
is - in
state of the art parlance 'logged off.
INTERRUPTION
As previously mentioned, the ability to lay aside work in favor of more urgent
work is
also required. Interruption of Input or Output between humans is a normal part
of human
behavior - for example, one person interrupts another when he has not
understood
something being said, or a boss may interrupt a report from a secretary
because data of
greater urgency appears and he needs to give her an order, or ask her a
question concerning
something else. For a computer to emulate human behavior in this aspect
requires that
whenever Input is progress, Output is available, and whenever Output is in
progress, Input is
25' available, and this in addition to the ability to lay aside one partly-
given order, in favor of
another.
The screen is particular example of an environment in which continuous
interruption
may occur, and the construction methods for the Visual Interface outlined
above, enable any
Interface Element and its junior elements to be laid aside, and equally, to be
replaced as they
were at a later time.
Interruption can occur by:
Starting a new View or Sub-View
2. Using an Active Element labeled 'STOP' that halts all Execution that is
in progress
3. Unloading the all or part of the User Master View, View or Sub-View,
writing View Specification and Data Specification records that between them
record
499
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the data use and the display of that data, enabling both existing exact
situation to be
recovered at any future time.
4. Marking as inactive in the Status field all or part of the User Master
View, View or Sub-View, writing View Specification and Data Specification
records in
use
Because of the methods of the Any-to-Any machine, and as an advantage over the
state of the art, several users can be logged onto a single machine at the
same time. The
situation is different to several users being logged onto a server, as the Any-
to-Any machine
enables one machine that is 'logged onto a server' to service many users at
once if required.
In the method of the Any-to-Any machine, a user is not logged-off until he
either logs himself
off or the machine stops. If one user is logged on, and a second user is
identified, that user is
also logged on, and his screen User Master View is opened, while the User
Master View of
the first user is interrupted and laid aside in the manner described above.
The Controller
View, notified by the user Identification Module that another user has been
identified, simply
changes the User Master View and uses the one for the newly-identified user.
If this is to be
done, it is of course desirable that the user recognition method in use is a
transparent one,
and that the user identification is checked every few seconds as a background
activity. This
is similar to the way humans work; for example, a secretary does not shut her
eyes and take
orders from anybody who walks in the door, but identifies who she is talking
to, and modifies
what she does and does not say according to who is talking to her and who is
present.
This procedure is possible, because in the methods of the Any-to-Any machine,
both
the interface and confidentiality restrictions are user-dependant, and
therefore, one can be
related to the other. When a particular User Master View is in use, the values
in the
Confidentiality field of every record are part of the Find Specification, and
hence, when
something is restricted from a User, he can be told an item exists and shown
any non
confidential aspects of it, but can not see confidential aspects as these do
not display and
cannot be output by that user. The user can, however, use the Any-to-Any
machine methods
to pass a request to the person who assigned the Confidentiality, to be
allowed access to the
item.
3O REQUIREMENTS FOR VIEWS OF ITEMS
Views of items such as 'a Letter or ' an e-mail' ~ how these things appear on
the
screen - needs to be user-dependant.
Some Software Modules, such as Fax or E-mail Software Modules, only have a
very
limited number of Data Relation Table fields that are required to be used with
them.
However, different users - in a multi-user environment - may want to see even
that limited
number of fields in different ways and have their own preferences, for
example:
500
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
One user may want to see the Addressees name appear at the top of the screen,
labeled 'Who to?', while another user wants the Addressee name to appear at
the left side of
the screen labeled 'Addressee Goes Here.'
Different users may want the input fields presented in a different manner. An
experienced user may prefer that all fields he needs to fill in appear at once
and no Prompts
are used at all. A new user may prefer that the fields he needs to fill in be
fed to him one at a
time with very extensive Prompts. In each of the above cases, the underlying
Software
Module Execution for the action - Fax or e-mail- is the same, but the View
(and hence the
Sub-View) to be used is completely different.
One user may want to see only the fields that are absolutely essential, while
another
user may want a screen showing every possible fax parameter that could be of
interest, such
as field governing Confidentiality, Copies to, Resolution etc.
In each of these examples, the underlying Execution performed by the Software
Module responsible for the actual Execution is the same, but the view the user
sees of that
Execution needs to be completely different. Each one of the above is a
different View for the
same Execution. Hence, there is a requirement that the View to be used can be
matched
with A) to who the user is and also with B).the exact command that user wants
to execute.
94) Methods to Relate Print and other output to Screen inputloutput
In the state of the art, the screen display of an item and the print or other
output of an
item - to a projector for example - have a fixed relationship, and as a
consequence, it is not
normally possible to see an item on the screen with one layout and also print
it with another
layout, without first changing the screen layout. The further consequence of
the One-to-Many
machine fixed relationship between screen and printer is that while it is
sometimes useful to
output to alternately to different printers, requiring change in layout-
change between portrait
and landscape for example - again this is not possible without changing screen
layout also.
With the methods of the Any-to-Any machine, when given data is displayed on
the
screen in one manner with one View Collection, the exact same data can be
viewed and/or
output in a different View Collection without have to change the first View
Collection - both
can be available and the user can change between any number of different View
Collections
for the same data. This can be useful in a View termed 'Battle Manager' by the
Any-to-Any
machine. A Battle Manager is a defined as a View that shows in tabular form,
everything that
the user has on his plate - incoming messages of aft kinds; all things he has
planned to do,
including he time and times he plans for them; incomplete actions, and so on.
Such a View is
normally split into Past, Present and Future Sub-Views so that the user can
review any of
these at the same time, and, due to the fact that all parts of the screen are
Active Elements,
he see all of any item - the equivalent, in the state of the art to 'opening'
it - simply by clicking
501
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
on (the Active Element of) the item concerned. In such a case the data behind
the display is
extensive - a 5,000 foot view of everything in the computer to do with that
particular user. In
common with everything else in the Any-to-Any machine, anything can be named
and hence
any Interface Element can be named, and hence a View can be named.
Consequently such
a Battle Manager can display Active Elements Buttons that are labeled with the
name the
user has given to particular Views of the same data, such as 'Today' 'Next
Week' 'Last Month'
'Next Week's Meeting', and see the particular selection meeting the Find
Specification, with
the particular arrangement - the View - that goes with it.
The same principle applies in relation to print and other output. As
explained, a
particular user has an active User Master View for each type of output
channel, and hence
has one for screens, one for printers and so on. In many cases, the user will
be satisfied to
work on an item on the screen and print it in the exact same manner it is seen
on the screen
in the normal manner. In this case, when the user clicks an Active Element
button labeled
'Print' (or uses a Language Processor that produces the same result) the Print
Module
converts the View into printer-acceptable output per the Active (printer)
Device Setting record
in use in the User Master Print view, and the item prints. An Active Element
Button labeled
'Change Printer' enables the user to change the Active printer Device Setting
record.
However, if the user wishes to view the item on the screen one way and print
it
another way, and the user provides an Active Element Button labeled Change
Print Layout or
similar, then the Change Print Layout Module activated by the Button performs
the following
actions:
Copies the View Collection that is in use, into the User Master Print
View
2. Provides an Active Element Button labeled 'Change to Screen View'
When a Print View exists after being created as per (1) this button stays on
the screen
when the user is in the User Master Screen View but changes its label to
'Change to
Print View').
As a result of this method, two identical Views of the item now exist, one of
which is
labeled Screen View and one of which is labeled Print View. The user can now
apply any
changes he wishes to the one or more Print Views, and the View will print as
it appears an the
screen. The user can also work on the same data in the Screen View, displayed
with a
different arrangement and whatever changes he makes to the data, but not to
the layout of
the data - will also seen whenever he changes to any Print View, because both
are displaying
the same data.
The same principles apply to output other than Print - thus any output channel
can
have its own and different view that suits the channel concerned. A user could
act on a
5o2
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
screen for example, and what he does could be seen as it happens on a video
screen that is
using another User Master View While only one User Master View for a given
output channel
is required, nothing prevents an unlimited number of User Master Views being
used for a
given output channel type, each one set up for a specific device of that type.
Thus, if proper
physical output arrangements are made, a user could act on one screen and what
he does
can be seen on many screens.
If a suitable 'Broadcast' Software Modules are used, and the basic data on
which the
user is acting is transmitted to remote machines in the manner already
described, and the
user's commands to his own machine are transmitted in the form of Data
Relation table
records to the many remote machines, then the user can conduct a planetary
slide show
without any other action more complicated than pressing an Active Element
Button that
activates the Broadcast Software Module.
95) Methods to Relate User Data to Interface Elements
The previous sections describe the Any-to-Any machine's methods for
controlling an
Any-to-Any interface such that the interface can have the intrinsic capacity
to input/output
data in an Any-to-Any manner. The description will now continue by describing
the Any-to-
Any machine methods for relating user data to the Interface Elements that
output the data or
accept the data for input. A number of different situations exist, each of
which has its own
methods and these will be described in turn.
For the purposes of this following description, an 'item' is considered to be
one of
something - an e-mail, a fax, a note, a presentation, and address, a report, a
drawing, a
spreadsheet etc. The one type of thing that is not included in the above
definition of 'an item'
is 'a database', because the Any-to-Any machine is essentially a special type
of database and
therefore, the relation of user data to the interface will be described
separately for the
database function.
8. Creation of Items other than Databases and Spreadsheets
The programmer provides basic screens for the creation of the different types
of item
- termed Item Types - that the application is expected to produce and
therefore should
provide named Views that are appropriate to these items, and named after the
items
concerned - for example - 'e-mail', 'a fax', 'note', 'a presentation', 'a
report', 'a drawing' '
letter', etc.
The creation of all Item Types except a spreadsheet and a database follow the
same
procedures, illustrated in the following description with the example of 'a
letter':
1. An Active Element Menu Button exists for each Item Type displaying a
Label that is the name of the Item Type. These Active Element Buttons may be
used
in anywhere in any View or Sub-View or menu - a menu is only a specialized Sub-
503
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
View. The Label displayed by the Active Element is identical to the name of
the
Software Module that it calls - unless changed by the user following
procedures for re-
naming items - and this name appears in the Software Module Name field of the
Software Module Execution Record that creates the new Item Type. The name of
the
Software Module is also the name of the Item Type that is to be created.
Hence, in
this example, the Software Module that will enable to the user to create a new
letter
could be a Software Module named 'New Letter' This illustrates an desirable
principle
and method of the Any-to-Any machine, termed Name Parallelism. Naming a number
of different things, each of which is a different type enables a Find Module
to find
different types of item that are identically named without requiring user
intervention to
do so. Thus Active Element displaying Label A provided by a Software Module
named
A, effectively names both of them with the name of A. The Software Module
named A
used a View Named A and together they enable, the user to create an Item Type
also
named A.
2. As soon as the New Letter Module is loaded into memory, it uses the
Find Module to find a Active Interface Module record marked as a Base record
which
is a) named 'New Letter' in the Administration Field 'User Name for this Item'
and b)
has in its User Number field, the same number as the number in the User Number
field of the Execution Record of the Active Element button that called it.
(When an
Active Element Button is started in a User Master View, the start process
consists of
copying the Active Element's records into memory. As this is done, the User
Number
in the User Number Field of the User Master View Execution record is written
into the
User Number Field of the Active Element's records. fn this manner, any number
of
simultaneous users can use their own copy of any Active Element Button).
3. If the Find Module does not find a match - i.e. there is no Active
Interface Module Record for the item name in question - 'New Letter' - for
that user,
then it searches for an Active Interface Module record marked Base Record
which is
named 'New Letter' and which has no number entered in the User Number field -
i.e.
it finds the programmer-provided default Active Interface Module record for
'New
Letter'.
4. The Software Module 'Letter' copies the Active Interface base record -
which is named 'Letter' - into memory and activates it. (The Active Interface
Module
assembly named 'Letter' serves both to display a new letter and an existing
one). The
View Module similarly obtains and copies into memory the Sub-Views in its
Active
Interface Module record. The Sub-Views in turn find the Active Elements
contain in
504
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
their Active Interface Records, and consequently, the display shows the
template for 'a
letter', presenting a visual aspect the user considers to be 'a letter'.
5. At the same time, the Letter Software Module sends a token to the New
Record Module to open the quantity of New Records that are specified Letter
Module's
accompanying Data Specification Record for that Item Type.
There are two ways of using Data Specification Records:
a. A Data Specification Record can be constructed as a set that
exactly matches, record for record, the number of records that make up that
item type. For example, if the item is made up out of a Record Set of four
records, the Data Specification record also consists of a Record Set of four
records. In this case, the appropriate values are entered in the appropriate
records of the set. In this case, the two record sets are Field Parallel, and
such a Data Specification is termed a Field Parallel Data Specification
Record.
b. Alternatively Data Specification records can be constructed in
pairs, together termed a Data Specification Record Set in which one of the
pair
- termed the Relative Record states a Record number and a field number in a
record, and the other one of the pair states the value in that field.
6. In the case of Data Specification records accompanying an Item Type
creation Module, the Data Specification Records specify the number of blank
records
and record types that are required by the Item Type concerned. The New Records
that are opened between them provide one field for each of the data fields in
the Sub-
Views of the 'Letter' View Module. Note that, with this method the user can
create a
new Item Type, if a suitable Software Module enables him to copy all the parts
- as
described above - of an existing Item type, copy them, re-name them to the
name of
the new Item Type, and then change them however he wants to change them.
7. The Base Record Field Logic of the Letter Module labels the first of
these new records as the Base Record for Item Type being created by marking
the
first record appropriately in its Base Record Administration field. The Base
record
marking is used in future searches - when an item is being searched for, the
appropriate Find Module initially ignores any records that are not Base
Records,
thereby eliminating all other records from the search that may make up a
single item.
8. All the New Records that the New Letter Module opens are given the
same number in the Sub-Level Administration field by the Sub-Level Field Logic
of the
Letter Module and this referred to as the Item Number, and each item that is
created
is given the next available Item Number in a consecutive series. The effect of
assigning this number is to group all the New Records for the item into one
group that
505
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
together, will constitute 'the letter'. All the records that constitute the
'letter' all contain
the name of the type of item - 'letter' in the Item Type Matter Data Category
field,
placed there by that Field Logic of the New Letter Module. Additionally, the
user can
give the group of records that constitute the 'letter' an individual name,
which is
recorded in the User Name for This field by the User Name for This Field Logic
of the
New Letter Module. Because all the records including the Base record have the
same
number in the Sub-Level field, when the user for some reason locates a record
that is
not the Base record - he locates a record stating an attachment to the letter
for
example - Find can then search for a record containing the same number in the
Sub-
Level field, which is also marked as a Base Record, and thereby find the Base
Record
of the item, enabling it to be assembled and displayed. User Data records that
-
together - contain (or will contain) the user data for an item and are grouped
together
in this manner are termed a Data Record Set.
9. The Sub-Sub-Level Field Logic of the New Letter Module also numbers
all the New Records that are opened - identified by a specific number in the
Sub-Level
field - individual numbers in the Sub-Sub-Level Administration field, thereby
keeping
certain records together in a specific sequence. For example, all records
forming part
of the sender's address can be kept together in this manner.
10. Additionally, the New Item creation Software Module Sub-Level or Sub-
Sub-Level Field Logics can use a Sequence Record to keep together all the
records in
an item, or those in a specific Sub-Level or Sub-Sub-Level number, or both,
and to
keep them in a specific sequence. This ability can be useful when displaying
lists of
items, where a user wants to see the list in an arbitrary order - i.e. he
wants to see
items in a certain order that is backed by a reasoning known to him, but is
not an
ascending or descending sort order. The effect of assigning each record in an
item a
sequence number is to state the order of each record in that group of records,
and if
this is done, then the number of a particular record in the Sub-Sub-Level is
referred to
as its Relative Record Number in the Data Record Set.
11. The View Specification Field Logic of the New Letter Module creates a
Data Relation Table record of the type termed a View Specification, which
states the
Execution Record Numbers of: 1 ) The User Master View Module that is in use 2)
the
View Module that is in use. Additionally it records 3) the number of each and
every
Active Interface Element record that is in use by the View and by all the Sub-
Views 4)
The Number of each Connect To and Interface Control Records that were used. 1
) -
4) above constitute together, the 'View Specification'. If, in the future, the
user wants
to see the item now being created, even if the any aspect of View has beeri
changed -
506
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
for example by someone else re-arranging its display differently - the
original item can
be re-assembled exactly as it existed at the time, since the key original
record
numbers are recorded along with the item. Note that every record in the Data
Relation
Table has a View Specification field, and therefore any particular interface
assembly
can be recorded in relation and used with a specific record, as well as being
recorded
in the View Specification of a Base Record for a group of records, and
therefore,
applying to the entire group.
12. The View Specification Record Number is recorded in the View
Specification'Data Relation Table Administration field of the Base Record of
the item.
If that user - or another user - changes the layout of data in the item, in
effect
changing the View Specification - the view of the data but not the data itself
- than the
action of doing this activates a View Change Module that 1 ) replaces the
record
number in the View Specification field with a View Specification List Record -
a Data
Relation Table View Specification record type, Sequence Sub-Type - and then
~ 5 records for the changed view of the item 1) the date 2) the User Number
and 3) the
number of the View Specification Record, using fields in sets of three to
record this
information in the View Specification List Record. With this method, a single
item can
be displayed in an unlimited number of ways - with an unlimited number of
layouts
and appearances.
13. Supposing that an item such as 'a letter' may at some future time need
to be output with a non-visual interface - for example, read over the phone
line using
text-to-speech - then the sequence in which data is read out to the user by
the
appropriate 'Read' Software Module can be controlled by the user. The user
will refer
to what he wants to hear by using the names of the types of the parts of the
item, such
as is evident in the following examples: "just give me the address", or: "give
me the
First Name and the Content". In effect, the user refers to - states - either
the Data
Relation Table name for the Data Class field of the part - e.g. 'First name'
or the
name of a Data Relation Table record type - e.g. 'address', or the name of a
Data
Assembly Table. The Read Module uses these to select the sequence in which
record
numbers and their fields are fed to the Text-to-speech engine. A Read Module
should
be so constructed as to record a Read Sequence Record that states the sequence
given by the user, so that if the user wishes to repeat the action on the
further items,
or on other items in the future, a record is available that states what that
sequence
was
The Logic of a specific data entry Active Element, once a Programmer or a user
places the Active Element into a Sub-View, is written in such a manner that it
generally writes
507
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
to, or reads from a specific field number in a record that has a specific Sub-
Sub-Level. A
Data Entry Active Element used in all Modules except for a Find Module, is
constructed such
that it will write to 'its' field if that field is empty, and continues to
write until the user ends the
entry - in a Visual Interface, with a Tab or Return key or by clicking on
another Active
Element in most instances, and using an Active Element Button in the case of a
Content field.
Once it has written to the field, it reads 'its' field that it has written. If
thereafter the user
attempts further entry into the field, it displays a Confirm Change Prompt to
the effect 'Please
confirm you want to change this information by clicking the 'YES' button, or
using the 'Enter'
key'. (In the case of Data Entry Modules used in new Find Specification, the
Confirm Change
prompt is turned off, as entering data into a Find Specification does not
change any original
data. If an pre-existing Find Specification is being used, then the Confirm
Change Prompt is
turned on, as the Find Specification may be in use by others or for other
activities).
The Software Module name type 'New X?' - New Letter for example - is reserved
for
Modules that create a New one of something, while 'Find X' is reserved for
Modules that Find
a type of something. Module names of 'X' are generally not used as - for
example if a
Module is named 'Letter' leaves the user uncertain. A name of something - such
as 'Letter' -
is a statement, where as 'make a new letter' or 'find a letter' can be viewed
either an order to
the application, or as a question from the application to the user, but the
one thing it can not
be viewed as is as a statement.
- Saving Items
In the,state of the art, 'Saving' is an expression that signifies that the
item as it now is,
on the screen and in memory, is now placed on the disk and is recoverable in
the future in the
form in which it existed when 'saved'. However, the activity just described
does not apply
exactly to items created with the application, since, records that are written
in memory are
also immediately written to disk, and hence, an item is 'saved' in the sense
that the data is on
dl5k.
However, the programmer can still provide a 'Save' Software Module, together
with its
associated Active Element Button, in order to create a 'Version' of a
particular item. A
'Version' is 'saved' by simply by noting the Time and Data in the Exact Time
Administration
field of the active base Record for the item and marking that time and date
reference with a
code digit that states it is a Version time - i.e. using the Exact Time field
value as a
Combined Number. This marking is preferably done in Exact Time field of the
Base Record
of the Item concerned. The Software Module that does this can also add further
digits in
specific positions to state the Version Number, otherwise, if a Version number
needs to be
displayed, A Version Number Module can search for the number of versions
marked in the
508
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Exact Time field, number each one and provide the Active Element displaying
the Version
Number with the digit for the version being displayed.
A record, once written, is not changed. If the user wishes to change the
record, a
suitable Software Module is called and copies the previous record. The record
that has been
copied is marked 'Inactive' in the Status field, while at the same time
marking the time and
date of the Status Change in Exact Time field of the record concerned. (When
the time of
more than one event needs to be marked in a particular record, then a Data
Assembly Table
is used to do so - this will be described under the Exact Time field). The new
copy is rnarked
'Active' and it is the new copy that is changed. The new copy is treated as a
new record, with
pre-entered data, in which anything may be written up to the paint that record
is no longer in
active use - i.e. is unloaded from memory, or, in the case of communication,
the
communication is actually sent. In either of these two situations, from then
on, the record is
not changed, in the future.
Looking at previous 'Version' of an item is essentially looking at that item
as it existed
at a past time, and ignoring changes made to it at any later time. Because of
the methods of
the Any-to-Any machine - the Data Relation Table is a continuous time-stream
record of
events - it is possible to go back to any previous point in time - since and
see any item as it
appeared at that past time and hence, and the entire history of all changes to
an item is
available, so long as records marked Inactive are still available and have not
been removed
by a Durability Software Module - as will be described under the Durability
field. Viewing a
previous version, then, requires the Previous Version Software Module to send
a Token to the
Find Module, containing a Specification record for the item to be found. The
Create Time
field of this Specification Record contains a value stating that the date from
which the search
on that field is to begin and that any earlier value is acceptable.
Effectively, this starts the
search from a previous date, and not - as is usually the case in the case of a
Find
Specification - from 'Create Time = now or earlier '. The Specification record
sent by Token
to the Find Module does not include any entry in the Status field - and hence
records are
found whether the records are marked Inactive or not. The Previous Version
Module then
looks in the Exact Time field - which contains the time at which a Status was
changed to
Inactive, for any of the found records that were marked Inactive at a time
later than the time
at which the user wishes to view the item. By treating such records - records
that were
marked Inactive at a later time - as Active, and displaying them, the Previous
Version Module
reconstitutes the item, as it existed at that time. In effect, these methods
of the Any-to-Any
machine plus a suitable Software Module can allow the user to scan backwards
and forwards
at will through an item in its development, much like watching a fast film of
the item from its
creation to the present.
509
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
This technique can be used with suitable Software Module and a Timing record
to
control the speed of progress through the various changes, and one use for
this can be as a
training tool - how to write a letter or report for example.
Hence creating a 'Version' of an item is question of marking a particular
point in time
and giving the item at that time a Version Number and/or name if the user
wants to do so -
creating a 'Version' is only a question of marking a specific point in time.
As already described concerning the Content field, two situations can exist:
1. A full Language Processor is in use, and in this case, all Content is
recorded as data Relation table records.
2. Coritent is recorded as a text file, while the remainder of the
Specification is recorded as Data Relation Table records.
In the first case, when the user Saves a Version, the application acts exactly
as
described.
In the second case however, the Content field is treated as a block, and while
it is
automatically and frequently saved by the Content Field Logic of the Module
that is creating
the item, there is no continuous record of changes that are made to the
content - in other
words, each time the Content is saved, the previously recorded Content is over-
written unless
arrangements are made to the contrary. Consequently, in this case, when the
user gives a
Save Version order, the Content field file that is in use, is copied and
closed, the copy is
saved with a new file number, and all subsequent changes made to the Content
are made to
this new fife..
In order to avoid confusions with the state of the art practice, 'Save
Version' is clearer
than using a button labeled 'Save'.
Some of the Interface Controls records- such as Conditional Interface Controls
and
Enhancements - are strictly related to the specific user data being displayed -
they are Field
Parallel Associated Records that are related to the data and used by the
interface. For
example, a user may order that one person's name in one 'a letter' should turn
red if that
person's account balance is negative, but does not want every person's name in
every 'a
letter' turning red if the Condition is met. In this case, the Conditional
Interface Control that
turns the name red applies strictly to one specific 'a letter' and not to all
'a letters'. Three
possible different situations exist:
1. All items of that have one specific appearance and behavior
2. A single item of that type has either a different appearance or a
different behavior or both
3. Any numbers of group of items of that type have either a different
appearance or a different behavior, or both.
510
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
When a programmer first creates a type of item, situation (1 ) exists - since
there is
only one item of that, type, all items of that type (i.e. the only one that
exists) have one
specific behavior. Thereafter, either situation (2) or (3) can be brought into
existence.
Consequently, whenever the user changes any aspect of the interface
input/output of
an item, the programmer should provide an 'Applies to?" Software Module that
finds. out from
the user whether the display change applies to that item only, to a group of
items, or to all
items - when input or output by that user; changes to input or output are user
specific, and
the original programmer-provided default is not normally changed unless
specifically ordered
by the user.
1 p The effect of the 'Applies to' Module is to record appropriately the
changed Interface
Control Records. Changed Interface Control records for situation (1 - all
items) are re-
recorded with the addition of entering the User's number in the User Number
Administration
field. Changed Interface Control records for situation (2 - a specific item)
are recorded as
along with the data of the item, by re-recording them and giving them a the
User's number in
the User Number Field, and additionally, by giving them the same Base Record
number in the
Base Record Number Administration Field as the Base Record number of the item
itself.
When the changed Interface Control records apply to a group - situation (3) -
the changed
records are recorded with the User's Number and the number of the group in the
Data
Relation Table Group field.
2p Interface Elements are so written as to look first for Interface Control
records that are
recorded for a specific item (2) and also for a group of items (3) and then
,look for all items
(1). When a conflict of values in the same field exists - an Interface Control
record for a
single item in a specific field states one value, while an Interface Control
Record for a group,
states another value in the same field, then the conflict activates a Conflict
Resolution Module
that uses its own Sub-View to present the conflict to the user and obtain his
decision as to the
value that is to be applied to (1 ) (2) or (3).
Interface Elements treat Interface Control records of the different types (1),
(2) and
(3), plus the default Interface Control Records for an item as being summed or
totaled - i.e.
the records are treated on a field-by-field basis, not on a whole record
basis. For example, if
an Interface Control record exists for a single item (2), but, in its field
number 4, has no value,
and the Interface Control Records for any of the groups to which that item
belongs (3) and for
all items for that user (1 ) has no value in field 4 either, but the Interface
Control default
Record do have a value in field 4, then the field 4 value is used. The
Conflict Resolution is
not activated in the case where there is a conflict between the Interface
Control Records for
that user, and the default Interface Control records.
511
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
These methods of the Any-to-Any machine provide the basic mechanisms necessary
for a programmer to provide Software Modules needed to carry out such user
orders as to:
'make this look like that' - 'that' being a named item - or: 'show me anything
that looks like
this', when the user is referring to physical appearance as opposed to data
content.
- Post-Creation Execution
Certain types of item, such as an E-mail, or a Fax require further Execution
after they
are created - i.e. creating them is one Execution, sending them is another
Execution. In this
case, the Module that creates the item as described above, when the user is
finished, passes
a Token to Post Execution Module whose Execution record number is contained in
its Director
field, including the Base record number of the data that was created, and this
Module
performs the Execution desired. tn other words, one Module of a given name,
prepares the
item, and another Module of the same name but of a different sub-type,
performs the
Execution - such as sending the e-mail or fax.
- Sub-Types of an Item
As previously stated, the user can change the basic Views provided by a
programmer,
and when he does so he can re-name them. Hence a programmer can provide a
Module
called New Item Type that allows a user to create new types of items. Such new
items can
include completely new items with names that might be nonsense to anyone else
that the
creator, such as a 'Bongo.' Alternatively, the user might create named
variations of existing
items, for example 'a letter' - creating variations such as Office Letter 1,
Office Letter 1, Golf
Club Letter etc. In order to allow the user to create new item types, a New
Item Type Module,
in outline, performs the following actions:
1. Asks the user to state a name for the new item type.
2. Asks the user to choose an existing item type from which to start.
3. Copies the entirety of the Modules and records for the ofd item type and
renames the copy with the name the user provides, entering the User Number I
the
User Number field of each record.
4. Copies the old item's Active Element Button and arranges for its Label
to display top display the new Item Name.
5. Displays a list of all available Post Execution Modules such as Fax, E-
mail, Print etc, and allows the user to relate as many of these as he wants to
the item.
6. Allows the user to change the item in any manner he wants, re-writing
the items records appropriately.
7. Terminates when the user says he has finished and sets the Active
Element Button Execution record to Active in the Active field so that from now
on
512
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
when the Active Element Button with the new name is clicked, the new item
executes
as previously described for existing items.
- Templates
In the terms of the Any-to-Any machine, a specific item type is in fact a type
of
template; however, 'Template' as used in the following is taken to mean: 'an
item in which
specific data is pre-entered for the user based on a Condition.'
The following is the method of the Any-to-Any machine concerning Templates as
defined above:
When the New Item Module is activated, it in turn activates the senior Module
of a
group of Template Modules whose Execution Record Number is specified in its
Director field.
The Template Find Module is accompanied by a Data Specification record or
record set,
Template Sub-Type, Find Sub-Sub-Type that specifies which records and fields
it should
attempt use to attempt to find a previous item of the same Item Type that:
1. Was created by the same user,
2. At the same User Location
3. Sent to the same Addressee
4. At the same addressee Location.
Each field in that is marked in the Data Specification Template Find records,
is also
marked with a code number that Codes for the sequence in which each field is
to be ignored
in successive find attempts. Accordingly, if no previously existing item is
found containing
values in all the fields marked in the Data Specification Template Copy, then
the Template
Find Module conducts further Finds using the Find Module, each time dropping a
further field
from the Find Specification, dropping them in the sequence stated in the
Template Find
Record.
When field values are dropped from the Find Specification, Template Find
Module
may find more than one Template Provider - for example 2 or 3 locations for
one person - and
if so, calls a Template Choose Module. The Template Choose Module, using the
records and
fields specified in the Data Specification Template Find record, compares
those fields in the
Template Provider records with the values in the same fields of the records of
the new item
being created, to find the fields in which the values are different. Using a
Sub-View, it then
displays the fields that are not matching, presenting these to the user in a
Sub-View,
numbering each one, enabling the user to chose the one he wants - for example,
'Home' or
Office' - by stating the number of the item, or clicking on it. When the user
makes his choice,
the Template Choose sends a Token to the Template Find Module with the Base
record
Number of the item the user chose.
513
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
If the above effort fails to find a template provider, the Template Find
Module - or a
subsidiary Module - searches again, using a succession of Condition Records as
Search
Specification, in which the Programmer has specified other Item Types to be
searched in a
specific order, with most similar Item Types specified first.
When Template Find finds an item - referred to as the Template Provider - it
sends
the Base Record Number of the Template Provider to the Template Copy Module.
The
Template Copy Module used a Data Specification record or Record Set, Template
Sub-Type,
Copy Sub-Sub-Type, belonging to the Module creating the new Item to tell it
which fields
should - in theory - be copied from the Template Provider item to the records
of the new Item
Type being created. For each field marked in the Data Specification Record,
Tempiate Sub-
Type, the Template Copy copies the value in the Template Provider record's
field into the
corresponding field in the new record of the Item type being created, provided
the filed
concerned is blank. The effect of this is to copy the value of any record and
field included in
the Data Specification record, Template Sub-Type Copy Sub-Sub-Type, into the
new item,
unless the user has already given a value for that field.
If the Template Find Module fails to find any Template at all - in effect,
this is the first
time that this specific user has used this Item Type creation Software Module -
then a code in
its Condition Field tells it to send a Not Found Token back to the New Item
Module that called
it.
On receiving the Not Found Token, the New Item creation Module calls the New
Template Software Module whose Execution record Number is stated in its
Director field.
The New Template Software Module copies basic information for the User and the
addressee into the record for the new item being created, and then terminates.
Alternatively, supposing that the user does not state anything other than the
name of
the item when giving the order to create a new item, then the Module creating
the new item
does not active the Template Module until further data is received and the
View will present
itself to user with all fields showing their Prompts (An Active Element shows
its prompt in its
data (input output) space when there is no data to read and none is entered.
Hence, it
economizes screen space by using a single area for Prompt, data entry and data
display. If
all data is removed from the field, the Prompt re-appears). The method used in
that case is
as follows:
1. When the user starts entering a value in the data entry field of a data
entry Active Element that calls a List Software Module, the List Software
Module uses
the values that exist in the Data Class Table for the field concerned to
present a Sub-
View showing the list of values in the Data Class that match the part of the
value that
the user has so far entered, continuously refining the list as the user enters
or
514
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
removes data. Each item presented is in the List Sub-View is numbered so that
the
user can either state the number of the item to select it, or click on it.
2. When a data entry Active Element no longer is receiving data - i.e.
another Active Element is receiving data, the Active Element now receiving
data sends
a Token the Module creating the new Item Type, and that Module Activates the
Template Module. The Template Module check or re-checks the New Record for the
item that is forming as the user enters data, and when it finds a Template
provider that
matches the Specification, calls the Template Copy Module as previously
described
When a user changes the layout or the fields that are included in an item
type, this is
detected by the Software Module that is called upon the make the change, and
results in a
Change Item Software Module being called. The Change item Module finds out
from the user
whether he wants this change to apply only to the item he is working on, or to
all similar items,
or whether he wants to make a new item type and if so, whether the new item
type is
completely new or a Sub-Type of an Item Type that already exists. If the user
wants to make
a new Item Type, all record in use are copied and re-named with the name the
user gives to
the new Item Type and the user changes the item however he wants to. If the
Item Type he
wants to create is a Sub-Type of an existing Item Type, all records are still
copied, and the
iterti changed as the user wishes, but the name of the new item Type is placed
first and the
name of Sub-Type stated by the user is placed second. In effect, this will
result in the user-
if he is using a Visual Interface having Action Element Buttons that display -
for example -
'Letter, Collection' 'Letter, Welcome' etc. However, in the standard method of
the Any-to-Any
machine, whenever a Type and Sub-Type exists and is displayed for the user,
each item
occurs twice in the list - for example, as 'Letter, Collection' and
'Collection Letter'.
With these methods, there is no need for user intervention in order to record
templates for any item as the first of any item is the template for any
succeeding items.
- Mail Merge
Two forms of Mail Merge are possible in the Any-to-Any machine:
1. Simple Mail Merge. ft can be possible that the empty fields in an Item
when it is being created are adequate to select the records with which the
Content and
other fields are to be merged. In this case, the user, instead of entering a
value such
as Joe Brown or New York, in the State field, can enter the word 'a11' plus
the value he
wants. The effect of entering 'afl' in a field is to call the ALL Module, and
X in the
fields that he wants filled in. The ALL Module then acts as follows:
a. Sends a Token to the Item Module, ordering it, when creation is
finished, to:
515
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
i. Return the Token stating the Execution Record Number
of the Post-Creation Execution Module
ii. Put the Base Record Number of the item in the Token
iii. Cancel sending a Token to the Post-Execution Module.
b. When it receives the Token, it:
i. Uses the Find Module to get a list of all the User
Numbers for Base Records whose field - in which the All value was
used - matching the value_given by the user following the world 'all'.
ii. Writes a temporary list of these in a Table termed the
Multi Execution Table
iii. Uses the list to construct one data Record for the first
item in the list.
iv. Copies the item whose Base Record Number it received
v. Calls the Template Module to fill in the fields that are
marked X.
vi. In the event there is no Template Set, or all fields
marked X are not completed by the Template Set, it uses the name in
the list to look up and then enter the data into the fields marked X in the
item that do not yet contain data.
vii. Sends the first item to the Post Execution Module to
execute.
viii. Deletes the completed item from the list.
ix. Repeats iii-viii until the list is empty
x. Send an acknowledgement prompt to the user to state
that the job is done.
xi. Any failures occurring in the Post-Execution Module's
Execution are handled individually by the Module's Execution checking
Condition records and procedures already described, and can result in
an Alternate Execution being attempted - for example, if an item does
not go through by e-mail, attempts to send by fax or text to speech
phone message etc.
2. Complete Mail Merge. The procedure is similar to the above, with the
exception that a an Active Element Button labeled Merge Specification or
similar calls
a Merge Specification Module and Sub View, which provides a full Find Sub-
View,
complete with Filters and Operators to enable the user to use all Data
Relation table
516
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
fields to provide the Specification for the records or items to be used. This
Specification is then used to create the list referred to in 1 b ii above.
When doing Mail Merge, the user can chose and add to the item any other fields
that
may be useful to him such as 'Account Balance'. All Views and Sub-Views
standardly contain
an Add Field button. The effect of this Button is to provide a Sub-View
showing a list of All
Field Names - this list is gathered per produces that will be described later.
The user can
choose any of these by stating its number or clicking on it, which displays
its default Active
Element, which the user can then move where he wants. The Add Field Module,
using a
timing record to count a few seconds delay, perform the procedures to revise
the Sub-View
as described under Insertion and Deletion of Interface Elements.
Note that mail merge performed in Content, in the absence of a full Language
Processor, is not a true merge but simply a superimposition of an Active
Element displaying
the field value, over the top of the large Active Element that is used to
display Content. If a
full Language Processor is used however, then Content also is displayed as
Active Elements
with one word per Active Element and then true merge if possible and the merge
field is
simply another field in a sequence of fields.
- Translation Modules
While the description is written in terms of Spoken (English) language Concept
Language Values, ali data in the various tables of the Any-to-Any machine
except Data Class
Tables is in numbers Concept Language, while Screen displays and output are in
terms of
Spoken Language concept Language, and both in input and output, translation is
useful both
of incoming values from the Visual Interface and values that are outgoing to
the Visual
interface output channels. This is accomplished by one or more Translation
Software
Modules, which are placed logically between the Interface Elements and the
Data Relation
Table. The Translator Module has a Field Logic for each field that receives a
value either
from a Table field or from an Active Element and supplies the translation to
whichever of the
two did not send the data. In order to ensure good speed, each record that is
in memory can
have its own Translator Module. A Translator Module is Field Parallel and each
field Logic
services only one Data Relation Table field and therefore only one data Class
Table, both of
which have the same number.
A Translator Module may receive a Spoken Concept Language value for which a
corresponding Numbers Concept Language value does not exist in the appropriate
Table -
for example, the user enters a name. for which there is no previously recorded
value.
Similarly a Translator Module may receive a Numbers Value to translate into a
Spoken
Language and find there is recorded corresponding Spoken Concept Language
value in that
language. When more than one Condition can exist in any field that a
Translator Module
517
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
should translate, then Field Parallel Condition Records, each with their
corresponding Director
Record, is required to test which of the possible Conditions that can exist in
the field in
question, actually exists. If only one Condition can exist in each of the
fields that a
Translation Module should translate, then a Condition Record is not strictly
necessary, and
the logic of the Translation Module can use the Director record directly.
However, this is not
the most desirable method as it may mean that some Translation Modules wilt be
written to
use Condition records while others are not and further means that the absence
of a Condition
Record, means that it is assumed that no-one, anywhere, ever, in any language,
will enter
something that constitutes a second Condition in any field that the
Translation Module should
translate, Since such assumptions mostly turn out to be untrue, every
Translation Module is
written to use Condition records, even if no instance of two Conditions in a
single field can be
seen to be likely to arise at the time the Module is written. If only one
Condition is foreseen in
each field, then the Condition Record states that one Condition for each
field, If, in the future
other Conditions are also found to be able to exist in any field for which a
particular
Translation Module is responsible, then an additional Condition Record is
added to state the
new Condition, and no other change whatsoever, is necessary.
In fact, in any field that receives data entry, at least two Conditions are
possible:
The user is intending to enter a new value
2. The user has simply made a mistake in entering the value, typing the
wrong value in the wrong place, or hitting the wrong key on the keyboard.
Hence, when a Translation Module gets data that cannot be translated it calls
a
Resolve Module with all the necessary sub-Modules, Sub-Views etc, that takes
over, uses
Condition records to determine the Condition that exists, and then takes the
appropriate
action, while using the minimum of user intervention to do so. Various methods
can be used
to do this, such as displaying a list of alternate values that are similar to
the value entered,
displaying a messages, making the value blink etc.
In the event that the user does want to enter a new value, then the Resolve
Module
uses the Director Record paired with the Condition that was matched, to call
the appropriate
Software Module that takes care of that type of new data entry. When the new
data entry
Module completes, it returns the token received to the Resolve Module, which
returns it to the
Translation Module, which can now complete its translation.
New Data Modules are generally specific to the exact type of data being
entered - a
new phone number, or a new address - and take care of all needed actions for
doing so,
including recording relationships with pre-existing data.
518
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
- Item Find Modules
Each Item type can have its own Find Specification records. A Find
Specification
record is a Data Relation Table record, Data Specification type, Find
Specification Sub-Type.
A named Find Specification record can contain pre-written values that limit
the Find to that
type of item, plus a Sub View displaying fields which the user may need in
order to further
specify what is to be found., and enabling the user to specify Filters and
Operators. In
practice, it is also useful to provide one Find Specification record in which
no values are pre-
loaded, that the user can use to find anything, plus Specification records
that contain values
limiting the Find to groups of items such as Documents, Planning, Statistics,
Addresses,'
Spreadsheets etc. If the programmer does this, then he can also provide an
Active Element
displaying a suitable label, such as 'Addresses' 'Documents', 'Planning' that
when clicked,
activates the Find Module, but with a Specification record that contains pre-
loaded values
limiting the Find to what the user wants. If the programmer does provide
these, then a
suitable Software Module can copy an existing Find Specification plus Sub-View
plus Active
Element Button and then modify them to provide a specific type of Find for
something he
wants to find frequently. In effect, the Active Element that calls such a
specific type of Find is
calling the same Find Module, but giving it a New Record to use for the Find,
that contains
certain values, that are copied from an existing Specification record.
When a full Language Processor is in use, it is the task of the Language
processor to
designate exactly what type of item the user wants found, and to write the
Fins Specification
record accordingly. The Find Execution record then uses this in the standard
manner to
locate the item.
When items other than spreadsheets and databases are found and re-displayed,
it is
desirable that the original item is not modified a) because some other item
may now user or
refer to some data in it and hence, refer to it and b) because the item is
what it is, and
changing it destroys the record of what was done. Because of this, there are
two basic
methods that can be used when such an item is re-opened, and the user should
be given the
choice of which he prefers at install time:
Items when re-opened, are copied before opening, any Add Anothers
are executed, and the item is a new a new version that is ready for
modification. If it is
not modified, then it is discarded, following the procedure described shortly
under
spreadsheets.
2. Items are re-opened in read-only mode and an Active Element Button is
provided with a Label 'Modify This?' If this button is clicked, the item is
copied, Add
Anothers are executed and the user modifies the item. This is not the most
useful
method but is less trouble for programmers.
519
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Language processors, in the Tokens they pass to the other Modules can specify
whether the Visual Interface should be displayed or not - i.e. whether the
View Module and
its juniors are Active, or marked Inactive in their Active Data Relation Table
field - in which
case, they do not execute or display.
Some Software Modules - such as the 'Find' Software Module - could potentially
require the screen to show any of the 150 or so fields that make up a Data
Relation Table
record and 300 or so fields that make up a pair of Data Relation Table
communication
records - one record for the sender and another for the receiver. It is
neither practical nor
desirable to display 300 fields at once.
If a user says 'Find' the application cannot throw 300 fields on the screen,
but should
wait - and perhaps prompt - for further data such as 'A letter'. The input of
'Find' plus the
input of 'a letter' needs to be able to select a suitable~View- i.e. a
suitable selection of Data
Relation Table fields - where the user can place the rest of his Specification
if he wants to.
When a Visual Interface is in use, buttons can be provided to activate
different types
of Find - i.e. an address Find, a Document Find, a Calculation Find and so on.
Again, while
there is only one Software Module called Find that finds anything that needs
finding, the View
is different in each case. The fields required for each of these types of find
will be different -
i.e. different Views. Pre-programmed Views can - essentially - be attached to
Icons and
thereby pre-select the fields to be displayed. Hence, with a Visual Interface,
the ability is
required to match the View with A) who the user is and also with B) the exact
command that
user wants to execute, can be adequate.
- Creation of a Spreadsheet
RECORDING OF SPREADSHEETS
The files that are today prepared by any and all state of the art software
packages - or
that have been prepared by them in the past - can be treated by an application
built with the
Any-to-Any machine methods, in one of two ways, and spreadsheets are no
exception to this.
The files prepared by such software packages can be treated:
1. As Content.
Files created by software packages written with non-Any-to-Any
machine methods are treated as a Sub-Class of Content - i.e, with one Data
Relation Table field for Content Software Package and a second field for the
Sub-type (the package name).
2. As Data Relation Table records
The functions in a state of the art software package are re-written as
Software Modules and the data itself is recorded in the tables of the Any-to-
Any machine.
520
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Any combination of these two can also be used; for example pre-existing data
can be
left as it is or converted into the format of the tables of the Any-to-Any
machine using
Converter Modules. Further items of the same type can be created by either the
non-Any-to-
Any machine package or by Software Modules installed in the Any-to-Any
machine. In some
instances it can be convenient to create some spreadsheets using existing
packages, and
others with appropriate Modules and Tables that create 'spreadsheets' with the
Any-to-Any
machine methods.
The difference between the two methods is the functionality required. If the
files of
non-Any-to-Any machine packages remain in the format in which their software
package
created them, the data contained in those files is a many level One-to-Many
assembly and is
only accessible to be related to other data in the application with keyword
technology and the
inaccuracies that entails, as previously described. Effectively, even if the
relationships of data
(contained in such file assemblies) are found andlor related (recorded) in
relation to Any-to-
Any machine-format data, the result is inaccurate, unreliable and effectively
of little use. This
is one of the reasons that non Any-to-Any machine-format data in the form of
Keyword
searches on Content fields containing non-Any-to-Any machine format data, are
used as a
tail-end supplement in the Any-to-Any machine Find procedures. (The other
reason is that
keyword Content searches are relatively slow).
In order to be able to discover relationships between data in 'spreadsheets'
and any
and all other data in an application written with the methods of the Any-to-
Any machine, it is
preferable to create spreadsheets with the Any-to-Any machine methods, and
preferable to
convert spreadsheets made with old-style software packages, into the
spreadsheet format -
which requires a sophisticated Converter Module for each package to do so.
Hence the decision on whether or not to use or continue to use packages, or to
convert files of packages written with state of the.art methods, depends on
whether or not it is
desirable to be able to find - and consequently to use - relationships that
actually do exist
between data in the files of such package and any other data stored and
manipulated with the
Any-to-Any machine methods.
When 'a spreadsheet' is created with the Any-to-Any machine methods, as for
all
other items, a Spreadsheet Module is used to create 'a spreadsheet'. Similarly
to other new
item creation Modules, when activated by Language Processor or its associated
Active
Element Button, the Module creates the necessary new records and calls its
Associated View
Module. There is no specific size for 'a spreadsheet' and a spreadsheet first
appears as a
small but convenient size. In the standard manner, when the user enters data,
the
spreadsheet Add Another Module opens a new data entry area to replace the one
he is now
using, so that however much space is used in a spreadsheet, more space is
created ahead of_
521
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
the user. In the case of a spreadsheet however, the spreadsheet Add Another
Module
creates columns and/or rows in blocks of a convenient quantity - such as ten
at a time -
termed a Spreadsheet Add Another Block. Moving around a blank spreadsheet -
for
example, by using the arrow keys or the cursor, blank rows and/or columns are
added ahead
of the cursor. Obviously, a user may just open blank rows and columns for
amusement, and
while there is no reason he should not do so, a Module should be provided to
check for this
behavior and point out to the user that there is no size limit (if all the
methods of the Any-to-
Any machine have been implemented) and that he is filling his application with
empty space.
When a spreadsheet is unloaded, the records corresponding to any completely
empty
Spreadsheet Add Another Block are cleared of all contents except the Record
Number in the
Record field - effectively removing them from 'the spreadsheet'. A Re-write
Module 1 ) places
all the record Numbers of these empty records into a one column Re-Assignment
table, and
2) re-writes all subsequent records to use the empty records, so that there
are no empty
records left in the Data Relation Table. Such a re-write procedure can be
complex but is well
within state of the art competence, as shown by such utilities as disk
defragmenters that
perform an analogous task. Records are not normally deleted, as to do so
raises the
question of what was in them, and more seriously creates the risk that an item
that referred to
one of the deleted records is effectively deleted also, as part of its data is
missing. The Data
Relation Table is, however, reorganized from time to time to compress it, and
these
procedures will be explained in due course.
A number, in the terms of the Any-to-Any machine, is classed as a Modifier - a
Data
Component that, on its own is so broad in it's meaning as not to be useful on
its own and in
complete isolation. Matter Data Category Components, where a word such as
'table' to a
type of thing - while they have a broad meaning, have a broad meaning that is
useful even
when used in total.isolation. The number '14191' in complete isolation has a
meaning so
broad as not to be particularly useful when used in isolation. Numbers, as a
Data Class,
belong to the Life Data Category, as they are a phenomenon that arises with
life, and do not
otherwise exist - numbers exist only because a human says so, or agrees it is
so - and
further, numbers display the characteristic phenomena of all Life Data
Category Data
Classes, namely, that they can modify any value from any Data Class.
Consequently, like
other Life Data Classes, in addition to a Data Relation Table field in the
Life Data Category,
Numbers have a their own Data Relation Table record type, and - like all Life
Data Category
Data Classes - this is a Field Parallel record type that is used as an
Associated Record to a
data record.
The Base Record of a spreadsheet is a user data record that states the User
Number
of the user who created the spreadsheet, when it was created, its title if
any, etc. Thereafter,
522
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
each line of a spreadsheet is a pair - a Data record with an associated
Numbers Record that
contains the numbers entered by the user or calculated by formulas. ('A
spreadsheet' can be
used to calculate numbers, without containing any text at all and without
having any numbers
to which a meaning is assigned that would normally be the meaning conveyed by
one or more
words. In this case, while such a spreadsheet can be named and found again in
the future,
the numbers it contains are not related to anything that can be known by the
computer. They
are simply calculated numbers).
Each Numbers record acts as the lead or guide record for a number of
Associated
Records that are Field Parallel with each single Numbers record, and, with
some exceptions,
are the same, or closely similar to the record types already described for
other items. Hence,
for example, a Numbers Record can have any of the Interface Control types
previously
described., and these can be Associated with the relevant Numbers Record using
the number
in the Sub-Sub-Level Field:
Alignment types
Enhancement types Color, Font, number of Decimal
Places, Currency sign, leading or trailing currency signs, data
format
Conditional Display changes based on Conditions
Column and Cell widths that are normally required in state of the art
spreadsheets, are
not of great use as Active Elements adjust themselves in size, and a group of
Active
Elements such as 'a spreadsheet' can be Squeezed using the mouse in which case
both the
cell size and the size of the font used to display the data adjust to the size
user's Request
Space order.
Borders for groups of cells are created by using an Active Element that is
transparent
- except for its border - and which does not accept or display data, as these
abilities have
been turned off.
Merge and unmerge cells is not normally needed, as any Active Element - any
cell -
can be any size, and there is no obligation in the Any-to-Any machine methods
to fill with cells
areas that are other wise blank. Active Elements - cells - to display and
calculate numbers
can be added or removed from any kind of item including 'a spreadsheet' and
because there
is a cell in a given position does not mean there should be a cell next to it -
there can be one,
or not, just as the user requires.
In the method of the Any-to-Any machine, and individual spreadsheet record is
actually a Data Relation Table record, as shown by the following example of
what might be a
small part of a typical spreadsheet:
Sales Revenue April, 1995
523
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
~P;roauci~:y,: ' ::;.: ~ ~::: ':r~2~o:,000
':
Product 2-'' :1:25.000:
- , ; . ,, :..; : ...
r~ . ..... ;.. .;.:::: : :.;,
. : .,. . :. -,..~_
, ..._
'.' . :r ,- . - ;.,
Product 3 , 300,000
4-... y:~;; =. .;~; : .;v.::
~: .~ ' . ; :.:,_;:,. : ;::...;,,:;;,:;:::
f?roduct' 4'. 250,000
.. . .. . .
. . ,
.. ...
Total "
.~ ..
~ 925,000
If these spreadsheet records were converted into, Data Relation Table records,
they.
would appear as follows (only relevant data fields from the Data Relation
Table are shown:
Record Record Category:Category: Cat: Action Category Matter,
Number Type Time, Action: Sub- Type
Date Saie Type of thing:
94 Data April Sale Revenue Product 1
1995
95 Number $250,000
96 Data April Sale Revenue Product 2
1995
97 Number $125,000
98 Data April Sale Revenue Product 3
1995
99 Number $300,000
100 Data April Sale Revenue Product 4
1995
101 Number $250,000
102 Data Apri11995Sale Revenue Total
103 Number $925,000
As a review of the Data Relation Table format for the spreadsheet cells in
this
example shows, it is now possible to search for the query 'April 1995 Sales
Revenue?' and to
find the answer. If the query issued and other data exists on 'April 1995
Sales Revenue' - for
example in communications or elsewhere, all data that exists to do with April
1995 Sales
Revenue can be found. The data that is required, can then be selected, groups
and used.
Equally orders such as the following becomes possible: 'print me the sales
Product 1 for each
salesman for any month in which product 1 sales are 10% or more below its
sales for the
previous month. Also Print the profit generated by each such salesman on
Product I and the
cost of that salesman attributed equally amongst all his sales profits.'
Hence, 'a spreadsheet', written with the methods of the Any-to-Any machine, is
simply
and only a particular visual presentation of Data Relation Table data (and
potentially, a
presentation of data from other tables in the Any-to-Any machine), that
concentrates on
mathematical methods incorporated in the Any-to-Any machine that will be
described shortly.
524
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Three main ways exist of creating 'a spreadsheet' in the Any-to-Any machine:
1. In Data Relation Table records in the normal manner '
2. In a separate Data Reiation Table that is dedicated to spreadsheets
and can be placed on another machine. In this case, all records include the
Sub-Data
Relation Table Identify Number in the Sub-Data Relation Table Identity field.
In this
case,
a. An Execution Split Module that sits at the side of every Find
should run the same Find in parallel on the Spreadsheet Data. Relation Table,
followed by a Virtual Record Converter to create a Virtual Record in memory
p out of any matching records found in the Spreadsheet Data Relation Table.
b. Each Execution Module should have an appropriate Subsidiary
Module that is able to write to the subsidiary Spreadsheet Data Relation
Table.
This method can be applicable if many spreadsheets are likely to be used.
3. Using a Spreadsheet Data Assembly Table.
While spreadsheets are composed of Data Relation Table records, it is likely
that
many of the records would be almost entirely empty, and this is a situation
that lends itself to
the using a Data Assembly Table, which is, after all, only a shorted Data
Relation Table.
While a spreadsheet may have values in only one or two classes of each
individual Data
20 Relation Table record, the values used are likely to cover virtually all
Data Classes in the
course of time, and therefore, a practical method to create spreadsheets is
with a Data
Assembly Table which:
1. Contains the necessary Administration Fields from the Main Data
Relation Table, needed to group records - in the main, the Record Type, Base
Record
25 Number, Sub-Level (number), Sub-Sub-Level (number), AND V & H, AND WAS V &
H, User Number fields.
2. Contains several fields, with each containing a Combined Number that
states a) The Data Class of the Value and b) the Value from that data Class.
If a
numbering method is used whereby the number of the Data Class is part of the
30 reference number for a value, a Data Class value intrinsically states its
Data Class. If
this method is not used, then fields need to be used in pairs, with one field
stating the
Data Class value and another stating the number of the Data Class.
3. A Formula Data Class field - the nature of this field will be explained
under 'Calculation Methods' below.
35 I 4. A Number Data Class field
525
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
5. Potentially a field for each Interface Control value - or a field to
contain
the reference to a record in the Interface Control Data Assembly table
previously
described.
If the Data Assembly Table method is used, then appropriate Converter Modules
have
to exist so that when a Find is done:
1. One of the Converter Modules completes the search on the several
Data Class fields - 2 above - where any Data Class value can be in any field
2. Another Converter Module should turn any records that are found into
Virtual Records that can be used by all other Software Modules (a Virtual
Record is a
record that is made into a full Data Relation Table record and read into
memory as
though it was a record in the main Data Relation Table. If this method is
used, the
Administration field of all Data Relation Table tables should include a field
for Virtual
Record Number; at conversion time the Converter Module writes the original
record
number of the record to be made into a Virtual record, into the Virtual record
Number
field and deletes the original record number form the Record number field
thereby
avoiding two records appearing to have the same number, once they are read
into
memory).
With the above modifications, a 'spreadsheet' is like any other item, with the
further
exception that it makes more heavy use of Calculation Software Modules, and
their data
relating methods.
DISPLAY OF SPREADSHEETS
While state of the art spreadsheets present individual cells as a continuous
pattern of
rectangular cells, where cell border are either visible or invisible, there is
no obligation for a
spreadsheet created with the methods of the Any-to-Any machine to do so, and
some
examples of the flexibility of the Any-to-Any machine methods in relation to
'a spreadsheet'
are:
1. Individual cell borders (Active Elements) can be on or off.
2. Individual cells (Active Elements), if their border is turned on, can be
any shape, and any installed Interface Control, such as Spin or Walk can be
applied to
any spreadsheet cell or group of cells.
3. Because the data and the manipulation of the data does not have any
fixed relation to the display of that data, there is no obligation for the no
obligation for
the cells of a spreadsheet to remain in the layout iri which they were
created.
For example, if the user wishes to create 'an invoice' that calculates itself,
he can
create a small spreadsheet that performs the necessary calculations. This
spreadsheet may
begin life as sub-View, whose border is the not itself visible (i.e. the Sub-
View itself has its
526
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
border turned off). The user can then move the individual 'cells' into the
positions they will
occupy in the finished invoice, and as he does so, the size of the Sub-View
will expand
automatically using the methods previously described, illustrating the fact
that there is no
obligation for a Sub-View to occupy a physically distinct area of the output -
the Active
Elements that make up a give Sub-View can be anywhere - for example, they can
be in Any
positions on the screen. It is this that gives rise to the definition of a Sub-
View:
A Sub-View is a collection of Active Elements presenting data where each of
the Active Elements is using, or can use, an identical pattern and types of
Data
Relation Table or other records.
And hence the definition of a View is:
Any collection of Sub-Views that the user may wish to handle as a named unit
such as 'a letter'
And a View Collection is:
Any Collection of an individual user's Views that are using the same
input/output channel at the same time, or, that are available to use the same
input/output channel at the same time.
Hence the classification of any selection of Interface Elements is a
functional
classification, not a recorded classification that is stated anywhere in the
recorded Interface
Elements or the data they are showing.
The user can add further data, for example, by simply calling for a list of
named items
he has created previously and adding chosen items from them, such as one
called 'Company
Letter head', 'Special Promotion' etc, and then moving these around on the
screen until he
likes the final arrangement. When added, these items are added as Sub-Views
and may, or
may not be occupy a contiguous physical area of the inputloutput
If the programmer has provided a New Item Create Active Element Button and
Module, then the user can add an Active Element Button and give it the name of
'New Client
Invoice' and doing so creates a Software Module of the same name that opens
the item each
time its Active Element Button is called.
The user can off course copy the View of the item - with one name - and then,
in the
copy, turn off the display of individual Active Elements - such as one showing
the label 'Profit
on the item'.so that a customer cannot see it, give the View a Confidentiality
'Not Customers',
with the result that customers see one version, and accounts personnel see the
version that
shows profit and other information - but with information in which they are
not interested
turned off - such as the Sub-View containing the company address for example.
If the
calculations in the spreadsheet are labeled with the correct account names,
then, when a
customer enters data ordering something over the web, for example, and a Paid
Module
527
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
marks it as Paid, a Deliver Module marks it as delivered, then the effect can
be that the
international profit and loss account and Balance sheet is updated. Any
manager can see the
profit on any product sale or any grouping he chooses; such an application of
the Any-to-Any
machine's methods is termed 'Real Time Accounting' and solves one of the
largest prablems
in business - financial information that is historic and often inaccurate, a
is a major cause of a
problem that periodically manifests itself as companies - with access to the
most
sophisticated technology - announcing million and billion dollar losses.
- Calculation Methods and Relating Data using Calculations -
All calculations that are performed by 'a spreadsheet' in the state of the art
are
implemented in the Any-to-Any machine as Software Modules and hence, are
available for
use in any type of item in which a Numbers fields is used and, as stated, any
data record can
be accompanied by a Field Parallel Associated Numbers record.
A Field Parallel Associated Calculate record that can contain the number of
the
Record of Calculation Software Logic Module can also accompany any Numbers
Record. A
Software Logic Module is a single Field Logic that can act on its own and
perform an action,
such as a performing a typical spreadsheet calculation. The reference number
of a Software
Logic Module is the record number of the record in the Software Module Data
Assembly
Table that assembles it. When any Software Logic Modules is created that the
user can
himself use individually - whether or not these are also further assembled
into a Software
Module - then the Software Field Logic Assembly Table requires a field each
for its Label,
Prompt and Help references, referring to the Label, Prompt and Help Data
Assembly Tables.
The arithmetic signs +, -, * or x and l are the names of Calculation Software
Module
Logics that perform the actions of those signs. Other Calculation Logic
Modules are
appropriately named, so that they communicate to the user what they do, but
each one is
accompanied by its own Help file, whose number is recorded I the Help Field of
the
The Life Data Category of full Data Relation Table record contains a Number
field and
a Calculate field. A Calculate Logic Module can often be called up on perform
a calculation
only on the Numbers field of the AND or AND WAS record to which it is joined.
A Calculate
Logic Module places the result of its calculation into the Numbers field in
its own record.
Calculations - generally addition and subtraction - with an AND / AND WAS
record
pair are useful in an Accounting application, where the first record is a
record for one account
to which something is added - for example - and the other record is for the
opposite account
to which the same amount should be subtracted for example. Since a record that
a record
that is the AND WAS record to previous record, can also be the AND record to
another
record, an amount removed from one account, and added to another, can be
further split
between an unlimited number of accounts. Accounting items are not grouped or
summed
528
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
before entering, but each one is entered individually, for example, by using
front office staff to
do so in the course of the normal operations they should do to do their work -
such as issuing
invoices etc.
However, Calculate Modules frequently have to act on number data outside their
associated AND or AND WAS record, and in this case, in the standard method of
the Any-to-
Any machine, the formula itself and the arguments on which it operates are
separated into
Field Parallel fields with the following general method:
1. The user can construct formulas in with the cursor and notation
methods that a standard in spreadsheets in the state of the art. However, when
the
user does so the Numbers Active Element -an Active Element adapted to handling
numbers and formulas - places the formula he enters into the Formula field,
not into
the field to hold the resulting number. This is one of the instances when an
Active
Element can cross Data Classes. The Active Element enters data into the
Formula
field, and, when the user presses Enter or Tab, displays the contents of
the~Numbers
field.
2. If the Calculation the user wants to enter into the formula field is
relatively simple - i.e. does not exceed a fixed limit that is a combination
of the
number of Calculation Logic Modules and the number of arguments each one
requires, then the formula is entered into the Formula field - in terms of
reference
~ numbers to Calculation Logic Modules.
3. If the number of Calculation Logics and their arguments exceeds this
programmer-set limit - decided by the maximum digits that a single field can
hold in
the storage system in use - then instead of the formula itself being stated in
the
Calculate field, the field states a reference number to the Calculate Data
Assembly
Table.
4. The Calculate Data Assembly Table contains a field for the record
number and then a reasonable number of fields each of Which can contain a
Calculation Logic Module reference number, plus two fields for the AND H l AND
WAS H mechanisms to join two fields together end to end. Additionally, the
table
contains a field in which the user can name any particular formula combination
that he
has entered. When the user has named a formula, he can then use the name
instead
of specifying the formula.
5. When the user enters a formula that exceeds the maximum length and
therefore is to be recorded in the Data Assembly Table, the Formula Construct
Module
that is called by a Numbers Active Element when it detects formula entry,
checks
existing combinations of Calculate Logic Modules that have already been
recorded,
529
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
and if one of these exactly matches the formula that the user has entered,
then it uses
the one that is already recorded.
6. The fields to which each argument field refers - i.e. uses in its
calculations - are recorded with a parallel method to the above method for
recording
Calculation Logic Modules. If the number of arguments - the fields to which
each
formula refers - is less than the programmer-set limit (3 above), then the
fields to
which each part of the formula in the Number field are recorded in a Field
Parallel
Reference field. The recording is in the form of a Relative Field Number as
previously
described for Template records and in point 8 of 'Creation of Items other than
1 Q Databases and Spreadsheets'.
7. However, if the field references that are to be recorded exceed the
programmer-set limit, then a Field Reference Data Assembly Table is used, and
the
value in the Field Parallel Reference Field points to a record in that table.
8. The Field Reference Assembly Table contains fields for the number of
~ 5 the record, and a reasonable number of fields each of which can contain a
combined
Relative Record number and the field number in the relative record. In
addition, the
tables contains two fields for the AND H / AND WAS H mechanisms to join two
fields
together end to end. Additionally, the table contains a field in which the
user can
name any particular reference combination that he has entered, so that when
the user
20 has named a reference combination, he can then use the name instead of
specifying
the reference combination. When a range needs to be specified, this is done
using
the standard spreadsheet system in which the first and last fields of the
Field Parallel
range are stated, and the Calculation Logic Modules that perform the
calculation apply
the calculation to all the field in the range.
25 9. If the reference is to a field in a record outside the spreadsheet
itself -
i.e, all records grouped together with an Item Number, then, if it is just to
a single
record outside the spreadsheet in question that is used for each formula, the
Field
Reference Table is given a Record Number Relative Reference, so that the
combined
values in the Field Reference table Reference record, and Record Number
Relative
30 record, give the exact record and field number to which the formula is
referring. If
however, formula refers to a range that is outside the spreadsheet, then:
a. If the range occurs 100% within records that are already
grouped with an Item Number, a further Field Parallel Item Number Reference
Record is used in the Field Reference table.
35 b. If the fields concerned are not already a group, then the
Reference Creation Module should first group them according to the Any-to-
530
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Any machine method for grouping records using the Group Table - to be
described - assign the group a number, and then use the assigned group
number in the Item Number Reference field in place of the Item Number,
noting with a code digit that the Item number is found in the Group Table.
As a result of these methods, Formulas and the fields to which they refer
strictly are
parallel one to another, and these methods make spreadsheet-type facilities
available for
inclusion in any item type, and for use by database functions.
- Creation of Database Data
With the methods of the Any-to-Any machine to construct 'a spreadsheet' -
which
makes spreadsheet facilities available in every item created by an application
written with the
methods of the Any-to-Any machine - there is no detectable difference between
'a
spreadsheet' and 'a database.'
'A database' is actually the same as any other item, with the different that
there is no
specific visual look that identifies 'a database' in the same way that a
specific visual look
identifies 'a letter' or 'a spreadsheet'. Otherwise all provisions so far
described do apply. In
effect, a working description of 'a database' in the terms of this Any-to-Any
machine is: 'a
View that does have a look that is identified with any other named type of
item'. An Alternate
definition of ' a database' is:
A named collection of fields plus a filter Specification that excludes items
from
those fields that are not part of 'the database'
The difference in the construction of 'a database' lies in the method that is
used to
create the View of the database, and this arises from-the fact that there is
no identifiable and
predictable 'look' to a database, other than that it is usually tabular.
'Database Reports' in the
terms of the Any-to-Any machine are simply a (named) collection of specially
created Data
Relation Table records, in which the Numbers field totals various records, and
a further
Numbers field may totals those totals.
In order to provide a View for a user who wants to create 'a database' the
programmer
should, as usual, provide some basic Views and Software Modules enabling the
user to
choose Data Classes, so that the user has something to start from. In order to
do this, the
programmer should provide each Data Class with a default Active Elements
suitable for each
Data Class and data type within a Data Class in the Active Element Assembly
table. The
programmer and the user can then take these and choose suitable Data Relation
Table fields
to put into 'View', and gives the View a name, and gives all the Active
Elements in the View a
common look. To enable the user to assemble his own 'database' the programmer
should
provide a Sub-View that lists all available field names - i.e. lists Data
Class Names, and all
531
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data Class types, in a every Data Class 'type' field and enables the user to
select these,
either by stating their number in the list or by clicking on them.
The user can then assembly his own database by choosing one of the named Views
the programmer has created and then changing - if necessary - the particular
Data Relation
Table field that is serviced by one or more of the Active Elements in the
View. Alternatively, if
the programmer provides a Module to display and a View to show all different
Active Element
looks that have so far been created, the user can choose one of these, copy
it, and make up
his own named View by assigning each Active Element in it to access the
appropriate Data
Relation Table field and changing the look.
To assist the user in this, the programmer should provide a 'look Like This'
Software
Module that allows the user to modify one or a group of Active Elements, so
that, by using the
'Look Like This' Module, the user can give the same appearance to other Active
Elements or
groups of Active Elements.
Additionally, the programmer should provide at least an elementary Language
Processor and a suitable Sub-View, allowing the user to state the values he
wants to enter
and the type of value each of them is. The type the user gives is then matched
with all field
names so far recorded - all labels recorded for each Data Class and all types
recorded in
every Data Class Sun-type field - with the effect of choosing the appropriate
field and
assigning the values the user enters to that appropriate Data Class.
- Addition of Data to an Existing Item
Some user data assemblies are relatively simple - for example, a single entry
in a
bank account is essentially one record - and the assembly of Active Elements
to display it is
also relatively simple. Most of 'a letter' or 'an e-mail may contains data
wholly or largely held
in a single pair of a Data Relation Table records.
Some user data assemblies can become more complex, and 'an address' is a good
example of this. A Visual interface should be able to accommodate the fact
that a single
person may have only one telephone number or ten telephone numbers; he may
have one
location, or three or twenty locations he uses routinely, and even more when
he travels.
Additionally, data assemblies such as 'an address' are not static, but change
over time as
new data gets added. People are individuals, and it is confusing and
unproductive to provide
space on a screen for fifteen telephone numbers for a person who has only one,
and equally
undesirable to provide only one space for a telephone number for a person who
has fifteen.
In essence, the screen should be able to add data display as and when it
become necessary.
Application of the Unlimited Principle requires that whenever one of something
is
entered - one telephone number, for example - there should be a provision to
allow the user
to enter another of that same type of thing - another telephone number for
example.
532
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
A type of Software Module termed the 'Add Another' type takes care of this in
the
manner previously described and can be associated with an individual Active
Element, or
more usually, with a Sub-View. Add Another Modules and the Active Element or
Sub-View
with which they are associated have the following specific behaviors:
1. Add Another Modules are activated by Token by specific Active
Elements that receive data entry. Certain Active Elements are coded in such a
fashion that if they receive data entry, they call a specific Add Another
Module.
2. Add Another Modules introduce either another copy of an Active
Element or of a Sub-View and exactly what they introduce is coded into the
Logics of
the particular Add Another Module.
3. The copied Active Element or Sub-View does not have a Data Relation
Table record opened to receive the user's data until such time as the user
actually
enters data into the Active Element or into one of the Active Elements in the
Sub-
View.
4. When data is received into a copied Active Element or into any Active
Element of a Sub-View copied in this manner, the Active Element Logic or Sub-
View
Controller Logic calls the appropriate Software Module that takes care of that
kind of
data entry, informing it in the Token it sends, that that the needed screen
Active
Element or Sub-View is already open. In other words, the principal difference
between
the first and subsequent Active Element or Sub-Views, is that for the first of
the type,
the Software Module calls its associated Sub-View, which then opens the
appropriate
Active Elements, and that for the second and subsequent Active Element or Sub-
View, an Active Element or Sub-View itself calls that Module's Active Element
or Sub-
View, and informs it that the Active Element or sub-View is already called and
active.
The Software Module that is called, knowing from the Token it has received,
the
record numbers of the Active Element or Sub-View that is now opened for it,
gives
these, the number of the new Record that it opens to receive their data.
5. When an Add Another Module opens an Active Element or Sub-View,
the copied Active Element or Sub-View records exist in memory but are not
recorded
in the Data Relation Table until data entry is actually received. If data
entry is not
received before the item is either left by the user going on to do something
else, or by
the item being sent somewhere, then the records in memory produced by copying
the
Active Element or Sub-View are discarded.
6. When data entry is received into a copied Active Element or Sub-View
and the appropriate Software Module is called, the new records that are now
written
under the control of the newly activated Module are part of the item that is
already
533
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
being created, and may also be part of another item. The Token received by the
called Software Module instructs that the Token be returned to the calling
Module
when the Module is Active, together with the number of the New Record that~it
has
opened. The calling Module supplies this new Record number to its Controller
Logic.
The Controller Logic supplies the Token to the Module that called it, and
continuing in
this manner, the first Module that was activated, receives the New Record
Number
and records appropriate number values in New Record's Sub-Level and number in
the
Sub-Sub-Level field, to make it part of the item being created.
7. The data received from the user may be completely new data - for
example, if a new location name is entered as part of a user entering a
Communication then this new location name is not only part of the item being
created
but is another of - and therefore a part of - the location names for that
person and
need to be related to that person. Active Elements receive data in the users
Spoken
Language and supply this to the appropriate Translation Module. The
Translation
Module, as previously described, finding that no translation exists for the
data received
calls the appropriate New Data Entry Module that enters the data and records
the
necessary relationships for the new data.
8. When the user in the future, edits a previously recorded item, the Field
and Controller Logics of the Interface Elements receiving data entry, call a
Copy
Module that records the existing item as a previous Version, so that the user,
in effect,
edits a copy, not the original. The Sub-View and Active Elements of every type
of
Communication item - e-mails etc - that are used to look at a previously
recorded
item, check the Data Relation Table Status field, to determine if the item has
been
sent, and if it has been sent, de-active all Add Another Module calls. If the
user enters
data into a sent item, or activates a specific Active Element Button - such as
a button
labeled 'Send this to Someone Else?' - that has the same effect, then the
appropriate
Controller Logics inform their Field Logics to check for the presence of data,
and to
call their Add Another Modules, if their Logic calls for them to do in the
presence of
data.
- Addition of Data to an Existing Item
The display of a complex assembly of data - such as an address - is a matter
of the
assembly of:
1. The data itself.
The assembly of the data is stated either:
- tn the Administration fields of the records making up an item,
particularly using the Base Record, Sub Level Number, Sub-Sub-Level, Sequence
534
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
and Data Specification field and record types - this the case for an assembly
of
user data such as 'a letter'.
- Using one the two Data Specification Record types previously
described - either a Data Specification Record or a Data Specification Record
Set.
This is the case for something such as 'an address', where the particular
assembly of data that is labeled as 'an address' can - with the methods of the
Any-
to-Any machine - be slightly or wholly different for every recorded 'address'
or for
any groups of 'addresses'. One 'address' may contain one telephone number
while another contains ~a hundred, one type of 'address' may contain a
photograph
p while another contains the company motto displayed in the place where - in
other
'addresses' - the photograph displays.
2. The Interface Elements to display that data:
- The assembly of Interface Elements to show a particular item is
contained in the View Specification previously described and the Base Record
number of the View Specification is recorded in the View Specification field
of the
Base Record of the data record that is the foundation of the recording of the
data
making up the item. If a number of users use different views of given data,
then
the View Specification in the View Specification field is converted by a
suitable
Software Module into a Data Relation Table record, View Specification type,
that
records the User number of the different users, together with the number of
the
Base Record for the View Specification that each one of them uses.
One of the most powerful data manipulation tools used by humans is naming
things
with names they choose - as previously described, a 'word' is a essentially
also a name for
something - and consequently, one of the methods of the Any-to-Any machine is
to allow and
provide for the user to be able to name anything and everything and 'User Name
for This'
field is used by a Naming - name creation - Software Module to allow the user
to do this. A
name can be a simple, single word name such as 'address' or a more complex
'name' that is
in fact a Specification: 'Joe's old address'. When a name is a simply one
word, the value for
the name can be placed in the User Name for This field; when the 'name' is in
fact a
Specification, then the Naming Module creates a User Name for This Data
Relation Table
record, enters the Specification in the record, and places the record name of
the User Name
for This record in the User Name for This field of the records of the item
concerned. If
several users give a particular item a variety of names, then a User Name for
This record is
created for each user, and the records are grouped using appropriate numbers
in the Sub-
Level and Sub-Sub-Level Administration fields.
535
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
In effect, then, a complex display of data - such as an address - consists of
a named
assembly of data, specified in a Data Specification Record, that is paralleled
by an unlimited
number of matching, identically-named assembly of Interface Elements that are
specified in
the View Specification records and that can be specific to individual users.
Because the Any-
to-Any machine method provides the ability to name a data assembly and its
Interface
Element assembly identically, specifying the name specifies both the data
assembly and the
Interface Element assembly.
A user may equally wish to display on the screen at the same time.any assembly
of
data whatsoever, that is not any pre-existing named item type, and
additionally, it is not
possible to predict the particular combination of data he may choose. In the
state of the art,
such assemblies of Views and Sub-Views data are sometimes referred to as
digital
dashboards in the state of the art.
The term 'View' and Sub-View' are functional terms rather than structural
terms - a
View and Sub-View potentially are both assemblies of Interface Elements that
can be
identical every aspect, are named and are built in such a fashion that they
can have a senior
Interface Element and junior Interface Elements. The only type of Interface
Element that
normally needs no ability to handle junior Interface Elements is an Active
Element itself.
The fact that one Interface Element assembly is termed a 'View' and another is
termed a 'Sub-View' expresses only the fact that as used in the circumstances
described, the
Sub-View is a junior and contained in the View - but the structures concerned
could equally
well function in the opposite roles. Nothing prevents either a Sub-View
containing a Sub-Sub-
View, or a Sub-Sub-View containing a Sub-Sub-Sub-View - etc.
The ability of Interface Element Assembly - such as a View or Sub-View - to be
named, combined. with the Any-to-Any machines methods - previously described -
that
enable a screen layout to be configured without user intervention, enables a
user to see what
he wants to see on the screen at the same time by specifying the name of the
data
assemblies he wants to see together.
Suitable Software Modules can be provided to assemble named Views and Sub-
Views
together when the user specifies their names. For example, a user can give an
order 'Show
me my two standard menu bars, my new messages, my calendar for tomorrow, plus
a graph
of rising sales, and a list of my personal screens'. Assuming that each of the
underlined
items in the above order already exist as named Data Specification record sets
together with
a corresponding View Specification with the exact same name, then the action
of a Software
Module called 'Dashboard' - for example - that assembles these:
1. Creates a View that uses the named Interface Element assemblies as
Sub-Views
536
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2. Gets the user to name the View record and records that name.
Thereafter, the user can see the named view at any time, simply by specifying
its .
name.
- Finding and Display of Data
Circumstances exist under which it is useful far the data being entered to be
able to
choose the View that is to be used to display that data. For example, a Visual
Interface,
although present, may not be used to state the data that the user wants to see
- the user may
enter the statement of what he wishes to see using a Language Processor
without entering
anything else at all into the Visual Interface. Equally a user may enter a
command remotely-
via e-mail or through a telephone and Voice Recognition - and may, as part of
the command,
require that something be displayed for someone who is sitting where the
computer is.
When a user enters data that he wishes to see, two possibilities exist:
1. Either the Specification the user enters specifies a previously existing
item, in which case the item will have a corresponding pre-existing,
identically named
Interface Element Assembly to display it. In this case, two further
possibilities exist:
a. The user's Specification includes the name of the item - ' a
letter from Joe in which...'. In this case the name of the item - ' letter' -
is
identified and the appropriate display is equally identified.
b. The user does not include the name of the item in the
Specification: 'something from Joe in which...' In this case, the user's
Specification will identify one or more items, each of which is related to an
appropriate Interface Element to display it.
2. The user's Specification does not correspond to any pre-existing
selection of data and therefore does not have any pre-existing assembly of
Interface
Elements with which to display it. In this case, a 'New Display' Software
Module uses
default Active Elements to compose the display, and gives the user the
opportunity to
name the new assemblies of data and Interface Elements. A programmer can
provide
a number of pre-configured default Active Elements such that there is one for
each
type of data in a given Data Class.
Occasionally it is desirable to output multiple documents simultaneously, a
function
that is referred to as a binder function in some office applications. In the
Any-to-Any machine,
this is accomplished by a suitably-constructed Software Modules that:
1. Enable the user to assemble the items concerned, either through a
Find Specification, or by the user selecting the items in some other manner,
so that
the documents to be output are identified.
537
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2. Provide additional Sub-Views that act as Headers and Footers together
with Active Element buttons that enable the user to impose these overall
Headers and
Footers either in,preference to those in the selected items, or in addition to
them.
3. Allows the user to add another item to act as first pages for the
selected items.
The overall result of these methods is to enable a computer to control the
display of
data based on the data Specified by the user.
~ METHODS TO ENABLE A COMPUTER TO RECORD THE RELATIONS OF
ANY DATA WITH ANY OTHER DATA: CONSTRUCT ION OF A TYPICAL DATA
RELATION TABLE
In general terms, the methods of the Any-to-Any machine to record the
relationships
of Data Components are neither wholly structural nor wholly logical, but a
combination of the
two. Some relationships of Data Components are recorded by the manner in which
they are
recorded in Data Relation Table records. Other relationships are stated in the
Administration
fields, that largely consist of code numbers stating various types of
relationship and in this
case, the code numbers mean nothing at all in the absence of logic contained
in Fields Logics
and Software Modules that interpret the coding correctly and act on it and
thereby manipulate
the records or fields concerned so as to implement the relationship stated by
the coding. Still
other relationships have no statement or coding in the Any-to-Any machine
tables at all, and
are entirety manipulated by logic contained in Field Logics and Software
Modules and once
manipulated, may or may not subsequently recorded. And example of the latter
is a Find
Specification created by the user. The user wants to find a specific
combination of data and
this combination is entered into a new Record that is recorded as a Find
Specification.
Records are found that match what the user wants to see and in effect, when
those records
are found, and certain fields form them displayed, a relationship has been
created between
the fields that are displayed, simply by the fact of displaying them together.
While the Find
Specification record is recorded, the user may not necessarily name the group
of fields that
were found by it, and once the user quits the Find operation, and the display
is removed, the
relationship that existed structurally a moment ago no longer exists, at least
until the same
Find Specification is run again. Effectively, the relationship exists within
the logic, not within
the structure. However, it should be noted that the Logic is not creating a
relationship as
such, only finding relationships that do exist, whether or not they are known
to exist.
This section described the fields in a typical Data Relation Table, based a
typical,
generic set of Data Classes, such as might be used in building an office type
of application
capable of doing word processing, spreadsheet, presentation and other normal
office-suite
functions.
538
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Method to Number Data Relation Table Fields and Hence Data Classes
As previously discussed, each Data Relation Table field contains data from
only one
Data Class or Data Sub-Class - whether or not the Data Class or Data Sub-Class
has its own
Data Class table. Hence, every field in a Data Relation Table is intrinsically
a Data Class or a
Data Sub Class or Data Sub-Sub Class.
The entirety of the structures and contents of Any-to-Any machine, with the
sole
exception of the contents of Spoken Concept Language fields in Data Class
Tables, consists
of numbers. The 'names' of all tables, all fields, are wholly and solely
numbers, and wherever
names are used in this description for tables, fields or records, these names
are only one of
potentially many names that can be given to each structural entity and occur,
if they occur at
. all, only in the Spoken Concept Language field of a Structural Names Data
Class Table, that
can translate these Spoken concept Language names into Numbers Language names
used
within the Any-to-Any machine structures. If a Structural Names Data Class
table is required,
then it contains fields for Numbers Language Name, Type Name, Sub-Type Name,
Sub-Sub-
Type Name, Sub-Sub-Sub-Type Name. Other fields can be added as useful -
Programmer
Name, Notes, etc, and the table can also be used to hold programmer's
construction notes, if
it is given some Time fields as well. All fields, except the Numbers Language
Name are in
Spoken Concept Language, as they are all information fields and do not need to
be
referenced in the table itself. Names for structures used throughout the Any-
to-Any machine
are all considered to be simply Working Names and represent one of the
possible names that
could be used.
Data Classes - and hence Data Relation Table fields - are not numbered
consecutively, as to do so makes it difficult for later applications built
with the Any-to-Any
machine methods to divide Data Classes or Sub-Classes and still keep them in
their proper
order. Instead, the block of numbers between zero and the largest number that
can be held
by the storage system in which the Data Relation Table is to be constructed is
taken and
divided into six equal blocks of numbers that do not overlap one another.
Doing this allows
one block of numbers to be allocated to each one of the five Data Categories
plus another
block of numbers to be allocated to the Administration fields as a group. Each
of these
blocks of numbers is then divided amongst the planned Administration fields or
Data Class
and Data Sub-Classes that are planned, so as to leave a block of numbers free,
before, and
after each planned field. The unused numbers are then available for additions -
in the case
of Administration fields - or for further divisions of the Data Class or Sub-
Class, in the case of
the Data Categories.
If, at some time in the future, a Data Sub-Class needs to be added, then it is
assigned
one of the unassigned numbers in the block of numbers where its Data Class has
been
539
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
assigned a number. In this manner, a Data Relation Table can, to some degree,
be
expanded into Data Sub-Classes or contracted into Data Class Type fields
without requiring
field numbers to be re-assigned - provided that rigorous discipline is
maintained in the use of
field numbers in different applications and different Data Relation Table s.
While future such additions can be inserted physically into their correct
place in the
Data Relation Table, there is no obligation to do so, as this numbering method
can place
them in the correct logical position.
In the remainder of the Detail Description of each Data Relation Table field
is given a
number, but this number is used for descriptive purposes only; when a Data
Relation Table is
constructed, its fields are numbered as described above.
96) Method For Constructing A Data Relation Table
Each field of a Data Relation Table can have the following structures that
associated
with it, which a programmer creates as useful in order to achieve the purpose
of his
applications:
1. A Data Relation Table Record of That Field Type. These are Data
Relation Table records that are an extension of the field, or contain data
used to
control something about its functioning and are designated by a particular
number in
the Data Relation Table Record Type field.
2. Data Relation Tables Records that are Sub-Types of a Field Record
Type. Data Relation Table records of a particular field type - i.e. with a
specific
Record Type number - can have an unlimited number of different sub-types, as
useful
to achieve the programmers objectives, and such sub-types are identified by a
particular number in the Record Type Field, and another number in the Sub-
Level
field.
3. Data Relation Tables Records that are Sub-Sub-Types of a Field
Record Sub-Type Data Relation Table records of a particular Sub-type - i.e.
with a
specific Record Type number and number in the Sub-Level field - can have an
unlimited number of different sub-sub-types, as useful to achieve the
programmers
objectives, and such sub-sub-types are identified by a particular number in
the Record
Type Field, and a specific number in the Sub-Level field and another number in
the
Sub-Sub-Level field.
The programmer can continue the process creating sub-levels as necessary.
It can also be useful to treat the senior number in one table - for example
the Record
Type number - as the junior number in another Data Relation Table - for
example, as
the Sub-Level number.
540
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
4. Data Class Tables. A Data Class Table can be useful preferable when
translation is needed between a Spoken Concept Language and Numbers Concept
language
5. Data Assembly Tables. Data Assembly Tables can be created as
desirable for a particular Data Class, in order to assembly data before use in
the Data
Relation Table.
6. Software Modules. Many Data Relation Table fields cause, or are key
to or the first step of performing actions, that may, or may not involve other
Data
Relation Table fields. Hence, while a Software Module does not 'belong' to a
particular field, - i.e. it is a Data Relation Table record of the type
'Software Module -
its function can often concern the value in a particular field - i.e, a
particular Data
Class in the first instance. There is no limit to the number of Software
Modules that
can be included in an application. For convenience, when the functioning of a
Software Module does concern a particular Data Class, and can be useful in
relation
to a particular Data Class, its functioning will be described together the
Data Class
concerned.
97) Method For Constructing Data Relation Table Administration Fields
The following descriptions of the construction of each of the Data Classes -
fields - in
a typical Data Relation Table cover special features of each particular field
and are in addition
to the descriptions already given concerning Data Classes, Record types, Data
Assembly
Tables, Data Class tables and Software Modules.
As previously described, a Data Relation Table divides the Data Relation Table
fields
into two main field types: 1 ) Administration fields, that facilitate relating
and controlling Data
Relation Table records containing data and 2)' Data fields, containing user
data and some of
the relationships of user data. The division of a Data Relation Table into
Administration fields
and field that are not Administration fields, is large artificial for the sake
of convenience in
description, understanding and use:
1. Every Administration field has its equivalent in non-Administration
fields.
2. In the purest form, Administration fields together are fields from non-
administration Data Relation Table records, Administration record type, that
have
been removed from the rest of the Data Relation Table, re-labeled so that the
generic
Data Class name is now labeled appropriately to the data to be contained. In
effect,
the Label record for a data entry has been made into the field names for an
the
Administration record, and the Administration record - since it is paired with
a data
record - added onto the front of each data record. '
541
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Hence, there is nothing preventing an Administration record being used to
contain
user data if it is convenient to do so, any more than anything prevents an
Administration
record type from using all non-Administration fields.
The real distinction between the Administration and non-Administration fields
is that
the user mostly does not need to see the contents of Administration fields,
and hence,
Software Modules written for users tend to display the data fields, rather
than the
Administrative fields, which are mainly used and displayed by a programmer.
Some
Administration fields - such as the Record number - are sometimes helpful to a
user and can
therefore be displayed for him, but without providing any facilities for the
user to change their
values.
As previously described, Administrative fields can be constructed as either
their own
type of Data Relation Table record or as a separate, parallel Data Relation
Table, and in
these cases, each and every Data Relation Table record containing the data
itself, is paired
with an Administration Record containing in its fields the data described
below for
Administration fields. Alternatively, Administration fields can be placed as
the first part of
each Data Relation Table record and it is this construction method is
described below.
Administration fields in general can sometimes be combined by combining the
references used in two or more Administration fields into Combined Numbers so
that one part
of the number states the value for a what would normally be one
Administration.field, while
the other part of the Combined Number states the value for the other
Administration field.
This method may be useful particularly for small embedded applications, but is
not the most
desirable method, at least for normal user applications, for two reasons:
1. The Administration fields combined in this manner may run out of available
numbers that can be held in the database or other storage mechanism. This
requires a
Rejuvenate Software Module to be used to make more numbers available. (The
Rejuvenate Software Module will be described later).
2. Such a method can lead to incompatibilities between applications and
consequently require the use of Conversion Software Modules that would not
otherwise
be necessary.
An Administration field contains a specific value, and when one field is not
sufficient to
contain all the required values, a Data Relation Table Record Type, named
identically to the
name of field, is used to contain the preferred values or to contain data that
is used to control
the operation of that field in some way.
542
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
1 ) Field 1 - DATA RELATION TABLE IDENTITY
DATA RELATION TABLE IDENTITY FIELD
The primary purpose of this field is to be a Number field containing the
number of the
Data Relation Table, but when this field is used as a record type, it can also
be used to
describe a Data Relation Table.
Each Data Relation Table has a unique number so that when Data Relation Table
records are communicated by software from one table to another, the Data
Relation Table
that supplied the record can be identified, as will be described.
It is desirable, in order to prevent confusion when records are transmitted
between
one Data Relation Table and another, that every Data Relation Table Identity
Number is
unique. One useful method for constructing a unique number for a Data Relation
Table is to
make use of the fact that a specific time combined with a specific location is
unique - it is not
possible for the same event to occur twice at the exact - identical - time in
the exact -
identical - location. This fact can be used to generate a unique number for
each Data
Relation Table as per the following example:
1. The entire date, hour, minute and second are represented as a
number, e.g. 16.22 pm and 4 seconds and zero hundredths of a second on the
first of
January 1999 can be represented as 1622040001011999.
2. A number in the above form is generated the first time that a Data
Relation Table is activated in a given computer, and used as the first part of
a
Combined Number in which the second part is formed by:
3. The CPU number, or other number identifying the computer concerned
if available. If a CPU number is not available, then a telephone number
belonging to
the person who creates the Data Relation Table, including country code can be
used
instead as no two telephone numbers are identical. Thus if the telephone
number
used is 33 (France) 333 3333, then the Table Identity number can be:
1622040001011999333333333.
One useful method is:
1. The Data Relation Table Identity Number is encrypted, so that one Data
Relation Table cannot falsely identify itself to another Data Relation Table.
2. Once a Data Relation Table has been activated and received its
Identify number, this number is not changed even if the Data Relation Table is
subsequently moved.
3. Every Data Relation Table record created in a Data Relation Table is
automatically marked in the Data Relation Table Identity Number field with the
Identity
Number of the Data Relation Table in which it is created. This is done by the
Field
543
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Logic of the New Record Software Module that creates all new records in the
Data
Relation Table.
The Field Logic in the Data Relation Table Identity Number field in each
Software
Module aborts processing if a Data Relation Table record has no. Data Relation
Table Identity
Number and displays a user message to repair the damaged New Record Software
Module.
DATA RELATION TABLE IDENTITY FIELD, TYPICAL LABELS
Examples of Labels that are typically displayed when displaying the contents
of this
field are Labels~such as 'Identity Number of This Software' or 'Name of this
Software' when
displaying the Data Relation Table's name to a user, or 'DRT 1lD' when
displaying it to a
programmer.
DATA RELATION TABLE IDENTITY RECORD TYPES
Every Data Relation Table, Data Relation Table Identity record type, contains
the Data
Relation Table Identity Number in its Data Relation Table Identity field. Such
records can
contain information concerning the table itself, such as who created it, when
it was created,
where, etc. As with all Data Relation Table records, each individual field of
this record type
can contain any value from the Data Class of the field concerned, or contain a
pointer to
another Data Relation Table record, or contain a pointer to another Data
Relation Table, or
one of any of these.
Sub-types of Data Relation Table Identity Number Records can be used to record
modifications to the Data Relation Table.
DATA RELATION TABLE IDENTITY DATA ASSEMBLY AND DATA CLASS TABLES
Data Classes where the Data Classes contains only Data Components that are
themselves numbers are termed Numbers Data Classes, and the Data Relation
Table Identity
is such a Numbers data Class. All such Numbers Data Classes are extensions of
the Life
Data Category Numbers field, and are simply specific types of numbers.
Numbers Data Classes do not normally require Data Assembly tables - but
equally,
nothing prevents Data Class Assembly Tables being created for Numbers Data
Class if there
are advantages to doing so. Equally, Numbers Data Classes do not normally
require a Data
Class Table, unless the Numbers Language references in the Data Relation Table
field of that
Data Class may need to be viewed in a language in which numbers are
represented by
symbols other than the Number Concept Language symbols in use in the Data
Relation
Table. In this case, a Data Class Table is useful to translate between the two
different
symbols for a given number, but when that is the case, a single data Class
Table can be
provided to translate for all Numbers Data Classes and used by the field
Logics of the
Translation Modules that are translating the Data Class.
544
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Data Relation Table Identity Data Class is norrrially composed only of the
number
of the Data Relation Table itself, and hence there is normally no need to
provide either a Data
Assembly Table or a Data Class Table.
DATA RELATION TABLE IDENTITY DATA CLASS SOFTWARE MODULES
Each Data Relation Table field has a Software Module that handles the
administration
for that field. Many Software Modules may need - for example - to assign a
Base Record
number to the Base Record field in a given record, or to write a record type
number to several
records. When a single action may have to be performed by many Software
Modules there
- are two possible choices:
1. Write the code in the conventional manner, with all the risks that
entails.
2. Write a single Logic to do that single action and then use this Logic
many times in different Field Logics in different Modules. In effect this
means that
many copies of the same code can be in operation simultaneously, and
additionally,
if Software Modules are assembled once only when a Logic is installed or
updated,
then many copies of that Logic have to be stored, taking up unnecessary space.
3. Write a single Software Module that does that action and which is
called by the Field Logics that need that action done. There is no obligation
for a
Software Module to act on many fields, and very often it is advantageous if a
Software Module just acts on a single field. Such a Software Module is termed
a
Software Field Module.
The third method has the following advantages:
1. If a Software Field Module is used, this requires storing only one copy
of the Module's code
2. It is easier to coordinate action between several copies of an identical
Field Module acting on a single field than it is too coordinate the activity
of the very
same Logics that could be embedded anywhere in an unlimited number of Software
Modules. When a Module acts on a specific field - and several copies of that
Module
can be acting practically simultaneously in a large multi-user environment -
it is
relatively easy to write each Module so that:
a. A single Data Relation Table record - termed an Active Field
Module record - is placed in memory,
b. When a Field Module executes, the first thing it does is to write
its own number into its own field in the Active Field Module Record and
activate
the Field Logic for the same field in an Active Field Module Controller Module
that administers the Active Field Module Record.
545
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
c. The Field Module then waits to be told to Execute.
d. The Field Logic of the Active Field Module Controller Module on
being alerted to execute by a Field Module, removes that Field Modules'
number from the Active Field Module record, copying it into the bottom of its
own Buffer stack.
e. The Field Logic tells the Field Logic at the top of its stack to
Execute by sending it a Token.
When a Field Logic receives a token that an Active Field Module
has terminated, it removes that Modules Number from the top of the stack and
sends a Token to the next Field Module in the Buffer stack.
With this method any Field Logic in any Module can call any of the Software
Field
Modules for that field - there is no reason to limit Field Software Modules to
one per field -
and conflicts between Software Modules and storage space are minimized.
Software Modules can be made up largely or wholly from Software Field Modules.
Hence, in the description of individual Data Relation Table fields, it is to
be considered
that at least one Software Field Module exists for each field, and the
description for each field
in respect of Software Modules will only describe Software Moduies that are
related to field -
i.e. are of interest in relation to that field - but whose functioning
generally concerns more
than one field.
Software Modules of particular importance to Data Relation table Identity Data
Class
are Software Field Modules that generate the Data Relation Table's Identity
number, and
check from time to time that all records contain the correct number. The
integrity of the Data
Relation Table is of desirable importance; if corruption occurs in the Data
Relation Table disk
file, all data can be lost, and therefore, in the preferred method of the Any-
to-Any machine,
three copies of all tables, including the Data Relation Table, are in
operation at all times,
preferably on separate disks. All the tables that make up an application are
termed a Tabfe
Set and one Table set operates as the Primary Table Set, with the other Table
Sets operating
as Check Tables. Except for mission critical applications, operations proceed
on the basis of
the reads from the Primary Table Set, and a background Read Compare Software
Module
uses processor idle time to compare the read from the Primary Table Set with
the Check
Table Sets. In other words, operations are not halted until reads from all
Table Sets are
obtained and compared, except in mission critical applications, where it may
be useful to
compare all reads before any action occurs on the basis of them. Instead, in
normal
applications, all operations proceed normally on the basis of the read from
the Primary Table
Set, while making sure, when time is available, that those reads were correct.
In the same
manner, all writes to the Primary Table Set are immediate white a Write Check
Software
546
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Module does writes to the Check Table sets when time is available. Three
copies of the
Table Sets may be kept on separate disks with separate controllers - this
method is preferred
to using Raid controllers, since these suffer from the problem that if the
Raid controller itself
has a problem data can become unavailable even if the disks themselves contain
correct
data.
During periods of idle time, such as at night or when the machine is shut
down, a Full
Compare Module checks all records in all Table Sets and writes a Full Compare
record type
to state its activities and the latest record number that was checked.
In the even that Read Compare finds a difference between the three reads then
the
Read Compare Module uses a Condition records in the standard manner to
determine the
Condition that exists, and the Companion Director Recordfs to take the
appropriate action.
Generally, if two reads are the same and one is not, then Table giving the
dissimilar read is
repaired by a Repair One Madule. In the event that the Table Set giving the
dissimilar read is
the Primary Table Set, then the Repair One Module redirects all activity to
one of the other
Table Sets, in effect making it the new primary table Set. In the event that
all three reads are
different, then a Repair All Madule is used., and performs the following
actions:
1. The user is informed that all three disks are reading differently and
work should be suspended for a few moments while the problem is resolved.
2. If the Repair All Module's Condition records detect that the error has
p occurred in a record number higher than the last record checked by the most
recent Full Compare, then Repair All launches Full Compare using a Taken to
tell
it to do a full compare on all records since the last record previously
subject to a
Full Compare. If the Condition record comparison shows that the error occurred
in
a record that was already fully compared, then the whole table set should be
checked.
3. Where the Repair All Module detects a difference between records, it
uses suitable View to show the user the differences. Since Sub-Views do exist
for
given user data records, the Repair All uses a View composed of three
identical
Sub-Views, each one showing the same record as read from a different disk.
The user is encouraged to set up a daily off-site backup of the Primary Table
Set
using the Internet or another computer and a Backup Module that writes a
Backup record
stating the details of the backup and the latest record number that was backed
up. Because
of the nature of the Any-to-Any machine, this is not complex, and simply
requires transmitting
the new records created since the last backed-up record in the Backup Record,
and a
Software Module at the receiving computer that copies the received records
into the Backup
Table Set.
547
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Note that with these methods, while a data recording error can occur, such an
error
cannot develop very far. before it gets detected and corrected, with the
result that the potential
damage is quite limited, and the repair time therefore required is short.
Further Software Modules associated with this field are the Pack-up type
Software
Modules that copy all the user's records and software to another machine -
either over an
electronic connection or to removable media, preparatory to moving permanently
elsewhere.
Such Moduies may or may not include deleting the previous installation, once
the Full
Compare Software Module has checked the copy.
Software Modules with this Data Class also take care of dual-site operation of
a single
application, such as a user who operates with both a fixed machine and a
portable device
such as a portable computer. All operations performed with the methods of the
Any-to-Any
machine consist uniquely of new records, as an existing record is not changed.
Supposing
then that the user is in operating with a fixed machine in a multi-user
environment where
many users are using the same application, and wishes also to operate with a
portable that
has not so far been used but is connected to the multi user environment, then
the user may
operate his portable unconnected to the multi-user environment are as follows:
1. A Transfer Out Software Module in the main application copies its
original, first install version over to the portable, together with a Transfer
In Software
Module.
2. The Transfer Out Module sends a Token to the Detect Module that was
copied into the portable as part of the first install version, that detects
the physical
parameters of the computer - screen resolution, storage etc.
3. The Transfer Out Module sends a Mark Junior Software Module to the
portable that marks - in their Seniority field - all new records that will be
created in the
portable as junior to the senior application sending the Mark Junior Software
Module.
4. While the Detect Module is busy on the portable, the Transfer Out
Module presents the user with View enabling him to state the data he wants to
have
available on his portable and the things he wants to be able to do -
effectively thereby
specifying the Find Specification for both data.records and Software Modules
that
need to be copied to the portable.
5. The Transfer Out Module copies the records and all Data Assembly
and Data Class tables, which the Transfer In Module stores in the portable.
6. The Transfer Out Module calls a Make Module List Module that creates
Data Specification record listing all the name of the Modules to which the
user had
access, that are not transferred to the portable, and copies these Module List
records
to the portable.
548
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
7. The Transfer Out Module writes Transfer records that record the last
record number of record that was copied to the junior = portable - machine,
meeting
the user's Specification.
8. The Transfer Out Module creates an If Not Found record that it adds,
using a Token to the portable's Find Module, with the effect that if the Find
Module on
the portable does not find something, the first place it tries to find the
missing data is
on the user's main machine and only if that fails, does it look elsewhere.
9. The user is then free to work on the portable and all work he does is
recorded in terms of new Records.
10. When the user re-connects his portable to the network at some future
time, the action of doing so activates a Synchronize Junior Module in the
portable and
a Synchronize Senior Module in the network machine that between them:
a. Re-write all the new records in the portable into the senior as
new records.
b. Overwrite the portable's new record numbers with the record
numbers assigned by the senior application.
11. When, in the future, the user.again wishes to work on his portable away
from his main machine, the Update Transfer Module asks the user for any
changes in
the Modules and data he wants available, and, using the users instructions,
plus the
previous Transfer records, transfers anything missing from the user's machine.
With these methods, working on junior and senior machines is a matter only of
copying the appropriate records, and hence, keeping different computers up to
date is a
relatively transparent process for the user.
2) Field 2 - SUB-DATA RELATION TABLE IDENTITY
SUB-DATA RELATION TABLE IDENTITY FIELD
Similarly to the Data Relation Table Identity field, the Sub-Data Relation
Table Identity
field is primarily a Numbers Data Class, and all remarks for Numbers Data
Classes apply.
As described previously, a Data Relation Table may, in certain applications
desirably
be divided into a main table and a number of subsidiary Data Relation Tables.
If so, then
each subsidiary Data Relation Table is assigned a Sub-Data Relation Table
Identity Number
in the Sub-Data Relation Table Identity field, and this number is also a
unique number
generated in a similar manner to that described above for generating a Data
Relation Table
Identity Number, and is used in a similar manner. When Sub-Data Relation
Tables exist for a
given Data Relation Table, then:
1. All records that are in the senior Data Relation Table have the Data
Relation Table Identity number repeated in the Sub-Data Relation Table
Identity field,
549
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
white records that are in the junior Data Relation Table contain that table's
Identity
Number in the Sub-Data Relation Table Identity field.
2. The unique identity of a given Data Relation Table operates on the Co-
Reducing Concept Principle by the combination of the values in the two fields:
a) The
value in the Data Relation Table Identity field and the value in b) the Sub-
Data
Relation Table Identity field.
SUB-DATA RELATION TABLE IDENTITY FIELD, TYPICAL LABELS
Examples of Labels that are typically displayed when displaying the contents
of this
field are Labels such as 'Sub-identity Number of This Software' or 'Sub-Name
of this
Software' when displaying the Sub-Data Relation Table's name to a user or 'Sub-
DRT I/D'
when displaying it to a programmer.
SU8-DATA RELATION TABLE IDENTITY RECORD TYPES
The Sub-Data Relation Table Identity Record Type and any sub-types can be used
to
record data of the same type as the Data Relation Table Identity Record Type
and its sub-
types, but with respect to information about the Sub-Data Relation Table.
Additionally,
particular uses for Sub-Data Relation Tables records are to:
1. Record sub-types that state where a junior Data Relation Table record
is to be found, what it is named, which user named it etc.
2. Record sub-types concerned with archiving data. Any-to-Any machine
methods for handling data that is excess to current needs will be described
later, but
one method is to archive Data Relation Table records in a Data Relation Table
that is
a format copy of the parent Data Relation Table and then to designate such
Data
Relation Tablets with particular numbers in the Sub-Data Relation Table
Identify
Number field. If this method is used, a number of options exist, such as
retaining
base records in the main Data Relation Table, and all other records concerning
an
item in an Archive Data Relation Tables, identified by particular numbers in
the Sub-
Data Relation Table Identity Number field and in this case, the Sub-Data
Relation
Table Identify number in the base record is used to activate a Virtual Record
Converter Module that uses the Sub-Data Relation Table Identity Number to find
the
3Q remaining records in the correct Data Relation Table.
SUB-DATA RELATION TABLE IDENTITY DATA ASSEMBLY AND DATA CLASS TABLES
Similarly to the Data Relation Table Identity Data Class, the Sub-Data
Relation Table
Identity Data Class is a Numbers Data Class and hence, a Data Assembly and
Class Tables
are not normally required but can be used if there are advantages to doing so.
550
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
SUB-DATA RELATION TABLE IDENTITY DATA CLASS SOFTWARE MODULES
Software Modules of particular importance to this Data Class are Modules that
generate the Sub-Data Relation Table's Identity number, check from time to
time that all
records contain the correct number and re-assign Sub-Data Relation Table
numbers to Data
Relation Table records when required.
3) Field 3 - SENIORITY
SENIORITY FIELD
Similarly to the Data Relation Table Identity field, the Sub-Data Relation
Table Identity
field is primarily a Numbers Data Class, and all remarks for Numbers Data
Classes apply.
The main purpose of the Seniority Data Class is to enable different
Seniorities to be
able to be set for Data Relation Tables and Software Modules, and this is
particularly useful
when one application - one Data Relation Table - is to receive and execute
orders from
another one. Nothing is worse that the junior who accepts orders from anybody,
and while
two Data Relation Tables may be authorized to interchange data between one
another, this
does not necessarily mean that a Data Relation Table should execute any
Software Module it
receives, and hence this field allows the user to establish which Data
Relation Tables can
execute orders received from another Data Relation Table without requiring
user permission.
Consequently, the value in a Seniority field states the seniority of a record
in relation
to records in other Data Relation Tables and is generally recorded in every
record generated
by a given table.
Additionally, the seniority applies primarily to Data Relation Table tables
but also to
people. For example, the boss of an organization can be entitled to order
anything to anyone,
yet nevertheless be using, at least temporarily, a junior Data Relation Table
that has no
authority at all to order any other Data Relation Table without human
approval. Hence, the
number recorded in a Seniority field is a Combined Number, one part of which
applies to the
Data Relation Table itself, the other part of which applies to the user. The
Combined Number
enables suitably written Software Modules to obtain data on whether one person
can order
another directly, or whether the order needs to go through a senior for
authorization first, and
route it accordingly, etc.
3O SENIORITY FIELD, TYPICAL LABELS
Examples of Labels that are typically displayed when displaying the contents
of this
field are Labels such as 'Senior Computer Number' or 'Junior Computer Name'.
When
labeling fields showing organizational positions labels can be used such as
'Boss' 'Juniors' or
'Head of Department' Department Staff'.
551
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
SENIORITY RECORD TYPES
Seniority Record types can provide lists of seniorities, information about
seniorities
etc. Seniority records provide a mechanism, by which the organizational
structure of Data
Relation Table s can be recorded, and equally whereby organizational
structures of humans
can also be recorded, and there are a number of possible ways to do this. For
example, a
Seniority records can be used to list the User Numbers of all the juniors
reporting to a given
user and these can be used by a suitable Software Module to construct a
Organization Chart.
SENIORITY DATA ASSEMBLY AND DATA CLASS TABLES
Seniority Data Assembly and Data Class Tables can be created as desired.
SENIORITY DATA CLASS SOFTWARE MODULES
Software Modules associated with the Seniority field generally handle matters
to do
with 5eniorities. In example previously described where a portable is used,
Software Modules
of this type ensure that the correct Seniority is ascribed to.the portable's
records.
Data Relation Tables can be named, like everything else in the Any-to-Any
machine,
and in the case of a Data Relation Table this name is recorded in the Data
Relation Table's
own record - i.e. a record of the Data Relation Table Identity type. Hence a
suitable
Software Module and its Sub-View can enable a user to arrange seniorities both
of Data
Relation Table s and of people, simply by arranging the names with a specific
Spatial Data
Relation Statement that the Software Module then uses to record the correct
relationships.
A particular use for Modules associated with this field is to rejuvenate the
Tables in the
application. The Any-to-Any machine contains methods, which will be described
under the
heading Durability (of data). However, despite the mechanisms described there,
a time may
come when the Data Relation Table runs out of available numbers Because of
this possibility,
all applications should be provided with a Number Check Software Module that
from time to
time checks the highest numbers in use in the Data Relation Table. Using the
Use Count and
Administration Time fields, the closer the Data Relation Table comes to
running out of
available numbers, the more frequently it checks. A Number Check Module is
provided with a
Condition record / Director Record pair and when the Data Relation Table is
about to run out
of available numbers it launches a number of Software Modules collectively
termed
Rejuvenate Software Modules (that could equally well be termed Sleep Modules).
The
Rejuvenate Modules:
1. Uses a Sub-View to obtain a time from the user when it can close the
computer to operations, and at that time, copies the Data Relation Table.
2. Activates any Durability Modules. These will be described under the
Durability field, but have the effect of removing records that are
superfluous, such as
552
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
early unused versions of documents that were simply early versions used in the
preparation of a document, and has the effect of removing a considerable
number of
records from the Data Relation Table. Rejuvenate count the quantity of records
remaining after the Durability Modules have finished work and based on their
Condition records, either copy the Data Relation Table as described below, or,
if
enough space now exists, simply proceed with renumbering it, also as described
below.
3. Makes a list in a temporary table, using the Last Use field, starting
earliest first, of enough records calculated to by the Rejuvenate Module to
allow for a
further six months or one year's operation, eliminating from this list any
records that
have been accessed during the last 6 month period. This list is termed the
Unused
List.
4. Checks through all other records one at a time, to find records that are
not on the Unused List, which refer to a record that is on the Unused List.
When it
finds a record that does frequently reference a record on the Six-Month Unused
List it
removes it from that list.
5. When it has finalized the Unused List in this manner, it then makes a
Used List - i_e. the list of records that will be kept in the new copy of the
Data
Relation Table.
6. It then deletes all records remaining on the Unused List in the new copy
of the table.
7. It re-numbers the remaining records in the Data Relation Table copy
starting from the earliest record and working forwards. This is possible
because all
records are in the order of their creation, and hence a later record can only
refer to an
earlier record.
8. It tests the copy Table by making a copy of it, by removing the latest
half of it to another temporary table, and re-running all user orders and
Table orders
that were executed, and checking the records produced against the records it
removed to the temporary table to ensure they are identical.
9. When the copy Table has tested as correct, it deletes the Used List
records from one copy of the original Data Relation Table and renumbers the
Seniority
field of the remaining records in the old Data Relation Table with a digit
that effectively
labels that Data Relation Table as the older Data Relation Table. However, it
does not
delete any Find Modules in the older table, as these may be needed in the
future.
10. It writes Rejuvenate records stating the date of the most recent record
removed.
553
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
11. It activates a Converter Module that, when user data is not found,
converts the Find Specification records - by adding the digit to them that was
placed
in the Seniority Table to label the older Data Relation Table - and supplies
it with a
Token to the Find Module in the older table. If the records are found there,
another
Converter Module converts them and copies them into memory. For use by the
Find
Module that originally was looking for them.
12. A programmer may choose to add a Module that, in parallel with the
above operations, checks with the user with a Prompt 'could this have been
over X
months / years ago?' where X is the date recorded in 9 above.
13. After some time in operation without faults, the Rejuvenate Module
deletes the other copies of the older Data Relation Table.
When a further Rejuvenate becomes desired, the partially filled older Data
Relation
Table is used for records being removed. When space no longer exists in that
Table, the
Rejuvenate Module generates a further Data Relation Table and then re-assigns
codes in
their Record's Seniority fields to reflect the correct seniority of the
different Tables. Since
each table can search the preceding table, it is possible to recover the
earliest recorded
information.
In this manner, the Data Relation Table operates similarly to a person, who
has a
great deal of data readily available, but may take more time to remember older
data; in the
case of the Data Relation Table, this translates as the additional time to
perform a second or
further Find operations.
4) Field 4 - RECORD
RECORD FIELD
The Data Relation Table record field is a Numbers Data Class field whose
primary
purpose is to hold the number for each record in the Data Relation Table in
the standard state
of the art manner and hence, this field in a record contains a unique
consecutive number for
that record in the Data Relation Table. Whenever a new record is added, this
number is
increased by one, so that if the highest record number so far created is 5,
then the next
record to be created will be numbered 6 in the Data Relation Table Record
Number field.
3O RECORD FIELD, TYPICAL LABELS
Examples of Labels that are typically displayed when displaying the contents
of this
field are Labels such as 'Data Relation Table Record Number' or 'Record
Number'.
RECORD, RECORD TYPES, DATA ASSEMBLY AND DATA CLASS TABLES
The Data Relation Table Record Data Class field is unique in the Data Relation
Table
in having no record of its own sub-type, as while the number of any Data
Relation Table
record can be repeated any number of times, its number in the Data Relation
Table Record
554
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
field needs to be unique. NormaNy, there is no requirement for a Data Relation
Table Record
Number Data Class Table. However, Data Class and Data Class Assembly Tables
can be
used if desired. Because of the many ways in which a specific record number
can be used, it
is not desirable to allow record to be deleted under any circumstances, much
as accounting
procedures do not allow an accounting entry to be deleted once made - a
further entry may
be used to correct a wrong entry, but the original entry remains. Records may
however, be
marked as Inactive or Active using the Status Administration field.
RECORD SOFTWARE MODULES
When a new Data Relation Table record needs to be created, this is done only
by the
New Record Software Module. The reason for this method is that when a New
Record is
created, data usually needs to be written in at least one of its fields - such
as the name of the
action being done. If the procedure for creating new records and writing the
initial data they
require is confined to one Software Module, then the code to do this only
should be written
once and used in one Software Module. If a Software Module that does the
functions just
described for the New Record Software Module does not exist, then every
Software Module
-should contain code to do these actions. If every Software Module is written
so that it can
itself do every action that it might require, the end result are the problems
described in the
Summary, due to many instances of the same or similar code existing in many
places in the
software.
Other Software Modules associated with this field take care of maintaining the
integrity
of record numbers. Field
5) Field 5 - RECORD TYPE
RECORD TYPE FIELD
Many different types of Data Relation Table can exist and these include:
1. One record type corresponding to each Data Class
2. One record Sub-Type in corresponding to each field in each record
type. If there are 150 fields in a Data Relation Table, then 150 x 150 record
types,
i.e. 22,500 record types and sub-types are possible. Each record type is
assigned
its own reference number and it is this number that is entered in the Record
Type
Field.
A primary and desirable division in the record type field as it concerns data
from the
user, is between the data that is an order given by the user and data that is
simply to be
recorded and the reason that this is desirable is that the full, uncompressed
meaning of many
words changes very radically if the word is used as an order compared to when
it is used in
the course of recording information. Accordingly, when assigning record type
numbers the
programmer should pay attention to assigning a particular identifying digit to
records that
555
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
contain user orders, as opposed to records that contain user data. When only a
Visual
Interface is in use the chances of confusion are relatively small but when a
Language
processor is used, not in used the Language Processor should be able to state
whether the
data it is putting in a new record is an order to be executed, or simply data
to be recorded,
and a distinguishing digit in the Record Type number is one way of enabling a
Language
processor to do this.
RECORD TYPE FIELD, TYPICAL LABELS
Examples of Labels that are typically displayed when displaying the contents
of this
field are Labels such as 'Data Relation Table Record Type Number', 'Record
Type Number',
or, if there is a Data Class and the Record type has been named, the name of
the type is
displayed as a label for a single record, or when displaying many records of
one type.
RECORD TYPE, RECORD TYPES
A use of this type of record is to hold a description of the particular type
of record and
in this case, the Record Type field points to the record number of the Record
Type recordls
holding the data.
RECORD TYPE DATA ASSEMBLY TABLE
A Data Assembly Table can be used to state specific information about each
record
type, stating who created it, containing a Content field to describe that
record type etc.
RECORD TYPE DATA CLASS TABLES
The Record Type Data Class Table may contain one field for the reference
number of
each Record Type in use (i.e. the Numbers Language Data Component) and a
second field
for the Name of the Record Type (i.e. the Concept Language Translation of that
Numbers
Language number).
RECORD TYPE SOFTWARE MODULES
Modules of this type are mainly required to take care of administration of
Record
Types, and Record Type Data Assembly Tables.
6) Field 6 - SUB-LEVEL
SUB-LEVEL FIELD
The Sub-level field is used together with the Record Type field - and with the
next
field, the Sub-Sub-level field - to provide a large number of possible Sub-
Types (and Sub-
Sub-Types within that Sub-type) for any given type of Data Relation Table
record. if the Sub-
Level field is used in coordination with the Record Type Number for user data,
then different
Sub-Level Field numbers can be used for user data falling into different Data
Categories such
as data concerning a person (Data Category Life), a person's Locations (Date
Category
Space) etc. A similar numbering method for Sub-Levels Numbers may be used to
that
outlined for Data Classes themselves, so that numbers initially required in
the first application
556
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
to be built are distributed evenly throughout the available numbers. It is not
obligatory for any
record to have a Sub-Level number - many user data records do not require
them. However,
they can be used as one way of grouping records as already described, and are
useful for
fixed groups such as those making up Software Modules or particular items.
SUB-LEVEL FfELD, TYPICAL LABELS
When displaying values from a Sub-Level field the value in the Record Type
field can
be used to label the fields displaying the Sub-Types for that record type.
SUB-LEVEL RECORD TYPES
If a Data Relation Table with a large number of applications runs out of Sub-
Level
numbers, then some numbers can be used to point to Sequence Records containing
a list of
a new set of sub-level numbers. The effect of doing this is to insert an
intermediate Sub-
Level, between the Sub-Level Number and the Sub-Sub-Level. Sub-Level Sequence
records
can also be used as lists of Sub-Level Numbers or Sub-Sub-Level numbers that
are part of a
particular Sub-Level
SUB-LEVEL RECORD DATA ASSEMBLY AND DATA GLASS TABLES AND SOFTWARE MODULES
Normally a Data Assembly Table is not required, but in a typical
implementation, a
Record Sub-Level Data Class Table exists, containing one field for the
reference number of
each Sub-Level number in use; and a second field for the Name of the Sub-Level
Record
Type. Other fields can be added, for example, a Content field to contain a
description of that
record sub-type. This is allowable as effectively, the data contained in the
Data Class table
described the data component - i.e. the Sub-Level Record type. An option for a
programmer
is to further expand the Record Sub-Type Data Class Table into a full, but
separate Data
Relation Table, as previously described. Software Modules for this field are
principally those
used to show and administer Sub-Level record types.
7) Field 7 - SUB- SUB-LEVEL
5UB-SUB-LEVEL FIELD, TYPICAL FIELD LABELS.
This field is a numbers Data Class with the primary purpose of allowing the
programmer to designate Sub-Sub-types of record Sub-Types.
Any Record Type that is assigned a Sub-Level Number can also be further sub-
divided into as many Sub-Sub-Types as the largest number that the storage
mechanism can
hold in one field. Supposing that the fields Record Type number, Sub-Level
number and Sub-
Sub-Level number are all configured for a 32-bit number, then the maximum
number of Sub-
Sub-types of records that can be created is:
32-bit number x 32-bit number x 32-bit number
In many cases, particularly where a number of Modifier Records from the Life
Data
Category are used, it is useful to relate the Modifier records to the Data
record that is
557
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
modified and this is achieved by giving the record the same number in the Sub-
Level and
Sub-Sub-Level fields as the record that is modified, while the Modifier
record's number in the
Record Type distinguishes it as being a Modifier.
Otherwise, the description,given for the Sub-Level field and field labels is
application
to the Sub-Sub-Level Data Class taking into account the nature of the
differences between
the two Data Classes.
SUB-SUB-LEVEL RECORD TYPES
As previously described, such records can be used to describe or contain data
to
control the Software Module operation on data of that record type.
The Any-to-Any machine provides a method for programmers to match data and
software Modules by assigning both the same number in either the Sub-Level
field or the
Sub-Sub-level field or both. Thus, while data and Software Module can be
separated using
the Record Type Number, they can be associated using Sub-Level and/or Sub-Sub-
Level
fields.
SUB-SUB-LEVEL DATA ASSEMBLY AND DATA CLASS TABLES AND SOFTWARE MODULES
The same description applies as for the Sub-Level Data Class, but as relation
to the
Sub-Sub-Level Data Class.
Further Sub-Level fields can be added and used if desired, following the
methods
described above for the Sub-Level and Sub-Sub-Level fields.
8) Field 8 - BASE RECORD
BASE RECORD FIELD
It is frequently useful to know which is the first record in any one series of
Data
Relation Table records or to know where an Item begins. For example, the first
entry of a
person's name may be used as a base in which to assign him a User Number and
from which
to relate Data Relation Table records containing facts specifically concerning
that person - for
example, the collection of facts that is often termed his 'addresses.'
Similarly, if a Language
Processor is in use, it is useful to be able to find quickly which is the
first Data Relation Table
record in a series that records given content - for example, the beginning of
a book.
A number of ways exist to use the Base Record field, at the programmer's
discretion.
For example, the Base Record can be used as a Combined Number field where a
single digit
- 1 for example - indicates that the record concerned is a Base Record, and
then the
presence of that ingle indicative digit designates a Base Record, making
possible to locate
any base Record more rapidly. In a refinement of this procedure, the field can
be also be
used to state the last record in a given series also. Alternatively, or
additionally, Base
Records can be numbered in a continuous series, so that Base Records can be
sorted in per
their number.
558
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
BASE RECORD FIELD RECORD TYPE
Base Records, like every record type derived from a specific Data Relation
Table field,
state something about that field and consequently Base Record type records can
state data
about the Base Record Field, or, are used in controlling how it is used.
When a value in a record's Base Record field designates that record as a Base
Record, it essentially also designed the item for which it is the base record,
and because of
this, Base Record, record types can be used to state something about the
entire item, such
as a description of it. _
It has already been stated that a Data Class field - i.e. a Data Relation
Table field -
can have a record of its own type, and hence the Base Record Data Class !
field can have a
Base Record, record type. It has also been stated that every Data Relation
Table record
contains all Data Relation Table fields and hence a Base Record, record type
contains all
Data Relation Table fields, including - for example - the Condition field.
The Condition field - in a Base Record, record type - can either have a value
stated in
its field, or - just like every field - be extended into its own record type
(and Sub-types and
Sub-Sub-types) and hence become an entire Data Relation Table record - each
field of which
can again be extended into its own type.
Supposing that the Condition field - in the Base Record, record type -
contains a
statement of when that Base record, record type is valid, then a virtual
infinity of control is
possible with which to state the validity of that single Base Record, record.
The same infinity
of control is possible for every field and every record in a Data Relation
Table.
BASE RECORD DATA ASSEMBLY AND DATA CLASS TABLES AND SOFTWARE MODULES
A Data Assembly and Data Class Tables are not normally required but a Software
Field Module normally is required to handle the administration for the field.
9) Field 9 - AND V
AND V FIELD
'AND V' is a short form for: 'AND VERTICAL'. The primary purpose of AND V
fields is
to contain the record number of a Data Relation Table record that follows
vertically onto
another record, or is a branch in a series of Data Relation Table records.
When language is represented in terms of Data Relation Table records -for
example
by a full Language Processor - part of the Any-to-Any machine method for doing
so are the
four 'AND' records - AND V, AND V WAS, AND H, and AND H WAS, where V stands
for
Vertical, and H for Horizontal, and 'WAS' is a way of stating that the
previous record WAS
record number X and 'AND' is a short way of stating that the next record is
record number Y.
The four types of AND field, sometimes together with the assistance of a
Sequence and/or
559
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data Specification record, are sufficient to state the structure of the
thoughts expressed in a
spoken language.
The AND V field is used differently depending on the type of record in which
it used:
Spreadsheet Records. The AND V field in the Base Record in a given
set of records - that, in the state of the art would be termed 'a Spreadsheet'
- states
the number of the next record containing the next block of 'spreadsheet cells'
that are
to be displayed vertically below the record in question - i.e. the 'cells'
that are
attached below 'cells' in the Data Relation Table record in question. _
This method allows 'a spreadsheet' to be any size vertically, and removes the
distinction made in the state of the art between 'a table' and 'a spreadsheet'
'a tabular
database display'. With AND V field ail and any of these 'tabular format'
displays can
be used to perform any calculation, or display any data - such as a page of
thumbnail
photographs, or a Table of Contents or an Index.
2. All other Data Relation Table records. In this cases the word 'Vertical'
is not used in such a literal sense, but is used to mean ' the record that
starts a branch
of the WHOLE OF the Data Relation Table record concerned. If the branch
concerns
only a particular field, then a Branch Field is used instead.
AND V FIELD, TYPICAL LABELS
An example of Labels for the AND V field is the row numbers for a spreadsheet
record; these are treated as a Label record and displayed by Active Elements
as desired.
However, while formulas may be displayed showing the customary row numbers and
column
fetters - both of which are treated as Label records - the formulas themselves
are not
recorded in this manner but as relationships between Data Relation Table
record numbers
and field numbers.
AND V RECORD TYPES
In addition to other uses - for example, stating calculation orders - when
more than
one record is joined vertically to another - i.e. multiple record numbers are
needed in the
AND V field, then an AND V Record Types can be used as a Sequence record to
state the
numbers of all other records that are joined to it Vertically.
3O AND V DATA ASSEMBLY AND DATA CLASS TABLES AND SOFTWARE MODULES
The requirements for a Numbers Data Class apply.
10) Field i 0 - AND V WAS
AND V WAS FIELD
The AND V WAS field is the companion field to the AND V field. The AND V field
in
record number X states that record that is joined to it vertically is record
number Y, while the
AND V WAS field states that the record number to which that record is joined
vertically is
560
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
record number X. Hence if there is one record with an AND V number in it,
there is at least
one record with an AND V WAS number in it.
However, while a record number X with a value in its AND V field has at least
one
record with its record number X in that record's AND WAS V field, the number
of AND WA5 V
records is not limited. In other words, one record with a value in its AND V
reference in it can
have many records that are connected to it and therefore contain its number in
the AND WAS
V fields; colloquially, one parent AND V record can have many children AND WAS
V records.
Additionally, a record that has a value in its AND WAS V field and is
therefore the
'vertical child' of another record, can be the AND V record for another record
or records.
Hence its AND V WAS field can state the record number to which it is a
'vertical child' while
its AND V field states the record number to which it s a 'vertical parent' and
in this manner an
unlimited number of records can be joined to one another vertically, and these
do not have to
be in the same sequence.
AND WAS FIELD, LABEL TYPES, DATA ASSEMBLY AND DATA CLASS TABLES AND
SOFTWARE MODULES.
The description given for the AND V field is applies, but in relation to the
AND WAS V
field.
11 ) Field 11 - AND H
AND H FIELD
AND H stands for 'AND HORIZONTAL'. These fields contain the record number of a
Data Relation Table record that follows onto, or is the opposite member of a
pair of Data
Relation Table records. The field is used differently depending on the type of
record in which
it being used:
1. Spreadsheet Records. The AND H field of the Base Record in a given
set of records that is, in the state of the art, termed 'a Spreadsheet' states
either:
- The number of fields - equivalent to columns - being used in the
'spreadsheet' if these are less than the number of available data field in the
Data
Relation Table in use, or
- The Number of the next Base record that it the first row in the next
horizontal block of columns of 'spreadsheet cells' that are to be displayed
horizontally -i.e. attached to the right-hand side of the columns in the Data
Relation Table record in question.
The AND H field of last Data Relation Table record to be added
horizontally, also contains the number of columns being used and displayed by
its
561
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
record - if that number is less that the number of available data fields in
the Data
Relation Table record in use.
This method allows 'a spreadsheet' to be any size horizontally, and removes
the distinction made in the state of the art between 'a table' and 'a
spreadsheet'. With
this method, both are placed by 'tabular format' that can be used to perform
any
calculation, or display any data - such as a page of thumbnail photographs, or
a Table
of Contents or an Index.
2. General User Data Records. In this cases the word 'horizontal' is not
used in the literal sense, but is used to mean ' the record that contains the
directly
following part of the data recorded in this record.'
3. Communication Records. In this case, the following 'Horizontal' record
(of which there can be more than one) records the data concerning the other
side of
the communication - i.e. the data concerning the other person or people in the
communication to whom the communication is sent, or from whom it was received.
In
the case of communication, the user's data may be recorded in the AND H record
-
and the other person or people in the communication, in the AND WAS H record.
AND H RECORD TYPES
In addition to other uses - for example, stating calculation orders - when
more than
one record is joined horizontally to another- i.e. multiple record numbers are
needed in the
AND H field, then AND H Record Types can be used as a Sequence record to state
the
numbers of all other records that are joined to it Horizontally.
In the case of multiple communications with a single content far example,
there is one
AND H record, and a potentially a large number of AND H WAS records, each of
which
describes fully the facts about who the communication was sent to, when, how,
etc, but
despite this, the Content itself - which is normally the bulk of a
communication - is only
recorded once, in the Content field of the AND H record. The fact that may be
sent by many
different methods to the different addressees is recorded and known, since the
AND H WAS
record contains the send method used for each addressee.
Hence, visually arranging a screen to display a multiple communication - the
same
communication to many addressees, is basically a question of arranging a
screen to display
initially, one AND H record and a corresponding AND H WAS record. As the user
enters data
into what is actually and the AND H record, an Add Another Module opens and
displays
another AND H record, enabling the user to add another addressee, and the
procedure can
continue without any limit.
. If the user specifies a group to which to send a communication, then the
Translator
Field Logic that is behind the addressee field, detecting that it is getting a
group name and
562
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
not the name of a single addressee, calls a one of a type of Module termed
Exceptions
Modules. Exceptions Modules use a Sub-View to allow the user to temporally
remove
something from a group, in this case to remove specific addressee names a
group of
addressees for the purposes of that particular communication. Exception
Modules should
also provide facilities for the user to give a group name to those that are
left in the group after
the Exceptions have been made. When the user is finished with the Exceptions
Module, the
Exception Module:
1. Supplies the group Name to the Translator Field Logic together-with an
over-ride code that tells it to translate it anyway.
2. Enters an Active Element into the Sub-View after the group name,
displaying a Label such as 'Except for the following'
3. Opens AND H WAS records for each member in the group
4. Turns off the display for all group members except those that are
Excepted
5. Turns on the display for the group members that were Excepted
6. Sets the Exist field to negative for the Excepted addressees, so that the
communication does not execute for the Excepted addressees.
In effect then a multiple communication to many addresses consists of one
record for
the sender, plus one record for each addressee, and one recording of the
content.
AND H DATA ASSEMBLY AND DATA CLASS TABLES AND SOFTWARE MODULES
The same description applies as for AND V records but in relation to records
that are
joined 'horizontally' instead of vertically.
12) Field 12 - AND H WAS
AND H WAS FIELD
The AND H WAS field bears a similar relationship to the AND H field that the
AND V
WAS field bears to the AND V field and states the record number of its
'horizontal parent'. As
with the AND V fields, one record that has a value I the AND H field, can have
any number of
records that contain its number in its AND WAS H field - one 'horizontal
parent' record can
have many 'horizontal children' records. Otherwise the description for the AND
V WAS and,
AND H fields apply in relation to the AND H was field.
13) Field 13 - SEQUENCE
SEGZUENCE FIELD
The SEQUENCE field and its record types are a primary mechanism of the Any-to-
Any machine to record relationships between data that are not already recorded
by recording
the data itself. The field and its record types is also one of the methods of
the Any-to-Any
machine that enables data to be viewed in a manner in independent of structure
of the data
563
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
itself. The Sequence field enables a given Data Relation Table record or
fields within a group
of Data Relation Table records to be manipulated and/or used in any sequence.
The Sub-Level and Sub-Sub-Level fields have the capacity to state which Data
Relation Table records exist in a group, and the Sequence field has the
capacity to state an
unlimited number of different sequences of a records within that group, and to
change the
sequences in an unlimited manner, for an unlimited number of different
purposes.
It may be that there is only one user for a particular Data Relation Table,
and that
when he uses that Data Relation Table he only every wants to view a given
selection of data
in only one way - i.e. a situation that is more or less equivalent to the
situation in the state of
the art. However, if a user wants to see or use original data in some other
manner or view it
in some other sequence, then the Sequence field and its record types are one
of the methods
of the Any-to-Any machine that enable him to do so.
A group of records can be given a new Sequence by recording consecutive
numbers
in the Sequence field of a given group of Data Relation Table records by
entering the number
of that record in the new Sequence into the Sequence field, so that the
Sequence field of the
first record to be used contains the number 1, and the Sequence field of the
second record to
be used contains the number 2 and so on.
However, in the more usual circumstance, where even a single user of a Data
Relation
Table may want to manipulate, view or use some of the data contained in a
group of data
relation table records in one sequence for one purpose and in another sequence
for another
purpose, then a View Specification data Specification record pair are used.
Sequence records can contain any reference in their fields and these
references do
not have to be all of the same type and, as described, the fields of Sequence
records can be
used in groups of any number of fields, in which each of the first fields in a
field group contain
one type of reference, each of the second fields in a field group contain
another kind, etc.
SEQUENCE FIELD, TYPICAL LABELS
The ways in which Sequence fields and records are so many and varied that
there are
no typical labels for such fields or records. However, any Sequence record can
be named
using the User Name for This field, and cari be accompanied by a Field
Parallel Label record
. that provides Labels for the contents of its fields.
SEQUENCE RECORD TYPES
Many uses have already been described for Sequence records, which are one of
the
basic methods in the Any-to-Any machine for creating a list of records and/or
fields and the
use of such records is really only limited by the programmers imagination. If,
for example,
supposing that various Data Relation Table records are grouped into items
using the Sub-
Level or Sub-Sub-Level field andlor records, a suitable View or Sub-View use
Sequence
564
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
records in which the fields are used in groups of three, can be used to
display different groups
of items in parallel, all in groups of three, so that when one of the items in
Sub-View changes,
all three change.
Alternatively, the Sequence Field can point to a User Number record that lists
in each
of its fields, a different user number. Associated with the User Number Record
as a pair, is
an Sequence Record , Sub-type Pointer, that contains in each field, the number
of an
Sequence Record. Each of the Sequence records pointed to contains list of the
data records
in the order they are to be displayed for that user.
An unlimited number of Sequence records can be used either accompanying some
description of original data, or independent of it. New items of any kind can
be assembled by
creating a Sequence record that states in each of its fields the number of the
Data Relation
table record to be used. Companion Sequence records that can be either Field
Parallel or
Table parallel can state, for each record that is used, the field or fields
that are to be used.
Effectively, a Sequence record that lists specific Data Relation Table records
constitutes an index of those records. A Sequence record, like any other
record, can be
given a name by the user in the User Name for This field. If this type of
Sequence records is
used extensively, then the programmer should consider placing them in a
separate junior
Data Relation Table as previously described. Equally, a Data Specification
type record and a
Sequence record can be used together, so that the Data Specification record
selects the
desired records and/or fields with required values, this Data Specification
record is used as a
Find Specification, and a Companion Sequence record to list those records that
are found
using the Find Specification. This basic combination can be used to provide
the user rapidly
with data meeting his Specification and as the foundation of a method to alert
the user to new
data meeting his named Data Specification, Sub-type Find Specification.
Other uses for Sequence records are to state a branch. For example, the four
AND
fields can state any number of branch that are composed of entire Data
Relation Table
records, but a Sequence record can state a branch for a field. If a Data
Relation Table field,
instead of containing a value, points to a Sequence Record number, that
Sequence record
can be used either to state a list of records that are a branch to that field.
Alternatively, if
many fields have only one branch, then a Sequence record can be constructed as
Field
Parallel to the data record and state in each field the record number to which
that field
branches. If a field in one record branches to a field in another record, then
this can either be
stated in a Data Assembly Table or using one Field Parallel Sequence record to
state the
record number while a Companion Field Parallel record states the field number.
Alternatively,
the fields of a Sequence record can be used in pairs, with one field of the
pair stating the
Record number and the other field of the pair stating the field number.
565
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
A Sequence Record - like any other record - can have any Data Class field as
its
sub-type. Therefore a particular field in a record could point to a Sequence
Record,
Sequence Sub-Sub-Type that lists other Sequence records, and the these could
be - for
example - a Sequence AND V Sub-Sub-Type that states a list of AND V branches
from that
field, while another of the listed Sequence records, AND H Sub-Sub-Type states
a list of
Horizontal branches from that same field.
SEWUENCE RECORD DATA ASSEMBLY AND DATA CLASS TABLES AND SOFTWARE MODULES
While Data Class Tables are generally not required, because a Sequence Record
is
usually assembling in some manner, values that exist in other data classes,
Data Assembly
tables can be preferable depending on the application, in order to create sub-
Assemblies that
are not large enough to merit a full Data Relation Table record, but still
require some
assembly before use in a Sequence Record.
Sequence record in general are not Field Parallel with field in the Data Class
in which
their field contents are found and therefore, in addition to the methods
already described for
dealing with this, specialized Sequence Record types generally require their
own Software
Modules to handle them, and a numerous selection of Software Field Modules can
be
required to deal with handle them.
14) Field 14 - MARKING
MARKING FIELD
The main purpose of the marking field is to provide a place for Software
Modules and
the user to mark specific records and fields as an intermediate step to doing
something else
and is simply a convenient place to place references to records and fields
that is of a
temporary nature. The Marking Data Class is essentially only a temporary
version of the
Sequence Data Class, and can be dispensed with altogether - all its functions
performed by
the Sequence Data Class and Sequence records. It is included here as it can be
convenient
as it is the one type of record in the Data Relation Table whose recorded
values are not
permanence and have no future significance.
MARKING RECORD TYPES
Marking record types similar in structure and function to Sequence Records
with the
difference that they have no permanent status. However, if the user does mark
a series of
records and/or fields, the Software Module Marking type that enables him to do
so should
also provide an Active Element button enabling him to make the marking
permanent and give
it a name. In this case, the Marking Record is converted into a Sequence
Record type and
named in the User Name for this field.
566
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
MARKING DATA ASSEMBLY AND DATA CLASS TABLES AND SOFTWARE MODULES
There is normally no need for Data Assembly or Data Class Tables, Marking type
Software Modules general provide the user with Active Elements that look like
checkboxes,
and when the user checks them, the Active Element writes the number of the
record and/or
field into a Marking Record. The Marking Software Module can provide for a
Marking record
to be used together with a Marking record, Sequence sub-type, so that a user
can make a
selection from the Data Relation Table, Mark it and then put the marked
records or field into
the sequence he wants, which the Marking Module then records in the marking
Sequence
record. Different to other fields and record types, Marking records have no
permanence and
can be over-written at any time, but because they are user-dependant - i.e.
they contain that
user's number in the User Number field - they can only be over-written by that
user.
15) Field 15 - USER
USER FIELD
The term 'User' has been used throughout this description as the term for any
person
that the application knows about - whether or not that person is sitting at
the computer's
keyboard, or simply sends something to the computer. An alternative term could
equally well
be 'Person'.
The primary purpose of the User field is to clearly and uniquely specify one
unique
person or several unique people, in relation to every user data record in the
Data Relation
Table, and this is done by assigning a unique number to each unique person and
then using
that number in ane manner or another in the User field- By 'specify uniquely'
is meant that
the Specification for the person identifies that person and does not identify
any other person.
USER FIELD RECORD TYPES
Two main types of User Record exist:
1. Data Relation Table Records that contain data about a user. Such
records are termed Unique User Records. Each Unique User Records specifies
data
about that one unique person. In fact, more than one record may be required to
contain all recorded data about one unique person, and if so the group of
records
containing the data about one unique user is termed a Unique User record Set.
When
there is more than one record about a unique person, - i.e. a Unique User
Record Set
exists - then the record number of the Base Record - the first Unique User
Record
recorded for a unique person - is the reference that is used to designate that
unique
user. The number of the first record, or of this Base is termed the 'User
Number'
A Unique User Record is an example of the case where it is not advantageous
to use a Data Assembly Table - the data about a unique person can be so
extensive
that if this is assembled in a Data Assembly Table, the Table eventually has
as many
567
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
fields as the Data Relation Table itself - i.e. its records are effectively
Data Relation
Table records - and it is more sensible to use full Data Relation Table
records in the
first place.
Once User numbers have been assigned, every Data Relation Table contains
a User Number in its User field - namely the person who - effectively -
created the
record. When a user creates anything, every record that constitutes what he
created
is marked with his User Number in the User field. Suppose that a User with the
number 143 sends something to someone else whose User Number is 554, and
suppose that the record recording the send is numbered 121 and the second
record,
recording the other side of the communication is numbered 122. Then record 121
will
contain the number 143 in its User field, while record number 122 will contain
the
number 554 in its User field. Record 121 and Record 122 will be joined with
the AND
mechanism and therefore, record 121 will have the number 122 in its AND H
field,
while record number 122 will have the number 121 in its AND WAS H field.
2. User Sequence Records that contain lists of users. Such records
contain User Numbers in their fields and when they do so, such records
constitute a
list of people. This is the prime method of the Any-to-Any machine that is
used to.
group people into a named group. Every record can be named by placing a name
reference in the User Name for This field, and hence a user Sequence record
can be
given a name such as 'The Consideration Committee.'
USER FIELD, TYPICAL LABELS
Labels for each of the Data Relation Table fields for use with the Unique User
record
type are attached as Appendix 1. Each Data Category has its own sub-type of
Unique User
records:
- The Energy Data Category for example, is represented in the
form of records that state the user's activities,
- The Space Data Category is represented in the form of Location
records that contain data about the users locations - street addresses etc
- The Matter Data Category is represented in the form of, records
that state the matter - things - that the user has or uses - etc.
Labels for each type of Unique User record are included in Appendix I.
USER FIELD, DATA ASSEMBLY TABLES
In small and possibly embedded applications, a Authorized User Data Assembly
Table
can be used instead of User Data Relation Table records.
568
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
A Data Assembly Table termed the Authorized User Table is used to assemble
data
concerning a unique person who is authorized to use a particular application
himself. This
table generally consists of at least the following main fields:
Record Number, User Number, Identity Method 1, ID Method 2, ID Method 3.,
Password 1, Password 2, Password 3, Startup Personality Number, Startup View
Specification (this is record that effectively specifies the user's default
start screen),
Re-start View Specification, Re-start Data Specification, Re-start Personality
Number,
and User Language. Other fields can be added as desired.
This Data Assembly Table contains the information that is used to identify a
user - i.e.
to detect his User Number - and is used by the Controller Interface Module to
identify the
user. When Transparent User Recognition methods are used, it is advisable to
have a
backup User identification method and therefore, provision is made for three
identity methods
each with their own 'passwords' - i.e. method of identifying the authorized
user uniquely. A
User name is typically not requested as this serves very little purpose, but
provision can be
~ 5 made for using two separate passwords, both of which should be correct
before the user is
allowed admission. Requiring the user to enter his own name should be avoided
when
possible because human identification methods generally do not expect this if
the person is
physically present - a person does not see someone for the twentieth time and
each time say
'my name is John', he expects to be recognized based on information he makes
available -
such as his face and expects the other person to know his name based on the
information
provided. This human procedure may be copied to recognize a human based on his
password or other equivalent information and thereafter uses his name as
preferable.
The Senior Personality will be described under the heading of the Personality
field.
The Data Class normally uses a second, User Preference Data Assembly table,
which
includes fields for such things as the preferred method of address that the
Personality is to
use in addressing the Authorized User - for example 'John', 'Miss Bowler'
'Funny Face' etc -
whatever name the Authorize User decides at installation or changes to after
installation. The
User Preference Table is normally extensive and contains a field for each
thing that can be
adapted to the user. If the table becomes too extensive, then it can handled
on the standard
Any-to-Any machine and Data Relation Table pattern, and divided into record
types, each one
of which specifies preferences of one type for one user; alternatively, these
preferences can
be recorded in the standard Data Relation Table, as - Record Type: User; Sub-
Level (type)
Preferences; Sub-Sub-Level types - preference type 1, preference type 2 etc.
USER FIELD~DATA CLASS TABLE
A Data Class table is not normally required, as when a User name needs to be
described or stated in Spoken Concept language, the translators for the
individual Data
569
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Classes whose fields contain values provide the translation from Numbers
Concept Language
into Spoken Concept Language.
USER FIELD SOFTWARE MODULES
Software Modules that are desirable to this Data Class are those that look
after the
administration and action of user identification, and the recording and
updating of new
Authorized and normal users and administration of Authorized User preferences.
16) Field 16 - Personality
The Personality Field in the_Data Relation Table being described is an example
of one
of the Any-to-Any machine's methods for reducing the number of Data Relation
Table fields
required to hold a number of Data Sub-Classes, and shows the general method
for
representing more than one Data Sub-Class in a single Data Relation Table
field. These
methods can be useful when, for some reason, a programmer needs to reduce the
size of the
Data Relation Table as much as possible
Generally, most Data Relation Table fields, particularly including
Administration fields,
need to contain record numbers, and these record numbers can be as large as
the largest
single number anywhere in a Data Relation Table. However, the Data Relation
Table fields
for some applications - and the Personality field for the general application
being described is
an example - a given Data Sub-Class only requires reference numbers that are
unlikely to
over get very large. In the example being used in this description, the
several Sub-Data
Classes used to control the Personality are all relatively small numbers and
such numbers are
often provided by a Data Assembly Tables.
The general method of the Any-to-Any machine is that a Data Class or Sub-Class
contains only one type of thing. If a Combined Number is used in a single Data
Relation
Table field, each part of the Combined Number is specifying a different type
of thing, and
therefore it is combining several Data Sub-Classes into a single field.
In order to reduce the number of Data Relation Table fields required, several
Data
Sub-Classes can be combined into one Data Relation Table field, and is so, a
Combined
Number is the mechanism used to combine the reference number for each
different Data Sub
Classes into a single number. Each part of a Combined Number is in effect
assigned to one
Data Sub-Class. Hence, whenever a Combined Number is in use in a Data Relation
Table,
the number is itself an assembly, and is usually an assembly of data Sub-
Classes. Data Sub-
classes, that are assembled into a Combined Number and then used, are referred
to as
Combined Data Sub-Classes and accordingly, Combined Numbers and Combined Data
Sub-
classes go hand in hand.
However, when one of the values in a Data Relation Table field is required for
use in
Execution, then it will be found that not only is the data referenced by the
parts of the
570
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Combined Number assembled into one, but doing so has resulted in a requiring
that
corresponding field in every Software Module that uses the Combined Data Class
requires at
least one Field Logic for each of the Combined Data Sub-Classes assembled
together in the
Combined Number. In other words, while Sub-Data Classes can be assembled into
a single
Combined Number, when the time comes to perform Execution on the basis of
them, the
Combined Number should disassembled - i.e. the Data Sub-Classes have to be
disassembled - a separate Field Logic operates on each part of the Combined
Number. In
the following description it will be seen that the Combined Data Sub-Classes
in a Combined
Number are separated out and used in temporary tables any of the Data Sub-
Classes that is
used, has its own field, operated on by Field Logics that operate exclusively
on that field - in
other words, the Data Sub-Class re-assumes its proper status as a Data Sub-
Class.
PERSONALITY FIELD
While the word 'Personality' as used in the Any-to-Any machine refers to a
specific
image, fundamentally, the subject of making an application operate the way the
user wants
and likes it to operate is the subject of the Personality of the application -
making it personal
to the user - and hence, parts of the Any-to-Any machine that are user-
dependant are
handled by the Personality Data Class. The Personality Data Class as a whole
is the Data
Class and field in the Data Relation Table that covers several of the methods
of the Any-to-
Any machine enabling any application to present itself to an individual user
in such a manner
that not only can the visual aspects of the application be adapted to the
user's tastes, but also
enabling any Execution to present itself to any level of user in such a manner
that it is easily
comprehensible to each individual user and therefore, easily usable by him.
A Personality can be represented on the screen - and therefore recognized by
the
user - by a picture or a video of person (or thing) - and in audio
applications by a particular
accent or intonation. A screen image of a person can be either one of a series
of still photos,
or a video. There is no obligation to display this image, and hence one part
of the Combined
Number this is the Personality Number states whether the chosen image is to be
displayed or
not. The use of this digit by Software Modules can enable the user to turn the
display of the
image on or off, and also enable Software Modules that do not need the image
to be
displayed - such as some communication Software Modules - to turn off the
image display if
they need to do so. Similarly, a specific digit position in the Personality
Number is a switch
that states whether or not a particular View or Sub-View should display, or
not.
The Any-to-Any machine also includes methods whereby texts such as Help,
Prompts,
and Labels are given to the user by an Active Element that uses a Spatial Data
Relation
Statement to make the text concerned appear to be coming from the Personality.
One
method of doing this in the case of a screen is to use an Active Element that
has the visual
571
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
aspect of what it termed a 'callout' in the state of the art - i.e. a Talk
Bubble, as used in
comic books to indicate that particular words are coming from a specific
visual image of comic
character. Hence, making a texts appear to be spoken by a Personality requires
use of a
suitable Active Element or Sub-View where the outline of the Sub-View is such
that the texts
appears to come from the Picture of the Personality. Using this method, any
Software
Module can 'use' any Personality, by displaying a suitable Active Element - or
a Sub-View
containing Active Elements in which the outline of the Sub-View appears to
make the text
come from.the Personality.
The methods of presenting the Personality give the user the impression that
the
Personality is the controlling entity for the computer - even though that is
not the case - and
therefore the place to which orders to the computer should be directed. A
Personality is given
a Name by the user and thereafter, Command Input - an order for the
application to execute -
is distinguished from Data Input - text being written in a letter for example -
by one of four
methods:
1. By including the Personality's Name in a command. If the Command is
delivered verbally the Language Processor interprets the word containing the
Personality name as a command. If the Command is given using a Visual
Interface
then the following two methods enable command input to be distinguished from
Data
Input:
2. By writing a command in a screen area that is a 'Talk to the Personality'
box - an area of the screen that visually appears to 'belong' to the
Personality and
which is dedicated to receiving commands from the user. The Personality name
in
this case, is used by a Language Processor to distinguish between a Command to
do
something and words that are Data Input.
3. By clicking an Active Element that is a pictorial representation of the
Personality; this produces further Active Elements menu buttons that enable
any
command to be given.
4. By clicking on any Active Element menu button.
The ability to address a Personality by the name assigned to it by the user
can replace
or supplement less usual human methods used in the state of the art for
indicating a
command, such as using the slash or equals key, or by speaking a word such as
'Command.'
In addition to presenting an image and having a name, a particular Personality
is also
a particular assembly of sounds, and a particular style and way of behaving
and a particular
way of saying things and a particular presentation of screens, Labels, Prompts
and Help that
are adapted to that user, self-adapting to that user and can be adapted by the
user. A
572
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Personality can be made to appear to display emotions appropriate to the
matter in hand, and
also potentially represents a particular functionality.
The Personality field records the number of the Personality - the Personality
Number -
that was used when creating a record. In the case of a communication that is
received from
another Data Relation Table, the Personality Number of the Personality the
user used to
receive a communications is written in the Personality field, while the record
for the sender
contains the Personality Number the sender used to create the message written
in its
Personality field.
Personalities are also used in the Any-to-Any machine to group functions
together into
useful groupings such as Accounting, Astronomy, and Secretarial. Doing this
enables
functionalities to be handled in groups, but the Any-to-Any machine method for
doing this
does not structurally separate any grouped functionality from remaining
functions. All data
and Software Modules are directly accessible from anywhere in the application,
whether or
not they occur inside a particular grouping of functionality. Hence, any
Software Module can
be accessed directly from anywhere, and any relationls that actually exist
within and between
all the available data can be accessed directly from anywhere also. Grouping
functionality
with this method of the Any-to-Any machine enables any particular
functionality to be
manipulated as a whole, without in any way preventing that functionality being
manipulated in
any other manner. In other words the functional grouping is a functional,
addressable
grouping, but not a structural grouping as is the state of the art practice
where a group of
functionality is cemented together - for example - as a package termed 'Brand
X Word
processor.'
The Personality number used in the Personality field is a Combined number,
some of
whose digit positions are assigned to a number, called the Application Number,
that is used to
designate a particular grouping of functionality.
When a new application that uses the Personality function is installed into an
existing
application, the new application is assigned an Application Number. This can
be done by the
software provider writing an Application number obtained from a central
registry and writing it
into Application Number part of the Personality field of all the records
constituting the
application. Alternatively, the Install Module that installs an application by
copying its records
into the tables of the Any-to-Any machine can write the next available
Application Number into
the Application Number part of the Personality field of all the data and
software records being
copied into the existing application. If some or all of the Application's data
and Software
Modules are intended to become part of the core functionality, and not
otherwise designated
as a specific application, then an Application number consisting entirely of
zeros is assigned
instead. (Part of the programming conventions for the application is that all
fields that whose
573
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
values are blank are filled with zeros, all zeros in a field or in the
entirety of one part of a
Compound Number being designated as equaling empty). The result is that data
and
Software Modules whose Application Number in the Personality field is all
zeros is handled by
the default Personality in and treated as part of the core application.
Wheri a data record or a Software Module is accessed that contains an
Application
Number other than zero, the methods the Any-to-Any machine can result in that
application
being made the Active Application, with the following results:
1. The Image of the Personality being displayed is changed to the image
used by that application.
2. All data recorded while an application is the Active Application is
recorded with that application's Application Number in the Personality field
of the
records concerned.
3. The Application Number in the Personality field of all Find
Specifications is set to the number of the Active Application. Doing this
limits the first
Find to the data with the same Application Number in the Personality field.
Equally, it
makes it possible for a second Find to be performed automatically, but with
the
Application Number in the Personality field set to NOT the number of the
active
application, with the result of finding all data that exists otherwise matches
the Find
Specification but which does NOT lie within the zone of the application
concerned. In
effect, this enables a computer to produce returns that, colloquially
expressed are of
the nature of: 'These are the people who have written to us saying they will
pay (i.e.
the result of the first Find within the zone of the active application of
Accounting) and
in addition, Sales has received e-mails from these people also saying they
will pay
(the result of the second Find outside the zone of accounting).'
Alternatively, the Application Number can be used so that when a first Find
fails to
finds what the user wants in the compass of the application in which he is
working, a second
Find executes automatically to look outside the zone where the user is working
In effect, these methods can be used to limit the Software Modules and data
that are
accessed first to a) general Software Modules and data plus b) Software
Modules and data
that concern specific groups of functions associated with a specific
Personality, but without
entirely separating all other data and Software Modules from being accessed.
1f this method
is in use, then all Software Modules that are of general use to all types of
applications -
Communications Modules, Calculation Modules and Interface Element Modules for
example -
have their Application Number part of the Personality Number marked as zero,
making them
available at all times. Accordingly, the only Software Modules and data
records that should
be marked with an Application Number other thari zero are those Software
Modules and data
574
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
that are highly specialized and only used in a certain context - for example,
a Software
Module that calculates planetary orbits.
The use of an Application number enables an entire body of knowledge and
ability
i.e. data and Software Modules concerning a specific subject - to be handled
as a block, for
example by a user who gives a command such as 'send the Astronomer over to my
portable'
- thereby transferring to the portable all data records and Software Modules
marked with an
Application Number as being part of the functionality to which the Personality
name of
'astronomer' has been given. In effect, giving a group of records an
Application number, and
assigning that Application Number a (Personality) name, enables the user to
manipulate the
application by manipulating the applications (Personality) name.
When these methods are in use, Personalities are assigned a Seniority in the
Seniority Personality Data Assembly Table field, so that a more senior
Personality can directly
access and use all Software Modules and data that are numbered with the
Application
Number of any Personality with a more junior Seniority number. One Personality
should be
able to access any data - i.e. that Personality ignores all Application
Numbers and all
Confidentiality restrictions. The methods of the Any-to-Any machine already
described,
include methods that make each Personality user-dependant and also include
methods that
require Password identification of the user in order to access each specific
Personality.
The Seniority field also enables a single user to use a number of different
Personalities with one Personality as the senior Personality and other
Personalities as junior
Personalities 'responsible' for different activities such as accounting or
games. Additionally,
with the methods of the Any-to-Any machine, the style and level of detail of
Labels, Prompts
and Help, and particular sets of screens and particular ways screens behave
are also related
to the Personality, and hence the Personality also forms a convenient way of
selecting any of
these as a group.
The effect of these methods for the user, is that he can appear to have a
structured
staff of specialist, knowledgeable Personalities - each of which has its own
recognizable
human characteristics - working for him in his computer, thereby creating a
way of functioning
that is analogous to the way of functioning that people are used to in normal
life. In normal
life, if someone wishes to know the answer to a legal question, they ask a
lawyer, and if they
wish to know the answer to a financial question they ask an accountant.
Continuing this
analogy into the computer environment has some importance, as information that
appears to
come from a source that is not expert in a particular discipline is not
generally trusted as
much as information that does (appear to) come from an expert in that
discipline. If,
therefore, a question about accounting is addressed to a Personality
displaying the general
look and comportment of a paperclip, a dog or of a good secretary, the answer
may be
575
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
accepted if the accounting question does not require profound knowledge, but
may leave the
user uncertain as to whether he should ask someone else, if the question
concerned
something such as tax advice which the user considers does require expert
accounting
knowledge.
Further, the range of computer and general experience, understanding, and
vocabulary amongst the users of any general computer application can be
tremendous,
varying from someone who is barely literate at one extreme to a computer
expert at the other
extreme. The state of the art practice of providing one set of User Messages
intended to be
easy to use by everyone in this range is clearly unrealistic, and does not
provide any user
whatsoever with the assistance that he actually requires. For new user, even
intelligent new
users, the guidance provided is close to unintelligible. In order to solve
this problem, the
Combined Number for a Personality includes digit positions that can be used to
designate a
number of different Levels - libraries - of Labels, Prompts and Help. A
'Level' in this instance
is used as designating a level of detail and language used in writing Labels,
Prompts and
Help that is suitable for a particular level of user literacy, and computer
understanding and
experience.
With the Any-to-Any machine methods, the programmer can provide different
Levels
of Help, Prompt and Label records - collectively called 'User Messages' - as
distinct Sets in
which every single User Message required by a Software Module is written in a
manner
suitable for a given Level of user literacy, computer understanding and
experience.
Additionally, each User Message Set, can contain sub-sets, termed Styles, in
which all the
User Messages found in a Set are written in a specific style - formal,
flippant etc. In the same
way that a number of Sets can exist to accommodate different user Levels of
literacy, and
computer understanding and experience, each Set can have a number of Styles,
accommodating the preference of different users for the manner in which the
Personality
states User Messages. Additionally, just as a given Set of User Messages can
be written in a
number of Styles, each Style can be written in a number of Emotions - grief,
sarcastic, angry,
bored, conservative, enthusiastic, euphoric, serene etc. A full Language
Processor can use
Condition records to detect specific emotions and the provision of User
messages written with
specific emotions can be used to enable an application to output User Messages
that are
emotionally appropriate to the circumstances.
Labels, Prompts and Help, are each stored in their own data Class Table,
containing
the Spoken Language Concept Language version in one field, and the Number
Language
number in the other field.
In computer terms, Help is, in effect, further information about what
something is, or
what it does. Hence, every non-Administration field in a Software Module that
has a value,
576
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
has a number of Help Records that are Field Parallel with it, each record
containing Help of a
particular Level and a particular Style. Additionally, the Controller Field in
the Help record is
used to contain the Help about the entire Module. Any and every kind of record
can be
provided with its own Help and it is often useful to do so and hence, data
records can also be
provided with Field Parallel Help records, giving information about the data
or help concerning
using it, and again, each field of the Help Record contains information about
its corresponding
field, while the Controller Field of the Help Record contains information
about the entirety of
the data in a record, in a group of records. Help Records associated with data
structures
such as the Data Relation Table are again Field Parallel with the structure
itself, and contain,
in each field, information about that field of the structure, while the
Controller field contains
information about the entire structure. The data for different levels of Help
records can be
stored in different ways. For one - perhaps expert - Level containing very
little information,
the information can held in the Help Data Class Table Content field, while the
Help Data
Class table contains disk addresses far disk files, where the Help data is
lengthy. The user
can change any Label, Prompt or Help that he wants to, and in this case, the
appropriate
Data Class Table should be provided with a field for User Number and another
field for the
number of the original Data Class Table record. The original record is copied,
re-recorded
but this time with the User Number in the User field, and the number of the
copied record in
the 'Original Number' field, and the user makes any changes he wants to the
copied record.
This procedure illustrates an alternative method to the method previously
described for
recording a specific user's version of an original value, and for enabling the
application to
translate between the original reference number, which is the number that is
used in a table,
and the user's version of the corresponding original value.
Specific digits in a Personality number are designated for the Set Number,
Style
Number and Emotion Number.
The general method of the Any-to-Any machine to handle these variables is as
follows:
1. The Personality Data Assembly Table relates a specific Personality
image Photograph or video) with a specific Level and Style of User Messages,
and
with sets of screens such that each screen in the set can operate similarly
and have a
similar look. Additionally, the table relates these to a specific user and
also potentially
to specific functional groupings ('applications'). The different things that
are related
together by the.Personality Data Assembly Table together make up 'the
Personality'.
2. Many of the parts that are related by the Personality Data Assembly
Table are individually represented in the Personality Number.
577
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
3. Every individual Data Relation Table record has a Personality Number
field. Each of the individual parts of the Personality Combined Number in a
record can
be either contain a value or be blank - i.e. assigned the value of all zeros.
4. Any part of a record's Personality Combined Number that has a value
other than zero results in that value being used, otherwise, the corresponding
value in
the Personality Data Assembly Table for that part of the Compound number is
used.
The effect of this method is that any part of the settings for a given
Personality that set
how the screen and the Personality behaves that are active at a given moment,
can be
overridden by the settings contained in an individual Data Relation Table
record. The
Personality can also be made to appear to 'speak' using sound files containing
spoken text,
and a further digit position in the Combined Number for the Personality states
whether these
are to be used or not.
The primary mechanisms that enable Personalities to operate as described above
are
the Personality Data Assembly Table and Data Class Tables.
PERSONALITY FIELD, TYPICAL LABELS
The main label for the Personality Field when it is displayed is the name
given to the
Personality in use by the user. Labels for the Personality Data Assembly Table
and the
various Personality Data Class Tables are stored as wilt be described shortly.
PERSONALITY FIELD, RECORD TYPES
Whenever one human deals with another, an explanation of anything he does not
understand is immediately and directly available, simply by asking the speaker
to explain what
he just said, and this is a universal operating method common to every human
being. It is not
the only possible method - another alternative method that could be used
universally would
bee for a human being who does not understand something, to break off the
conversation,
and go and ask the nearest person for an explanation and, when the explanation
was
obtained, return to the speaker and continue the conversation. However, while
that could be
the universal practice amongst humans, it is not the universal practice
amongst humans. The
universal practice amongst humans is to ask the person delivering the data for
an
explanation. However, the laughable example given for humans - going and
asking someone
else - is a close representation of the universal practice in state of the art
software - the user
should go somewhere else - to a Help file, which he should then open - to
obtain an
explanation of what another entity - such as an icon - is saying to him.
Hence, a desirable feature for Ease of Use, is that anything and everything
the user
encounters while using a computer has available its own full set of
explanations, written in
such a manner as to be understandably by that user, that is available by
directly 'asking'
578
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
whatever screen presence it is that the user does not fully understand - for
example by right
clicking on it.
Hence User Messages may be created individually to go with each and every
field that
a Software Module outputs to the user, and every single visual entity that
appears on a
screen anywhere has its own its own Help, and may also have a Label and a
Prompt. In
addition to the User Message records that accompany a Software Module, any
Software
Module can also be accompanied by one or more Condition records that are used
to detect
specific Conditions, Each of these Condition records can also be accompanied
by
Companion and Field Parallel records of Prompt, Help, and Label types. User
Message
record types accompanying Condition records are used to prompt the user for
input, and/or to
give him help on that particular field or Prompt. Additionally, Label records
may be used to
Label an Active Element displaying a data entry area, or to Label an Active
Element that is
displaying a Prompt or one displaying Help. Additionally - so that the user
can state what he
wants to do when a certain Condition is met - one or more Single Active
Elements can
accompany Condition record in order to display specific Active Element buttons
- together
with their Companion Label, Prompt and Help fields.
A Single Active Element is specified by citing its record number in the Single
Active
Element Data Assembly Table and is an alternative method for assembling Active
Elements
to the one previously described. The Single Active Element table contains
fields that between
them specify everything a single Active Element needs in order to operate,
including fields for
each Interface Control, fields for the Help, Prompt and Label records, plus a
field specifying
the Software Field Module or Software Module that is to be activated if the
Active Element is
clicked. A Single Active Element embraces and extends the functionality of a
state of the art
menu icon. One way of assembling 'menus' in the Any-to-Any machine is to use
one or more
Active Interface Element records to specify Single Active Element reference
numbers in each
field, and then assemble the Active Interface Element records into a Sub-View
using the
appropriate records to control the positioning of the menu, and then giving
them Sub-View a
name (enabling the user to specify it by name) such as 'start work menu'
planning menu',
'writing menu' 'check salesmen'.
Any Single Active Elements can be called at any time by any Software Module
and
one of many ways of doing this is to specify either the Single Active Element
Table reference
in a Condition Director record, or specify the number of Sub-View containing a
number of
Single Active Elements.
Hence, Single Active Elements also use Labels, Prompts and Help that.are
specified
in the appropriate Data Class Tables that are part of the Personality Data
Class.
579
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The method previously described for constructing View and Sub-Views stated
that
Label, Prompt, and Help records are Field Parallel with the Data and/or
Software Module that
use them and such full Data Relation Table records are a Sub-type of the
Personality Record
Type.
A 'Personality' as enabled in the Any-to-Any machine is not a single thing,
but a
composite - assembled in the Personality Data Assembly Table - composed of
images, and
a particular manner of User Messages, as well as a particular style and a
particular of detail,
all of which are able to be adjusted by the user andlor by the application, to
be
comprehensible and Easy to Use for each individual user.
Hence the package that is an 'an application' consists of:
- Software Modules
- Data records
- Data Class values to go with the Data
- Label, Help, and Prompt records
- Personality Data Assembly and Data Class records
- Views, Sub Views and Interface Elements including Single Active
Elements
Personality record types, like any other record type, can have any other type
of record
as a sub-type, such as a Condition Record, making certain Personalities active
under certain
Conditions.
PERSONALITY FIELD, DATA ASSEMBLY AND DATA CLASS TABLES
A number of Data Assembly Tables are generally required for the Personality
field and
the first of these is the:
Personality Data Assembly Table
The 'Personality' is not a single entity but is an assembly whose constituent
parts are
represented by the Working Names for fields in the Personality Data Assembly
table. In
effect, one Personality is one record in the Personality Data Assembly Table,
which generally
contains the following fields:
1. Record Number is the number of the record in the Personality Data
Assembly Table but, unlike most Data Assembly Table or Data Class Table
numbers,
is not used as a reference in the Data Relation Table as the Personality
Number is
used instead.
2. Personality Number. The Personality Number is a Combined Number.
3. Application Number is the number given to all supplied Data and
Software Module records that constitute a single function such as 'Astronomy'
'Gardening' "Computer Aided Design,' and can serve to designate what is called
'an
580
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
application' in state of the art terminology. The application provider sets
this number
and normally no provision is needed to be able to change it. The Install
Module
should however, ensure that the number does not conflict with any existing
Application
Number, and if so, change the number in all records provided by the new
application.
The Application Number is provided by an Application Number Data Class Table,
in
which one field provides the reference number for the application, and the
other field
provides the Spoken Concept Language name. If the application is to be used in
more than one language, one Spoken Concept language field is required for each
language. The Personality Combined Number includes digits for the Application
Number as previously described.
4. User Number is the User Number already described and is used to
record state user uses this particular Personality table record.
5. Seniority is used as described for the Data Relation Table Seniority
field and as described above, and contains a reference number that states the
seniority of the Personality and therefore, which junior Personalities it can
control. If
required, a Personality Seniority Data Class Table can be used to provide a
Spoken
Concept Language name for the corresponding seniority number, with other
fields for
description etc. The Personality Combined Number includes digits for the
Seniority,
so that the Seniority of an individual Module or record can be known.
6. Name. The Name field contains the reference number to the name
given to the Personality by the user and is used by the Personality when
referring to
itself. When the user uses the Personality's Name, the effect is to get the
Personality's 'attention' - i.e. use of the Personality Name designates that
what
follows is Command input. The Name of the Personality is any name that the
user
cares to give to the Personality. When an application is first supplied, a
default
Personality is normally supplied, - i.e. a Personality Table record that has
no User
Number. When the user first uses the Personality, a New Personality Software
Module associated with the field makes a new Personality Table record,
containing the
User's Number and - if the user makes no other changes - records the values in
the
default record in the record for that user. If the user changes the
Personalities' name,
the previous record is copied, marked Inactive in the Status field, the name
is changed
in the copied record, which is active by the simple fact of containing no
Inactive code
digit. A Personality Name Data Class Table is required to provide the Spoken
Concept Language translation of the Numbers Concept Language name. The
Personality Data Assembly Table Software Module for this field contains a
Field Logic
that, while it allows the user to give the Personality any name he wants to
give to it,
581
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
does not allow duplicate names for any one user. Different users can use the
use the
same name, but if the user does want to use a name also used by another user,
the
Field Logic should use a Sub-View to point this out to the user, as, while the
application will not get confused, the user might get confused. Similarly, if
the user is
using a Personality name that is the same as record Nickname for a person, the
Field
Logic should point this out, again, because the user himself may get confused.
7_ Status is used as described for the Data Relation Table Seniority field
and as described above and is used by the Software Modules associated with the
Table. If required, a Personality Status Data Class Table can be used to
provide a
Spoken Concept Language name for the corresponding Status number, with other
fields for description etc
8. Time Start is a date time field, in which the date and time is recorded as
a single number as described under the Data Relation Table Identity field, and
can be
used to state a time at which a particular Personality - i.e. a particular
record in the
Personality table - is active. This can be used to cause different
Personalities to be
used - without otherwise changing the function. The three Time Fields - Time
Start,
Time End, Repetition, and Time Name operate as will be described for these
fields in
the Data Relation Table and use the Tirne Data Class Tables as desired.
9. Time End, similarly to Time Start, states at a time and can be used by a
Suitable Software Module to control Personality behavior - for example, to
make a
particular Personality active or inactive depending on the time or to control
a time at
which a suitable Software Module updates the Personality or an application
from the
Internet.
10. Time Name enables a user to name a time - such a Wednesday or
Bong Day.
11. Repetition is a Time field that operates as per the Repetition Data
Relation Table field and data Class that that will be described. The field can
be used
to state how often a time statement is to be executed - i.e. whether this
Personality is
valid between these times every day, or every third Thursday, etc
12. Location Name operates as per the Data Relation Table Location Name
field and uses its Data Class tables. The field can be used to state Location
names at
which the Personality is active, and can be used to enable such things as the
user
having one Personality on his Portable and another one on his main machine.
13. Software Module Name. This field operates as per the Software
Module Name field in the main Data Relation Table. The Personality Data
Assembly
Table can have Condition records and these can contain a Software Module Name
582
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
that is launched if the Condition is met. The Software Module Name is the
reference
to a Software Module that is either in the main Data Relation Table, in the
Software
Module Assembly Table, in the Field Logic Assembly Table or in the Single
Software
Module or Field Active Element Data Assembly tables.
14. Image is a field used to state the reference number to the Image Set
field in the Personality Image Data Assembly table. An Image Set is a group of
similar
images that can be used instead of one another or under different
circumstances - for
example, a number of different photographs, all of the same person. The
Personality
Combined Number includes digits for the Image, so that individual images from
the set
can be designated - for example by different Software Modules - and so that
the
image can be changed from time to time by Software Modules. Images are managed
by the Personality Image Data Class Table.
15. Sound is similar to Image and selects a particular set of sound files in
the Personality Sound Data Assembly Table. Sound files themselves replace or
add
to Label, Prompt and Help files and can either play a sound file that is a
recording of
spoken words, or play music or musical sounds. The Personality Combined Number
includes digits for the Sound, so that individual sounds can be designated for
use with
specific records by different Software Modules. Sounds are managed by the
Personality Sound Data Class Table.
16. Screen Level is a reference number to the 'Level' field in the Screen
Data Class Table that designates a particular set of Screens written for a
specific level
of user competence. The Personality Combined Number includes digits for the
Screen Level, so that individual screens can be designated for use with
specific
records by suitable Software Modules. Screen Levels are managed by the
Personality
Screen Data Class Table.
17. Label Level and Style is a reference number to the 'Level' field in the
Label Data Class Table that designates a particular set of Labels written for
a specific
level of user competence. The Personality Combined Number includes digits for
the
Label Level and Style, so that individual Levels and Styles can be designated
for use
with specific records by suitable Software Modules. Label Levels and Styles
are
managed by the Personality Screen Data Class Table.
18. Prompt Level and Style is a reference number to the 'Level' field in the
Prompt Data Class Table that designates a particular set of Prompts written
for a
specific level of user competence. The Personality Combined Number includes
digits
for the Prompt Level and Style, so that individual Levels and Styles can be
designated
583
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
for use with specific records by suitable Software Modules. Prompt Levels and
Styles
are managed by the Personality Prompt Data Class Table.
19. Help Level and Style is a reference number to the 'Level' field in the
Help Data Class Table that designates a particular set of Help field values
written for a
specific level of user competence. The Personality Combined Number includes
digits
for the Help Level and Style, so that individual Levels and Styles can be
designated for
use with specific records by suitable Software Modules. Help Levels and Styles
are
managed by the Personality Screen_ Data Class Table.
20. URL is an Internet URL In the event that the Personality is run as a
soap opera, with a software supplier's studio creating a continuing life for
the
Personality, or that software updates or additions are supplied by Internet,
the URL
states where the appropriate Software Module calls to get updates. The Times
fields
can be used to state when the call should be made.
21. Status. Status is used to state whether a record is active or inactive.
A particular Personality Data Assembly Table record provides the default
values that
are used by the application, unless an individual Data Relation Table record
contains other
values, in which case, the vales in the Data Relation Table take precedence.
The Personality Data Assembly Table allows any one value from any one of its
fields
to be assembled in one of its records with any other value from any other of
its fields field,
including with values that the user provides himself if he wishes to, there is
no limit to the
degree to which a Personality can be made individual.
As previously described, a Data Assembly table is a miniaturized Data Relation
Table,
and can therefore contain any Data Relation Table type, such as its own Label
records,
Condition records - for example stating when a given Personality is valid, and
hold its own
Field Parallel Software Modules and Interface Element records with the
advantage that these
seldom-used records are kept out of the main Data Relation Table. However, if
more a more
extensive field selection is required than the above, the selection can be
extended, or the
Personality Data Assembly Table can be dispensed with and Data Relation Table
records,
Personality Type, Assembly sub-type used instead.
The Table requires associated Software Modules, Sub-Views and Single Active
Element buttonls to be provided by the programmer to enable the user to be
able to change
any settings
Personality Number.
The Personality Number is a Combined Number that is actually used in the
Personality
Field individual Data Relation Table records and is collated from the digits
of values in
individual Personality Data Assembly Table fields as follows:
584
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
1. Application Number. The digits for the Application Number are created
as already described.
2. Seniority Number. The digits indicating Seniority can be assigned by
both programmers and users.
3. Image On. This is a one digit switch number, with one value stating the
Image is on, and another number stating it is off.
4. Image Set. This is a reference riumber for a particular set of images. It
is a fundamental method of the Any-to-Any machine to store one type of thing
in-only
one place, since, with that method, something of a given type can only be in
one
place, and hence when it is desirable to find something of a particular type,
the
contents of that place can be reviewed to find the item required. Whenever the
same
type of thing can be stored in an unlimited number of different places,
finding a
specific one of a specific type of thing requires reviewing the entirety of
all data, as
there is no prediction at all where that type of thing may be found. If the
data mass is
large, this process can be impossibly slow. Hence, all Images of any kind,
whether
used as an image for the Personality or not, are stored in a full Data
Relation Table
record, Data, Image type. The image itself is stored in the Matter Data
Category,
Content, Image field of the Data Relation Tabie record, or alternatively, the
disk
address of the image is stored in that field. Records for Images that are used
for a
Personality, are given a Sub-Level type Combined Number such that one digit of
the
Combined Number code the image record as an image record used by a
Personality,
and further digits of the Combined Number codes the record with a (Personality
image) Set number. A 'Set' is a group of something all in a similar style and
in the
case of a Personality, a Set of Images is a number of photographs in the same
style -
for example, a number of photographs all of the same person, each photograph
showing a different expression and looking in a different direction. The
direction in
which the image is looking can be helpful in directing the user's attention,
as if he is
looking to the image photograph, he will tend to look on the screen where the
photographed person app-ears to be looking. The Image record is further
assigned a
Sub-Sub-Level number that code the record as a particular image number in the
Set.
When the user wants to change the Image Set, the Fieid Logic for the Image
Set field calls a Personality Image Change Software Module. This Module:
a. Uses a Data Specification type Data Relation Table record to
find all Image records coded with the code for a Personality Image.
b. Calls its associated Image Change Sub-View to display the
selected records
585
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
c. The Image Change Sub-View:
i. Uses One Active Element to display the number in the
Sub-Level field, minus the digit that codes the record as a Personality
Image record Sub-Type.
ii. The Active Element displays a translated Label, whose
number is found in the Image Set field of the Label record in the
Personality Data Assembly Table. When this reference is looked up in
the Label Data Class Table it will read 'Image Set Number'.
iii. A further Active Element displays the number in the Sub-
Sub-Level field of the record concerned.
iv. The Active Element displaying the Sub-Sub-Level field
number displays a translated Label, whose number is found in the
Image Set field of the Label record in the Personality Data Assembly
Table. When this reference is looked up in the Label Data Class Table
it will read 'image Number'
v. A further Active Element displays the content of the
Content, Image Field, plus a Label with the words 'Description'.
vi. A further Active Element displays a Prompt that says
'Each line is showing you one example from a Set of similar images.
Click on any line to have the chose the Set of images you want the
Personality to display.'
d. Whichever line the user clicks on, the Set number from that line
is placed in the Personality Data Assembly Table that is being created or
changed.
When the user records a data record, the Personality Number of the
Personality he used at the time is written into the Personality Field.
However, when
doing so, the Image Set number is set to zero, regardless of the Image Set
that was in
use at the time. When a User
When the same record is accessed in the future, Personality Field Logics look
at the Image Set Number in the record, and, finding it set to zero, refer to
Personality
Image Data Assembly Table, Image Set Field to find which Image the value for
the
Image Set
,. used in a Personality
5: Image Number. This is a Combined Number made by concatenating
the value in the Sub-Level and Sub-Sub-Level fields of a specific Image
record.
These numbers are concatenated and used as Combined Number to keep them
586
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
sorter and enable them'to be used in a Personality Number. Regardless of the
particular image that was showing when the user chose an Image Set for the
Personality, this number is set to zero in all
6. Set number from the
7. number of a specific image in the Personality Image Data Assembly
Table, Image Number field.
8. Sound On. This is a one digit switch number, with one value stating the
Image is on, and another number stating it is off.
Operation and Use of the Personality Number and Personality Data Assembly
Table
1 p 1. Startup
When the User 1/D Module identifies a user, the User's number is passed to the
Controller Interface Module, which places it in the User field of the
Controller Interface Table,
which is Working Table. However, in the course of writing the Personality
Number, the
Controller Interface Module splits or parses it into its respective parts, and
places each part in
its own field in the Working table.
Working Tables are Data Assembly Tables that are created by the Field Logic in
the
Controller Field of a Software Module called a Working Table Module using a
Token that
states how many fields the Controller Logic needs in the table. The Working
Table Module
creates the table, and returns the Token to the Controller Field Logic of the
Module that called
it, giving the location and number of the Working Table it has created.
Working Tables are
tables that enable a Software Module to record temporary assemblies that is
needs in order to
work, and which the Software Module concerned deletes when it terminates.
Working Tables
follow the same general principles as all tables in the Any-to-Any machine, so
they contain
only number references, the table itself, and its fields are not named with
words, only with
numbers. One convenient way of 'naming' Working Tables is using a combination
of the
Execution Record number of the Software Module using the table, and the time
of creation,
thereby avoiding confusion if two versions of an identical Module are in use
at the same time.
If for some reason a Working Table may need to be displayed - for example, for
a
programmer to see what is happening, then a Data Relation Table Label Record
can be used
to store the references to the Label values in the Label Data Class Table.
Names given to
Working Tables and their fields are Working Names for descriptive purposes the
same
names may or many not be used in the actual Labels - if any - at the
programmer's
discretion.
The Controller Interface Module uses a Controller Interface Working Table - a
temporary Data Assembly Table - to administer Active Users and their User
Master Interface
Modules; each Active User has one record in the Controller Interface Working
Table.
587
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Similarly, all User Master Views, View and Sub-Views also create and use their
own Working
Tables. The Working Tables used by the Interface Modules contain a Status
field and have a
corresponding Status Field Logic that marks as Active, the Status field of the
record
concerned. In the case of the Controller Interface Module, it marks the record
that contains
the number of the Active User and, in another field, the reference number for
the User Master
View for the Active user. In the case of User Master Views, Views and Sub-
Views, the
Working Table contains one record for each of its junior Interface Elements,
and this records
contains the User Number in one field - the number is the same in each field -
and a Status
field in which the Status Field Logic marks which of the juniors in Active at
each instant.
At the same time as the Field Logic for the User field writes the number of
the User
into the User field of the Controller Interface Module's Working Table, the
Controller Interface
Module's Field Logic for the Personality field queries the Authorized User
Data Assembly
Table to find the record containing the User Number of the Authorized User and
retrieves the
value it finds in that record's Re-start Personality field, and if that field
is empty, it retrieves the
value in the Startup Personality Number field instead. This Field Logic then
uses the number
it finds in the Startup Personality Record Field number to locate a record in
the Personality
Data Assembly Table Personality Number field that has the same number. The
Personality
Field Logic of the Controller Interface Module copies the user's startup
Personality Number
into the Personality field into record for that user in the Controller
Interface Table.
Also at the same time, the Controller Interface Module's View Specification
Field Logic
copies the value it finds in the Re-Start View Specification field of the
users' record in the
Authorized User Data Assembly Table and if that field is empty, instead,
copies the value it
finds in the Startup View Specification Field into its Controller Interface
Table, View
Specification Field in the record for that user.
Finally, the Controller Interface Module's Data Specification Field Logic
copies any
value it finds in the Re-Start Data Specification field of the user's record
in the Authorized
User Data Assembly Table, into its Controller Interface Table, Data
Specification Field in the
record for that user.
The Controller Interface Module Controller Interface table now has a record
containing
the User Number, the user' (startup) Personality Number split into the
respective fields for
each of its parts, the View Specification for that User's User Master View and
potentially a
value in the Data Specification field and this record is marked Active in the
Status field.
When the Controller Interface Module starts the User Master View, the Field
Logic of
the Controller field passes it a copy of its own Controller Interface Table
record for that user
to the Controller Field Logic of the User Master View, which, similarly,
places the record copy
in its own user Master View Interface Table that has been created by the User
Master View's
588
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Field Logic for the Controller Field calling the Working Table Module to
create a Working
Table for it.
If the record the User Master View received from the Controller Interface
Module
contained a Data Specification, the Data Specification Field Logic of the user
Master View
calls the Find Module and gives it the Data Specification reference that was
received from the
Controller Interface Module as a Find Specification, resulting in the data
with which the user
wanted to re-start being found. Since each Active Element is set to display
data from a
specific relative field position in an identified Data Record Set, the data
found is displayed for
the user.
2. Displaying the Personality Image
The Image is simply a pictorial representation of a person or a thing that is
used to
make the user make the user more comfortable about addressing a computer.
A User Master View, a View, a Sub-View or a Menu can display a Personality
Image
but normally, only one Personality Image is displayed per Master View, View or
Sub-View,
and can be displayed either in a Menu bar - a Menu Bar is Sub-View that is a
collection of
Active Element Buttons - or free-floating, i.e. not inside a menu bar. A
Personality Image is
displayed by a specialized Active Element termed a Personality Image Active
Element.
While everything visible on the screen has its own Help, a user can want Help
on
something that is not on the screen, and therefore, one of the primary
purposes of a
Personality Image Active Element is to provide Help on things that are (not
necessarily) on
the screen. Therefore, it is useful to set up the Personality Active Image
Element so that left
clicking on it displays a Sub-View that is a Find Sub-View, where the Find
Specification
contains field values that limit the Sub-View to finding Help records. With
the previously
described Any-to-Any machine methods for recording Help, the method to find
the Help the
user wants, is to find - but not display - the action (Software Module or
Software Module Field)
the user wants Help about, or the data that the user wants Help about, and
then, using that as
a further Find Specification, finding the Help (or Label or Prompt) associated
with that
Specification - i.e. the same Specification of item but where the record type
is a Help Record
(or a Prompt Record, or a Label record.).
On the other hand, right clicking on a Personality Image Active Element can be
used
to display a Sub-View - in such a fashion that the Personality Image appears
to be displaying
it - that enables the user to change something about the Personality. For
example, a Sub-
View can provide a number of Active Element Buttons to guide the user - such
as buttons
labeled 'Want some Help?"Change my Name?' 'Change my look?' 'Change my
behavior?
'Change what I say?' 'Change How I say things?' - in essence buttons that
enable the user to
change a specific part of the Personality. Alternatively, for the more
experienced user, a
589
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
different Sub-View can be used that displays Active Elements for each of the
Personality Data
Assembly Table Change Modules. Such a Sub-View would enable a user to change
anything
in the Personality Image Data Assembly table- for example, the Personality
that is active for
that record or that is active for a specific application.
Personality Image Active Elements are a particular type Single Active Element
containing different Logics to most Active Elements as they have special
functions in respect
of the Personality function. The Field Logics of Personality Image Active
Elements are Logics
that act on the Personality field as follows:
When the Personality Image Active Element is loaded, the Field Logic
of its Controller field creates a Working Table using the Working Table Module
as
previously described.
2. When the User was identified the Controller Interface Module obtained
the Re-start Personality Number, if one existed, and if not, instead obtained
the
Startup Personality Number for that Authorized User. In either case, the
Personality
Number that was obtained was copied by the Field Logic for the Controller
Interface
Module's Personality Field - using the Copy Fields Module - into the
Personality field
of the Active record in the Controller Interface Module's View's Working
Table.
However, when the Personality Number was copied, in the course of the copy the
Combined Number Personality number is split into its respective components,
and
each component placed in placed in its own field in the Working Table, thereby
disassembling the Personality Number into its respective Data Sub-Classes.
3. The User Master View's Controller Field Logic uses the Copy Fields
Module to copy this record into User Master View's Working Table, and with it,
the
Personality Number split into its respective component parts each in its own
field.
4. In addition, the Field Logic for the Status field of the User Master View
Module marks the Status field of this record as Active in the Status field of
its Working
Table.
5. The Field Logic of the View Specification field of User Master View
searches its Active Interface Module record, to find the number of any
Interface Active
Element that is coded as being a Personality Image Active Element. If it finds
a
Personality Image Active Element, it sends that Personality Image Active
Element a
Token telling to it execute.
6. If the User Master View contains a Personality Image Active Element,
when the Field Logic for the Controller field of the Personality Image Active
Element
receives the above Token from the View Specification Field Logic of the User
Master
View Module, it activates the Field Logic in its Personality (Image) field.
The
590
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Personality Image field is the name given to the particular Personality field
that is of
interest to the Personality Image Active Element.
A Data Relation Table field that uses a Combined Number is, in effect, several
Data Relation Table fields, each of which is a Data Sub-Class, that have been
combined into one Data Relation Table field. When Execution is to occur with
one of
the parts making up a Combined Number, it is desirable to disassemble the
Combined
Number into its component parts. Hence, when Execution should occur, Data
Relation Table field A, containing a Combined Number that consists of numbers
D, E
and F, each containing a different Data Sub-Class value, is disassembled into
its
component Data Sub-Classes, and is disassembled into Field A (Data Class A),
sub-
type D (Data Sub-Class D), Field A, subtype E, and Field A Sub-Type F. Hence,
the
Personality Number, in the Personality Field, contains as one of its parts,
the Image
Number for the Personality and hence, when it needs to be used, requires a
Personality, Image field, and it is this Image field that is used by
Personality Image
Active Elements. The Image Number itself a Combined Number consisting of two
components that are Sub-Sub Data Classes in the Personality field. One part of
the
Image Combined Number is the Image Set number - corresponding to the Sub-Level
field - that specifies the group of images to which an image belongs, and the
Image
number - corresponding to the Sub-Sub-Level field - that specifies the number
of a
specific image in the set.
7. The Field Logic of the Personality Image Active Element's Field Logic
for the Image Set field looks up the Image Set Number - part of the Combined
Number Personality Number - in the Personality, Image field of the User Master
View's Working Table record.
8. The Personality Image Active Element Field Logic for the Controller
Field uses the New record Module to create a new record, that the Personality
Image
Active Element Field Logic for the Controller Field marks as a Find
Specification
record.
9. The Field Logic for the Image Set field of the Personality Image Active
Element copies the Image Set Number into the Find Specification. The Image
Number even if one is present, is not copied, because, whether one specific
image
was chosen or not, all images in the Set need to be retrieved anyway, as the
chances
are that another image from the Set will be needed shortly anyway.
10. The Field Logic for the Image Set field adds to the Set Number the
code digit that is used in the Data Relation Table to code the Sub-Level field
of Data
Relation Table records as being Personality Image records.
591
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
11. The Personality image Active Element Field Logic for the Controller
Field passes the completed Find Specification to the Find Module.
12. The Find Module uses the Find Specification it receives to locate all
Data Relation Table records that are coded as Personality Image records with
the Set
number supplied.
13. The Controller Field Logic of the Find Module returns the Token to the
Personality Image Active Element, which now has a fist - in the Token - of the
matching records. _
14. The Controller Field Logic of the Personality Image Active Element
creates one record in its Working Table for each Personality Image record in
the Set.
15. The Controller Field Logic of the Personality Image Active Element calls
a Copy Fields Module, revising the Token it has received so that the Token now
contains, in addition to the record numbers, the fields that are to be copied
from each
record, and specifies the destination field in its Working Tabfe. The Token in
effect
contains an instruction that, colloquially states says 'copy Data Relation
Table record,
one at a time, into the next blank record in my Working table number X. Copy
Data
Relation Table field 44 into field 1 of Table X, Data Relation Table field 45
into field 2
of Table X, (etc) for each of the records, in the following list. Tell me when
you're
done.'
16. Following the instructions in the Token, the Copy Fields Module copies
fields from the found Data Relation Table Personality Image records as
follows:
a. The value in the Sub-Level Field is copied into the Image Set
field of the Working Table
b. The value in the Sub-Sub-Level field is copied into the Image
field of the Working table
c. The Content, Image field is copied into the Content, Image field
in the Working Table.
If the Content, Image fields of the Image records contain an actual
image, the image is copied. If the Content, Image field contains a disk
address, the disk address is copied. If the Working Table can not hold either
an image or a disk address in a single field and yet both are in use in the
application, then the Data Sub-Class division process is continued, by
dividing
the Content Image field into two fields, one of which is Content, Image, Image
-
holding actual images - and the other of which is a Content, Image, Address
field, holding disk addresses. If the Data Sub-Class is further divided in
this
592
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
manner, then, as per the standard methods of the Any-to-Any machine, the
Personality image Active Element will require Field Logics for each field.
17. When the Controller Field Logic of the Personality Image Active
Element receives the Token back from the Copy Fields Module, it instructs the
Field
Logic for its Image field to execute.
Two possibilities exist. The first possibility is that the user has ordered
that a Re-start
should be done in which case, the digits of the Personality Number that
specify the number of
the image to use in the Image Set contains a value - i.e. a specific Image
Number from a
specific Image Set was in use when the user shut down and ordered that the
application
should restart in the state it was when the user logged off.
The other possible situation is that the user ordered the application to start
up the next
time, using his default screen, and in this case, the digits of the
Personality Number that
specify the number of the image to use may be set to zero - i.e. no specific
image in the
Image Set is specified.
18. The Field Logic for the Image field of the Personality Image Active
Element's looks up the Image Number - part of the Combined Number Personality
Number - in the Personality Number field of the User Master View's Working
Table
record. If no specific image was specified in the Personality Number, the
number it
finds will be zero.
19. The Field Logic for the Image field of the Personality Image Active
Element uses the Image Number obtained from the Personality Number to find a
record in the Personality Image Active Element Working Table that has the same
number in the Image Number field.
20. If the Field Logic for the Image field does find a record with the Image
Number it is looking for - i.e. a specific Image Number was specified in the
Personality Number - it passes the record number it finds to the Field Logic
for the
Status field.
21. The Field Logic for the Status field marks the Status field of that record
in the Working Table as Active and then sends an Internal Token - a Token that
goes
between Field Logics in an Execution Record - to the Field Logic for the
Content,
Image field of the Personality Image Active Element.
22. When the Field Logic for the Content, image field of the Personality
Image Active Element receives this internal Token, it executes, and looks for
a record
in the Working Table which is marked as Active in the Status field. It looks
in the
Content, Image field of the Working Table record that is marked Active in the
Status
field, and finds there either the file for the Image itself, or the disk
address for the
593
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
image, depending on how the programmer has stored images. The Field Logic
displays the Image it has found, and the Personality Active Element's display
area
now displays the Image that was specified, or, if the image is a video, it
plays the
video.
The alternate possibility is that no specific image was specified in the
Personality
Number, and then the digit positions within the Personality Number that
correspond to the
Image Number will be marked as zero - i.e. blank. In this case, and assuming
that the
programmer has arranged for the Personality Image to be changed from time to
time at
random, then:
23. If the Field Logic for the Image field does find a record with the Image
Number it is looking for - i.e. a specific Image Number was specified in the
Personality Number - it passes an Internal Token to the Field Logic for
Marking field of
the Personality Image Active Element.
24. The Field Logic for the Marking field requests and receives from the
Field Logic for the Controller field, the number of records it has opened in
the Working
table and supplies this number with a Token to the Random Number Module,
requesting a Random Number and supplying the Random Number Module with the
Highest Number (i.e. the number of records opened received from the Controller
Field
Logic).
25. The Random Number Module generates a random number between 1
and whatever was the Highest Number with which it was supplied in the Token.
26. When the Field Logic for the Marking Field receives back the Token
from the Random Number Module containing the Random Number, it passes an
Internal Token to the Field Logic for the Status field of the Working Table.
27. The Field Logic for the Status field marks the appropriate record as
Active as per step 21 above with the result that:
28. The Field Logic for the Content, Image field executes, as per step 22
above, displaying the image in the Working Table record that is marked as
Active in
the Status field..
If the programmer wishes the Image being displayed should be changed from time
to
time, then:
29. When the Content, Image Field Logic displays an image, it sends an
internal Token to the Field Logic for the Marking Field.
30. The Marking Number Field Logic sends a Token to the Timing Module
telling the Timing Module to return the Token at a time of Now plus X -
whatever value
the programmer has written into the.Marking Number Field Logic. When the
Marking
594
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Number Field Logic receives the Token back from the Timing Module, it repeats
the
previous process. However, when it receives the random number, it first
removes the
Active marking from the Status field of the record that was previously marked
Active,
and only then sends an internal Token to the Field Logic of the Status field.
31. The Field Logic of the Status field does step 21 just as usual, step 22
occurs, and the image being displayed is changed. (The programmer can use
other
and more sophisticated alternatives. One alternative is to write the Marking
Field
Logic so that there is a Timing Record that is copied into the Working Table
and then
write the Field Logic to use this for the value in the Token to the Timing
Module, and in
this case, a Field Logic in the Working Table Time field can use the Random
Number
Module to generate a number that the Timing Field Logic places in the Marking
field of
the Timing Record, using an Internal Token to tell the Field Logic for the
Marking field
to look for that number.).
The effect of these operations is to display the Personality Image and change
it from
time to time.
As different Software Modules and data are selected and used, it may be that
the
Personality field in some of the Modules record or data record that are used
may contain a
Personality Number that specifies that a specific Personality Image Set
Number, or a specific
Image Number from a specific Personality Image Set Number should be used. It
is possible
that a Data Record could contain a Personality Number while the Software
Module
Personality Field contains none, or another Personality Number.
Every User Master View Module, View Module, Sub-View Module has both a Working
Table as already described for a user Master View Module, and also Field
Logics as
described above. (The only real difference between a User Master View, View,
and Sub-View
Modules controlling the screen is which interface Element assembly is the
junior of which
other Interface Element Assembly. However User Master Views of different types
do exist for
other output routes - modems, printers etc).
Taking the case of a Sub-View Module, every Interface Element assembly such as
a
Sub-View contains a number of Active Elements that have their Active Elements
set so as not
to display, but these Active Elements are within the Interface Element
Assembly and
consequently, can make data from their respective Data Relation Table record
fields available
to the interface Element Assembly such as a Sub-View. Active Elements of this
type are
called Hidden Active Elements - or Hidden Elements - and their ability to be
activated by
mouse click is also turned off. Each time a Hidden Element arrives in an
interface Assembly,
its logic sends a Token to a specific Field Logic in the Interface Assembly,
such as a Sub-
View.
595
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Each time another record arrives in a Sub-View, the Sub-View's Field Logic for
the
Record field -notified of the arrival by the Token received from the record
Number Hidden
Element - uses the Copy Fields Module to copy the numberls of the newly
arrived records
into the Record Number field in the Sub-View's Working Table, at the same time
copying the
Personality Number from that record or those records, if one exists,
disassembling it into its
component parts and copying it into the Personality fields of the Sub-View's
Working Table.
The Field Logic for the Record field sends an internal Token to the Status
Module, which
marks the appropriate Working Table recordls as active. At the same time the
Field Logic for
the Record field sends another Token, containing the record number of the new
record, to a
Module that is part of all interface Element assemblies such as User Master
Views, Views and
Sub-Views, called a Personality Check Module. When a Module or data record
leaves the
Sub-View, the Controller Logic of the Sub-View deletes the Working Table
Record belonging
to the departed records.
If there is a Personality Image Active Element in the Sub-View, when it loads,
its
Controller Logic sends a Token containing its record number to a Personality
Check Module
stating it exists. If the Personality Image Active Element is later on removed
by the user, the
last action it does before terminating is to send another Token to the
Personality, Application
field, stating that it no longer exists.
If the Personality Check Module of the Sub-View Module has been told by the
above
Token that a Personality Image Active Element exists in the Sub-View, each
time it gets a
Token from the Record Field Logic:
1. Its Controller Logic uses its Field Logics to check which of the following
are different in the newly arrived record to the values contained in the
various fields of
the Sub-View's Working Table:
1. Application Number
2. Application Number
3. Seniority
4. Image On l Off
5. Image Set
6. Image Number
7. Sound On/Off
8. Sound Set
9. Sound Number
10. Screen OnlOff
11. Screen Set Number
12. Screen Number
596
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
13. Label On / Off
14. Label Level
15. Label Style
16, Label Number
17. Prompt OnJOff
18. Prompt Level
19. Prompt Style
20. Prompt Number
21. Help On/Off
22. Help Level
23. Help Style
24. Help Number
The Personality Number values are not considered to be different, if the value
for that number in the newly arrived record is blank - i.e. zero.
2. If any of the above 24 numbers are different, the Controller Logic of the
Check Module creates a Change Record in which each field that needs to be
changed
- i.e. each field that was found to be different - is marked.
3. compares the Application Number in the Sub-View's Application field
with the Application Number in the Personality Image Active Element. If it
finds they
are the same, it terminates that Execution and takes no action until it
receives a new
Token from the Field Logic of the Record field, and then repeats the
operation.
If it finds that the Application Numbers are different, then the image needs
to be
changed to the image that is recorded as being used by that application. In
order to do this, it
calls an Image Change Module that:
4. Looks up Personality Data Assembly table to find a record, which has
that User's Number in the User field, and the Application Number it has found
in the
newly arrived record. If it does not find such a record, it terminates and
takes no
further action.
5. If it does find such a record, then it calls a Copy Record Module to copy
the Active record in the Sub-View's Working Table.
6. When the record is copied it disassemblies the Personality Number it
found in the Personality Data Assembly Table record and copies it into the
various
Personality fields of the new record in the Sub-View Working Table. It then
sends a
Token to the Field Logic of the Status Field to mark the record presently
marked
Active, as Inactive, and to mark the copied Record as Active.
597
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
7. When it receives the Token back stating that the copied record is now
marked Active, it sends a Token to the Personality Image Active Element
telling it to
execute.
8. The Personality Image Active Element then executes step 6 (above)
onwards, with the effect that the image is changed from the previous image to
the one
stated for the new Application.
Collated from the digits for the reference numbers of the Record Number,
Select
Level, and Style fields and in addition contains two further digit positions,
one of which states
if the image is to display, another stating whether Sound files are to be used
- 'Sound On',
and a final digit stating whether Text to Speech is to be used on messages -
'Text On'.
Because the Personality Number in each Data Relation Table record does contain
digit positions for Select Level, Style, Sound On and Text On, suitable
Software Modules can
change these settings for individual Data Relation Table records, without
changing the overall
level to be used, which is stated the Personality Data Assembly Table record
for that
Personality and that User. Changes to that the user wants to make to these
settings are
made by Software Modules associated with the Personality field. Changes that
the
application makes to these settings based on what the user does - normally the
degree to
which he gets faster with specific actions - are made by Software Modules
associated with the
Use Index field.
Personality Image Data Class Table
The main purpose of the Personality Image Data Class table is to enable the
user to
choose an Image set, or, to use images he has created himself. This table
contains or
displays one image per record, and generally contains the following fields:
1. Record Number contains the number of the record in the table.
2. Name. This field contains the name given to a set of images by an
application provider - such as Mr. Abraham, Joey.
3. Suitable. This field contains a description given to Personality by an
application provider and generally can be used to describe the functions for
which the
application provider considers the Personality to be suitable. Hence this
field contains
user information that can be either held in the field itself, or as a disk
file, in which
case the field contains the disk address of the data.
4. Image Set. This field contains a number that states to which set an
image belongs. Thus if there are a dozen photographs of the same person in the
set,
each one has the same number in an Image set, while another set of photographs
of
another person have another image set number.
5. Image Number
598
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
6. Image Address. Image contains either the image of the person, or the
disk file name of the individual image that the appropriate Active Element in
the table's
Sub-View uses to display the image file either when the Active Element is
clicked or
when the cursor hovers over it.
The Personality Image data Class Table is accompanied by - and can contain -
its
own Software Module and a Sub-View providing a suitable display to enable the
user to do
this. In addition a small Find Module should be included and suitable Find
Specifications to
enable the user to set the value of the Image Set field to select all images
in a given Image
Set. Normally, the Field Logic of the image field of the Personality Table
Software Module will
call the Personality Image Table Software Module if the user indicates he
wishes to change
the Image Set, and the Personality Image Table Software Module actually takes
care of
administering the changes.
A further Software Module needs to be provided in order for the user to be
able to
create his own Image Set. This Software Module essentially creates a new
record in the
Table and then asks the user to give it an Image Set number and designate the
disk address
of the image file.
Once the user has chosen a particular image set, the number of the chosen set
is
entered into the Image field of a new Personality Data Assembly Table being
created for that
user. If an existing record is being changed, as per the standard method of
the Any-to-Any
machine, the previous record is copied, marked Inactive in the Status field,
and changes are
made to the copy.
Usage of Image reference values
Personality Sound Data Class Table
The main purpose of the Personality Sound Data Class table is to enable the
user to
choose a set of Sound files or, to use sound files he has created himself.
When Sound files
are used for musical sounds and to contain supplements to Labels, Prompts and
Help, then
the Sound Data Class Tables can contain both of these. When, however, Sound in
the form
of recorded spoken text is used to partly or wholly replace Labels, Prompts
and Help - for
example for blind people or for control via an auditory channel such as a
telephone, then the
Sound file is confined to non-recorded text, and recorded text replacements
for Labels,
Prompts and Help are handled by their respective Data Class Tables.
This table contains one Sound file per record, and generally contains the
following
fields:
9. Record Number contains the number of the record in the table.
10. Language. Language states the language in which the sound set is
recorded and is only needed if a) the Sound fifes contain recordings of spoken
text
599
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
and b) more than one language is used. The reference number used in the field
is
the record number in the Language Data Class Table that contains fields for a
record
number, one field the name of the alphabet of the language (if the languages
used
use more than one alphabet) and a field for the name of the Language written
in the
alphabet of the language concerned.
11. Suitable. This field contains a description given to Personality sound
files by an application provider and generally can be used to describe the
functions for
which the application provider considers the sound files to be suitable.
12. Level. The word 'Level' is used to indicate a particular level of user
ability. Sound - in the form of text that is read, and recorded as a sound
file - can be
used to replace Labels, Prompts or Help, and this is useful for any
application that is
to operated using an auditory control channel such as a telephone or a radio.
Sound
Sets should be provided for different levels of user ability and can also be
provided in
different languages.
13. Sound Set. This field contains a number that states to which set a
sound file belongs.
14. Sound. Sound contains the disk address of the sound file. When the
Active Element for the field is clicked, or when the cursor hovers over a
Screen field
entry, the sound file whose disk address is in the Svund field is played.
15. Text. When the sound file reads a text, this field displays the text that
is read.
The Personality Sound Data Class Table is accompanied by - and can contain -
its
own Software Module and a Sub-View providing a suitable display to enable the
user to do
this. In addition a small Find Module should be included and as well as
suitable Find
Specifications to enable the user to set the value of the Sound Set field to
that of the sounds
in a single Sound Set. Normally, the Field Logic of the Sound field of the
Personality Table
Software Module will call the Personality Sound Table Software Module if the
user indicates
he wishes to change the Sound Set, and the Personality Sound Table Software
Module
actually takes care of administering the changes.
A further Software Module needs to be provided in order for the user to be
able to
create his own Sound Set. This Software Module essentially copies the records
for one of the
existing Sound Sets, and displays them one by one, asking the user to record
whatever he
wants said in place of the previous message, or alternatively, to enter the
disk address of a
sound file.
Once the user has chosen a particular sound set, the number of the chosen set
is
entered into the Sound field of a new Personality Data Assembly Table being
created for that
60o
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
user. If an existing record is being changed,, as per the standard method of
the Any-to-Any
machine, the previous record is copied, marked Inactive in the Status field,
and changes are
made to the copy.
Usage of Personality Sound Reference Values
Personality Screen Data Class Table
Screens that either too complex for a given user are hard for him to use. A
screen
that is simple enough for a new user will only irritate an expert user and one
that is suitable
for an expert will be incomprehensible for a new user. Screens that are to
simple for a more
sophisticated user are hard to use in the sense that they require him to
perform unnecessary
manipulations in order to see what he wants to see, and, if a Language
Processor is in use,
can require additional manipulation steps that can be effectively difficult
without user
intervention. Hence a prime requirement for ease of use is that screens can be
as simple or
as complex as each individual user requires. However, state of the art
practice is to hard
code the screen to the underlying Execution, with the result that is not
possible in practical
terms to provide suitable screens for different levels of competence, as to do
so requires
duplicating the Execution structure also - in effect producing complete new
version of the
same program.
The methods of the Any-to-Any machine solve this problem, firstly - as already
described - by separating screen control and display mechanisms from the
underlying
Executions, so that any number of screens can be used with any given Execution
or group of
Executions. The second part of the solution to the problem is provided by
mechanisms that
allow groups of screens, collectively constituting a visual interface, to be
related to
Executions, so that users can select from different sets of screens, and
choose a set this is
most suitable for them. The Personality Screen Data Class Table and associated
methods
provide this second part of the solution.
The first purpose of the Personality Screen Data Class Table is to enable the
user to
choose a set of Screens or, to use sets of screens that he has created himself
This Table
contains allowing the user to choose the complexity level of screen layout he
wants to use.
Other fields can be added if required, allowing the user to try and use
different color
schemes. The Table generally contains the following fields:
Record Number contains the number of the record in the table.
2. Suitable. This field contains a description given to screen by an
application provider and generally can be used to describe the functions for
which the
application provider considers the screen to be suitable. Hence this field
contains
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
user information that can be either held in the field itself, or as a disk
file, in which
case the field contains the disk address of the data.
3. Screen Set. This field contains the number of the screen set to which
the screen whose reference is contained in the next field belongs.
4. Screen. This field contains the number of an Active Interface Module
Record of one complete View. When the Active Element for the field is clicked,
or
when the cursor hovers over a Screen field entry, the View whose Active
Interface
Module record number is in the Screen field is displayed, either full size or
in a
reduced size version.
5. Behavior This field sets the behavior of the screen, particularly whether
it displays all Active Elements for its data fields simultaneously, or
displays them only
one at a time and then only for the fields for which the Condition is not
satisfied - a
behavior that is more useful for
The Personality Screen Data Class Table is accompanied by - and can contain -
its
own Software Module and a Sub-View providing a suitable display to enable the
user see
samples of and choose a particular set of Screens. In addition a small Find
Module should be
included and as well as suitable Find Specifications to enable the user to set
the value of the
Screen Set field to that of the screens in a single Sound Set. Normally, the
Field Logic of the
Screen field of the Personality Table Software. Module will call the
Personality Screen Table
Software Module if the user indicates he wishes to change the Screen Set, and
the
Personality Screen Table Software Module actually takes care of administering
the changes.
A further Software Module needs to be provided in order for the user to be
able to
create his own Screen Sets. This Software Module essentially copies the
records for one of
the existing Screen Sets, and displays them one by one, displaying a list of
all existing
screens - i.e. complete Views asking the user to choose which of these he
wants to use to
replace the screen being displayed. Additionally a Single Active Element gives
the user the
opportunity to create a new View, and, when he is finished, to use the View
just created to
replace any of the existing screens in the set.
Once the user has chosen a particular screen set, the number of the chosen set
is
entered into the Image field of a new Personality Data Assembly Table being
created for that
user. If an existing record is being changed, as per the standard method of
the Any-to-Any
machine, the previous record is copied, marked Inactive in the Status field,
and changes are
made to the copy.
Personality User Message Data Class Tables. The main purpose of the User
Message Screen Data Class Tables is to enable the user to choose a style of
user messages
- Labels, Prompts and Help - that suits him. The programmer can provide as
many styles as
602
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
he chooses - happy, serious, flippant, businesslike etc, but the provision of
each one requires
the programmer to write a full set User Messages - Labels, Prompts and Help -
in that style.
For each style that the programmer provides, he should also provide an
adequate
number of different Levels of each single Label, each single Prompt and each
Help -
remembering that each field in his Views and Sub-Views requires at least one
of each. In
some cases it is desirable for the programmer to provide several of each so
that the
Personality can change between them and provide the user with some human-like
variety on
less critical messages such as greetings, advices of something happening, etc.
In the state of the art, a considerable part of lack of Ease of Use arises
from
the fact that very little that appears on a screen is adequately and properly
explained
in normal language that the a non-computer person can understand, and the
provision of these mechanisms allow a programmer to remove these Ease of Use
problems if he wishes to remove them.
Personality Label / Prompt l Help Data Class Tables
Each of these tables is constructed in a similar manner and each has the
similar main
purpose enabling the user to choose Style and a Level for either Labels,
Prompts, or Help.
Each table holds the entirety of the entries for its Data Class. Labels for
tables
Each of these tables generally contain the following fields:
1. Record Number. The field contains the number of the record in the
table but is not normally used for any other purpose
2. Reference Number. Each single Label, each single Prompt, and each
single Help text has one record in the table. The method used to create the
reference
number is described at the end of the list of table fields.
3. Language. The field contains a reference number for the language in
which the Label Prompt or Help is written and is needed if more than one
language is
used.
4. Level. The word 'Level' is used to indicate a particular level of user
ability. All Label, Prompt and Help records are written in multiple levels
that are
designed for different levels of user literacy and computer competence. The
simplest
levels explain the subject in adequate details and with adequate illustrations
and in
language that avoids any technical terms and is suitable for a not very
literate person
of limited intelligence, while the highest levels explain something very
briefly and may
use technical terms when doing so.
603
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
5. Style. This field contains the number of the style in which the particular
Label l Prompt I Help entry is written - styles can be friendly, subservient
etc.
6. Label / Prompt l Help Text. This field contains the actual text of the
Label / Prompt ! Help.
7. Sound. The sound field is required when the written text of a Label /
Prompt or Help is to be replaced by a sound recording of the text being
spoken, or
used interchangeably with the written text.
8. Image. The image field is required when the written text of a Label / _
Prompt or Help is to be replaced by, or complemented by a separate image of
video.
0 9. Data Type This field contains a written description of the field name and
value to which this Label / Prompt l Help applies.
This reference number is the number that is used, as the reference number in
Label,
Prompt and Help records and is a Combined Number that is created as follows:
1. Each individual Label, Prompt and Help can exist in a number of
different styles each of which can exit in a number of different levels
suitable for
different levels of user competence. All the different versions of a given
Label,
Prompt, or Help, are given the same first digits as the first part of the
reference
number. For convenience, these first digits are usually the record number of
the very
first version of any given Label, Prompt or Help.
2. The next three digit positions state the Language in which the Label,
prompt or Help is written.
3. The next two digit positions state the Level of that particular Label,
Prompt or Help.
4. The next two digit positions state the Style.
5. The next digit position states whether text is on or off.
6. The next digit position states whether sound is on or off
7. The next Digit position states whether image is on or off.
When a Label ! Prompt / Help record is created using different references from
the
Label / Help Prompt in its fields:
1. Only the first part of the reference number above -1 above - is used;
this is the reference number covering all forms of that particular Label /
Prompt ! Help
in all its forms
2. The remaining digit positions are entered as zeros - note that zero may
therefore not be used as a number when numbering a Level, Style, or whether
text,
sound or image are on or off.
604
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Once the user has chosen a particular Label / Prompt 1 Help style and level,
the
number of the chosen Style and the number of the chosen Level is entered into
the Label /
Prompt l Help fields of a new Personality Data Assembly Table being created
for that user. If
an existing record is being changed, as per the standard method of the Any-to-
Any machine,
the previous record is copied, marked Inactive in the Status field, and
changes are made to
the copy.
The Personality Label / Prompt Help Data Class Table are accompanied by - and
can
contain - their own Software Modules and Sub-Views and Label records to
provide a suitable
display to enable the user see, andlor hear, hear particular Label l Prompt /
Help records as
samples of a set of such records and to enable him to chose a particular set.
In addition a
small Find Module should be included and as well as suitable Find
Specifications to enable
the user to set the value of the Level and Style fields to his chosen level
and style of a single
Label / Prompt or Help. Normally, the Field Logic of the Label / Prompt / Help
field of the
Personality Table Software Module will call the Personality Label / Prompt /
Help Table
Software Module if the user indicates he wishes to change one of them. The
Label / Prompt l
Help table Software Module actually makes the change.
Further Software Modules need to be provided in order for the user to be able
to
create his own Label / Prompt / Help entries. These Software Module usually
display the
Table concerned in the normal fashion but provide a further field in which the
user can write,
or record different text, and provision is made for him to enter the disk
address of any image
files he wants to use. When the user starts to make the first change, the
entire level for that
style is copied and the next available style number is written into all the
copied records,
replacing the previously existing style number. If the user is enabled to make
his own Label /
Prompt / Help records in this manner, fields can be added to the table, if
desired, to state the
name of creator of the style (i.e. a User name field) and a field to cover a
description of the
style (i.e. a Content field).
Usage of Label / Prompt / Help reference values.
Because Label, Prompt and Help records are created using only the part of the
reference number that states every Label, Prompt of Help record for a given
field, no matter
what its style or level, when the time comes to actually display the Label,
Prompt or Help, with
the following method, the correct style and level for the operative user can
be displayed:
When a user Logs on, the User Master Interface Module copies all
Personality Data Assembly Table record for the User Number of its User into a
specific memory area where all Active Interface-Modules look for data from
those
records when they need it.
605
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
2. The Active Interface Element that should display a Label, Prompt, Help,
or Help record obtains the reference number from the field of the Label,
Prompt or
Help record that it is servicing. This number contains only the first part of
the
reference number, the rest being zeros.
3. It looks up the Personality that is in use in the particular record
4. three digit positions state the Language in which the Label, prompt or
Help is written.
The next two digit positions
The methods described above for the Personality Image, Sound and Screen Data
Assembly Tables allows the user to choose an overall level of these for
general use.
However, if the programmer wishes to provide a finer level of control than
this - enabling the
user to change these for each and every data type, then the following
additional methods
need to be used:
PERSONALITY DATA CLASS SOFTWARE MODULES
If a user gives an order to particular Personality - for example to alert him
when
something arrives, the number of Personality to which the order was given will
be recorded in
the Personality Field in that Condition record. If the user subsequently uses
another
Personality, and while doing so, the Condition described in the user's order
is met, then the
fact that it contains the number of the Personality to whom the order was
given, enables
suitably constructed to Software Modules to give the alert to the user, using
the Personality
that received the original order.
17) Field 18 - JOIN
JOIN FIELD
The JOIN field provides a mechanism by which several Data Relation Table
records
can be used to state data that are all part of the same thing, but, that
cannot be held in a
single record.
The AND H field allows, when used to state a communication, for one sender -
the A
or AND record - to have a number of AND WAS records - i.e. B records or
recipients, and
each one of these can have a different status such as Via, Cc, For Info.
When - for example - several people sign a letter, they act as a sending
group, in
which difference between one Data Relation Table and another is the sender's
name and
potentially his post title, but the remaining facts are the same.
The method to enable this relationship to be represented correctly in the Data
Relation
Table is as follows:
606
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
1. Each sender has a Data Relation Table data record that records the
correct data as it applies to him.
2. Each such record is assigned the same number in the JOIN field, and
that number is the next number for use in the JOIN field.
3. The order is which a number of Data Relation Table records are
recorded is stated by their respective Record Numbers.
JOIN FIELD RECORD TYPE
Some of the possible uses for the JOIN record type are:
1. State the order of (of use) for the various records that are included in
the JOIN. (This can also be done using the Administration Field named
'Order').
2. Describe as a whole that have a specific JOIN. Number.
3. Control the use of al! or any JOIN records by Software Modules.
4. Acts as a list of other Data Relation Table records or this and other
JOIN numbers and thereby create an overall group of groups of records - that
can be
named using the 'Name' Administration field -
5. Point to a Sequence record that contains in each pair of fields:
- A User number (User numbers will be described shortly; they are a
number assigned to a specific user).
- The number of a JOIN Data Relation Table record of any of the above
types of JOIN record - for example one that contains the order in which a
specific
user uses a group of records with a specific JOIN number.
Sequence Records of this type - that contain more than one type of
reference number - are termed 'Compound Sequence' records as opposed to
a simple 'Sequence' record that contains only one type of data in its fields.
Compound Sequence records are one way of recording the relationships of
groups of things. Other methods will be described in relation to the
appropriate
Data Relation Table field.
JOIN DATA CLASS TABLES
Data Class Tables are not normally required for the JOIN Data Class. A number
of
different types of JOIN Data Class Assembly Tables can be constructed
usefully. Some
examples of Data Class Assembly Tables that can be created and used for this
Data Class
are as follows and demonstrate that in many cases it is practical to assemble
Data
Components either in the Data Relation Table or in a Data Assembly Table:
- To list the records for a given JOIN value. For example, Software Module
records that have a specific JOIN number can be listed in a JOIN Data Assembly
Table,
while the same function can be performed in for other data types such as user
data in a
607
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data Relation Table JOIN record. In this manner, a grouping of user data using
JOIN can
be available to the user, while a grouping of Software Module records is not
available to
the user, only to the programmer. (In both cases, suitable View Modules are of
course
required to make the data visible).
ORIGINAL ITEM FIELD
The term 'Original Item' is defined as Version 1 of an item - i.e. the first
of a particular
item from which other Versions are subsequently made. The Original Item Data
Class is
primarily a Numbers Data Class, containing the number assigned by Original
Item Field
Logics that are part of each New Item Creation type of Software Module, or by
an Original
Item Module called by Original Item Field Logics to assign the Original Item
number. Within a
series of Data Relation Table records - for example, working from the most
recent backwards
- numbers in the Original Item field can appear in any order. For example, the
user can now
create a new Version of an item that was first created long ago, and which
therefore has an
Original Item number that was assigned long ago, - the most current Original
Item number is
likely to be a much higher number than the Original Item number in the new
Version of the old
item. Rather than searching every Original Item field in every record to
determine the latest
number, it is more convenient to keep an Original Item table as a one field
table containing
the latest Original Item number assigned. In the even that more than one
Software Module is
operating that needs to assign a New Item Number, the Original Item Table
provides a
common place for each of them to find and assign the next Original Item
number. An Original
Item Field Logic in a Module that.is creating a new item - or an Original Item
Module - looks
up the number in the Original Item Table, adds one to that number, and then
writes that
number into the Original Item Number of each of the record making up the item.
ORIGINAL ITEM FIELD, TYPICAL LABELS
A typical Label might be 'Number of the Original Item'
ORIGINAL ITEM RECORDS
Original Item Records can be used to state data concerning the original it or
notes
about it (i.e., entries in the content field of the record that describes the
Original item) etc.
3O ORIGINAL ITEM DATA ASSEMBLY AND DATA CLASS TABLES, AND SOFTWARE MODULES
As a numbers Data Class, Data Assembly and data Class Tables are normally not
necessary and specialized Software Modules are normally not necessary either,
as Original
ltem Administration is taken care of by the Original item Field Logic in the
appropriate
Software Modules.
6o8
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
18) Field 29 - DESTINATION
The following fields - Destination, Sub-Destination, Origin, Sub-Origin and
Data
Specification - are all fields that are used to control internal communication
within an
application, for example, when one Software Module or Execution Record sends a
Token to
. another Module or receives one from another Module. They are also used to
control external
communication when one Data Relation Table sends or receives records with
another,
remote Data Relation Table.
DESTINATION IDENTITY NUMBER FIELD
When one Execution Record sends a Token to another, the number of the
Execution
Record to receive the Token is placed in the Destination Identity Field by the
Controller Logic
of the Execution Record that is sending the Token, which also places the
number of the
Execution Record that sends the Token is placed in the Origin field. With this
method, the
Software Module that receives a Token has the data available to know where the
Token came
from - and hence, potentially, where the Token should be returned when its
task is finished.
If the Token consists of more than one record, then the Data Specification
fieid in each Token
record being sent contains the number of a Token List record listing the
record numbers of all
the records than make up the complete Token package.
When Software Modules exist that enable Data Relation Table records to be
transmitted to a remote Data Relation Table, the Destination Identity Number
field contains
the number of the Data Relation Table to which the records are to be sent.
DESTINATION IDENTITY NUMBER RECORD TYPES
Destination Identity Data Relation Table records of different sub-types can be
used to
contain a complete history of the transmission of a given Data Relation Table
record or set of
records. In this case, the Destination Data Relation Table Identity Number
record (or records)
can be Sequence type records, containing in each field one Data Relation Table
Identity
Number for each Data Relation Table that passed on the record. As another
example, a
Destination Origin Data Relation Table Identity Number record, sub-type data
record, could
contain data concerning the sending Data Relation Table. Any Data Relation
Table Identity
Number record - containing data about the originating Data Relation Table -
can be part of
any transmission, and thereby convey data concerning the originating Data
Relation Table.
Alternatively, when particular Data Relation Table records are to be
transmitted to a number
of remote Data Relation Tables, Destination Identity Number Sequence records
can be used
to list a group of Data Relation Tables to which records are to be sent, and
this list, since it is
retained, can be used again. When the user groups a number of addressees
together and
gives the group a name, a suitable Software Module can automatically send an E-
mail to
each of the addresses in the group to ascertain if they are using an
application built with the
609
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Any-to-Any machine methods, and if so, to set up communications between the
applications
using a suitable Software Module. A suitable Module in the user's application
can then
construct Destination Identity Number list records, when the user sends
communications to
such a group. When Destination Identity Number list records are constructed in
this manner,
they should be identically named with the name of the group to which they
correspond. A
further type of Destination Record can contain a routing for the records in
the transmission -
i.e. Data Relation Tables through which a transmission is to pass.
DESTINATION IDENTITY NUMBER DATA ASSEMBLY TABLES
Communications directly between applications with methods of the Any-to-Any
machine requires the ability to provide information so that the receiving Data
Relation Table
can check the authenticity and acceptability of incoming communications,
exchange
passwords, state encryption routines to be used, etc, and all these can be
stated in a
Destination Identity Number Data Assembly Table with one record for each of
the destination
applications. In addition such a Table will need to contain the Location Name
and
transmission methods to be used for each Destination Data Relation Table.
DESTINATION IDENTITY NUMBER DATA CLASS TABLES
Destination Data Relation Table Identity Number is a Numbers Data Class and
the
description for Numbers Data Class Tables in general apply. Normally, there is
no
requirement for an Origin Data Relation Table Identity Number Data Class Table
unless the
application is to communicate with other similar applications, and in this
case, a Destination
Data Class Table or Tables will be required to record the translation of the
various terms used
in the Destination Identity Number Data Assembly Tables.
DESTINATION IDENTITY NUMBER DATA CLASS SOFTWARE MODULES
Software Modules of particular importance to this Data Class are Software
Modules
that take care of authentication between remote Data Relation Tables and
encryption of
transmissions between remote tables.
The most secure form of data encryption is the one-time pad, in which the
meaning of
a code transmission is found by using the code to look up a document that
contains the actual
meanings, and such a document is only used once, the word 'pad' referring to
the fact that it
is a pad of such documents. Transmission between Data Relation Tables in
Numbers
Language is itself a form of one-time pad, in that the actual Spoken Concept
Language
values to which the Numbers Concept Language numbers refer is does not need to
be
transmitted between communicating Data Relation Tables, provided that both
tables use the
same Data Class Tables. The one-time pad method achieves confidentiality
effectively by
splitting the message into two parts - the part containing text, and the part
containing the
code to that text, and separating the transmission of the two parts in time
and space.
610
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
The Any-to-Any machine methods allow this method to do be carried further, by
splitting the message into four parts and transmitting each of them
separately, as follows:
1. The Encoding Software Module first of all takes the contents of all Data
Class Tables, mixes them up and transmits them to the Destination Data Class
Tables, where the Decoding Module stores them as received.
2. The Encoding Module encrypts its corresponding Decoding Module and
transmits that, which is also stored.
3. . When the Encoding Module needs to transmit to the Destination Data
Class Table, it transmits a code that tells the Decoding Module how to sort
the
transmitted Data Class Contents, enabling the Decoding Module calculate which
number and Data Class to assign to which value.
4. Finally, the Encoding Module transmits the Data Relation Table records
it wishes to transmit - in Numbers Language, and hence as a continuous string
of
numbers - together with a code that the Decoding Module uses to know the order
in
which Data Class Numbers Language Values are being transmitted for each
record.
The advantage of this method is that one application can set up its own
Encryption
with any other application, the Encoding Module can frequently generate new
versions of
itself and of its Decoding Module and transmit them, and anyone can write
their own
Encoding Software Modules provided these basic principles are followed and
there is no
requirement for the Destination to obtain software from elsewhere before the
process can
begin.
A useful method for transmitting records between Data Relation Table tables is
that a
Copy To Transmit Software Module first copies the records to be transmitted,
and then during
the copy process writes the Data Relation Table Identity number of the Data
Relation Table
whose records it is copying into the Origin Data Relation Table Identity
Number field. Since
these Copy To Transmit records are retained as the Copy to Transmit record
type, they form
a record of what was to be transmitted. A second Software Module in termed
'Copy Transmit'
- clears the Data Relation Table Identity Number field and Sub-Data Relation
Table Identity
Number in each of the Copy To Transmit record it actually transmits.
Software Modules in a Data Relation Table that receive the transmission,
receive each
Data Relation Table record with the number of the Data Relation Table that
sent the record
recorded in the Origin Data Relation Table Identity field.
With this method, each Data Relation Table also keeps a record of the number -
and
hence the identity - of each Data Relation Table record from which it received
records and
also keeps a record of the number - and hence the identity - of each Data
Relation Table to
which it sent any Data Relation Table record.
611
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Destination Records accompanying a transmission of Data Relation Table records
can
be used to control the routihg of communications. For example, if a
communication is sent by
one user via someone else to a third person, each in different countries and
all using
applications built with the methods of the Any-to-Any machine, a VIA OUT
Software Module
can construct a Destination Record sent with the transmitted records such that
The Via Out Module uses the Location Name for the respective
addresses to look up and enter the Numbers and transmission methods
corresponding to the Data Relation Table s operating at those destinations.
2. Codes the Destination Record such that the corresponding VIA IN
Module at the Destination waits for the person who is the via to sign off on
the
communication before transmitting it to the next destination - or
destinations, if a
group of people are to receive it after the person who is the Via has signed
off.
Equally, suitable Software Modules can construct Destination Records to
specify that
a transmission is made to a remote Data Relation Table, where other suitable
Software
Modules split the transmission and send it to a number of local Data Relation
Tables.
19) Field 30 - SUB-DESTINATION
Sub-Destination Data Relation Table Identity Number Field, Record Types, Data
Assembly Tables, Data Class Table and Software Modules are similar to the
Destination
Identify Number Data Class, and are available to further define destinations.
One use can be
to state further destinations once the prime destinations are satisfied
Any Data Class and any field can have its own record type, and the sub-types
of that
record type can be any combination of at all of any number of any record type.
One of the
most useful record types in every field are Condition Record / Director Record
pairs. In the
case of Destination and Sub-Destination record types, these can be used to
direct a
communication to one destination or set of set of destinations if Condition 1
is satisfied, either
by the transmission itself, or in the course of Conditions encountered during
the transmission
process, and to direct it to another set of destinations and sub-destinations
if Condition 2 is
satisfied, and so on. In effect this can result in trying a number of
different routes and
methods to communicate to someone, and enables a computer to carry out the
equivalent of
an order to a secretary such as: "if the office phone doesn't answer try his
home, if that
doesn't answer try the mobile, and it that doesn't answer, send an e-mail."
20) Field 31 - ORIGIN
ORIGIN IDENTITY NUMBER FIELD
When one Execution Record sends a Token to another, the number of the
Execution
Record sending the Token is placed in the Origin Identity Field by the
Controller Logic of the
Execution Record that is sending the Token, which also places the number of
the Execution
612
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Record to receive the Token in the Destination field. With this method, the
Software Module
that receives a Token has the data available to know where the Token came from
- and
hence, potentially, where the Token should be returned when its task is
finished
When Software Modules exist that enable Data Relation Table records to be
transmitted to a remote Data Relation Table, the Origin Identity Number field
contains the
number of the Data Relation Table from which the records are sent.
ORIGIN IDENTITY NUMBER RECORDS
Origin Identity Number record, Condition Record and Director Record sub-type
pairs
can be used by Origin Identity Number Software Modules to re-direct, refuse,
or alert the
user, or otherwise manipulate incoming records, even if the source is itself
otherwise
acceptable. An order of the type: "if my wife sends an e-mail containing
xyz,° is an example
of the. user of such a Origin Identity Number Condition Director pair, and is
created by the
user.with a suitable Software Module.
ORIGIN IDENTITY NUMBER DATA ASSEMBLY TABLES
Origin Identity Number Data Assembly Tables can be used similarly to
Destination
Identity Number Data Assembly Tables, but with respect to items received as
opposed to
items sent. While it may be acceptable to send and also to receive anything
from a given
destination, this is not automatically so. Destinations can exist from to
which it is acceptable
to send only X, and from which it is acceptable to receive Y.
For example, it can be not acceptable to send anything to clients concerning
confidential matter, but it can be acceptable to receive anything from them
that happens to
concern the confidential matter.
Thus one use of Destination and Origin records is to state what can, and what
cannot
come into or go out of the establishment where the Data Relation Table exists.
ORIGIN IDENTITY NUMBER DATA CLASS TABLES
Similarly to the Destination Data Class, a Data Class Table is needed if
values in an
Origin Identity Number Data Assembly Table need to be shown to the user in
Spoken
Concept Language, or if different Numbers Language symbols are used in another
language.
ORIGIN IDENTITY NUMBER SOFTWARE MODULES
The operation of Software Modules associated with the Origin Number Software
Data
Class are similar to those for the Destination identity Number Data Class, but
concern the
Origin of the communication.
While it is more convenient and easier if applications at both ends operate
with
applications built with the methods of the Any-to-Any machine, nothing in
these methods
prevents the application operating with incoming and outgoing communications
where the
other terminal is an application written with previous state of the art
methods. In this case,
613
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
however, the incoming communication is sent to an Incoming Converter Software
Module that
is specifically designed to detect the presence of Data Class values, and
create Data Relation
Table records in normal format, as well as saving the entirety of the incoming
item in the
appropriate Content Data Classes. Such an Incoming Converter Module and can
have sub-
Modules that recording the relationships of new values as desired.
SUB-ORIGIN IDENTITY NUMBER FIELD, RECORD TYPES, DATA ASSEMBLY TABLES, DATA
CLASS TABLE AND SOFTWARE MODULES
21 ) The Data Relation Table field, Record Type and Data Class Tables for the
Sub-
Origin Data Class are used and function as described above for the Origin
Identification
Number, with the exception that that they concern the Sub-Origin. The Sub-
Origin can be
a junior Data Relation Table, or the previous origin of a communication - i.e.
where it
came from before coming to the sender.
THE 'DATA SPECIFICATION' FIELD
The purpose of the 'Data Specification' field is to ensure the completeness
and
correctness of all transmissions and the field itself can be used to contain a
checksum for its
record - or to point to a Data Specification Record.
Data Specification fields and record types are also useful to enable a user to
attach
data items - i.e. add one data item onto the end of another - or to include
data items - i.e.
make one item part of another, with a particular code digit being used to
state whether
something is an attachment or an inclusion.
DATA SPECIFICATION RECORD TYPES
Data Specification record types can contain checksums, lists of records
transmitted,
Condition/Director record pairs that state what to do if certain Conditions
appear - such as
partial transmission failure. They can also be used to state what constitutes
a complete or
incomplete communication that requires correction. The first objective of Data
Specification
records is to provide a list of what was transmitted and therefore enable the
receiving
Software Module to check and ensure that it has received everything it was
supposed to
receive, with no omissions - for example, in the middle of the communication.
DATA SPECIFICATION DATA ASSEMBLY TABLES, DATA CLASS TABLES, SOFTWARE MODULES
Data Assembly Tables and Data Class tables can be used as desired. Software
Modules associated with the Data Specification field are desirable to ensure
the integrity of
communications, and hence, such Software Modules function in pairs, one of the
pair being
concerned with transmission and the other with reception. Software Modules
associated with
this field also take care of user data attachments or inclusions.
614
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
THE ACKNOWLEDGE FIELD, RECORDS AND TABLES
A communication is not really complete without an Acknowledgement, as
otherwise it
is not certain if the communication arrived as intended or not. While the
Acknowledge field is
of major importance as an Administration field used by Software Modules that
are concerned
with transmission, it is equally desirable for user data, where the user can
require an
Acknowledgement from the addressee by a certain time, etc. Since Acknowledge
records
have all Data Relation Table fields available, alarms and deadlines etc can be
stated using
suitable Software Modules and the Time data category fields.
These methods concerning communications within an application and between an
i 0 application and distant computers enable communication to be an intrinsic
part of every
application constructed with the methods of the Any-to-Any machine.
22) Field 38 - AUTHENTICATE
THE AUTHENTICATE FIELD, RECORDS AND TABLES
The Authenticate field is the Administration field version of the main Data
Relation
table Confidentiality field. In the state of the art, software piracy is a
continuing problem,
which the methods of the Any-to-Any machine solve in the following manner.
When a software package - i.e. new Software Modules and potentially also data
records - are supplied by a Software provider who wishes to ensure that
unauthorized copying
does not occur, the follo~nring methods are used to prevent unauthorized
copying and use:
1. Each record supplies contains two additional fields at the end of the
Data Relation Table - an Authenticate Number field and a Authenticate Module
field.
2. An Authenticate Software Module is supplied together with the Software
Module
3. The Authenticate Module executes automatically as soon as it arrives
and contacts the supplier with the number of the Data Relation Table in which
it finds
itself.
4. The supplier's application uses the Data Relation Table number and the
time of contact to generate a unique number termed the Authentication Number.
5. The Authenticate field of each Software Module in the package is
supplied with an Authenticate Field Software Modules - Field Software Modules
are
Software Modules that Operate on one field only.
6. One of the Authenticate Modules copies the encrypted Authenticate
Number into an encrypted Authenticate Table.
7. One of the Authenticate Modules copies the Authenticate Number into
each Authenticate field of the supplied records and then calls the Install
Module to
615
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
copy records - that contain an Authenticate Number from the Working Table in
which
they are placed on arrival, into the Tables of the application.
8. When one of the Supplied Modules executes in the normal course of
work by the user, it executes normally, but while it is doing so, the
Authenticate
Module in its Authenticate Module field checks that the Authenticate Number of
the
Module itself and of the records being used, when partially decoded using the
Data
Relation Table number as a public key, matches the number in the Authenticate
Table.
9. If the Authenticate Field Module finds that the match is incorrect, the
programmer has a number of options, for example, sending a Token to the
Controller
Logic telling it to halt Execution, or calling a Module that deletes the
Software Module
concerned or just its Controller Field Logic, or switching off display and/or
other
output. An Authenticate Module can then launch other Modules, enabling the
user to
contact the supplier and obtain a valid Authenticate Number. The programmer
can
also use methods of the Any-to-Any machine to tailor an Authenticate Number so
that
functionality can be turned off selectively - for example, to turn off data
entry, but to
leave all display of existing data fully functional or using a Timing record
to give the
user X time to obtain an valid Authentication Number.
With these methods of the Any-to-Any machine, a software provider can be fully
protected from piracy, but at the same time, without bothering the user with
complex code
numbers; equally, Execution occurs unhindered, on the assumption that the
Software Module
will be authenticated, but provides for it to cease functioning if the
authenticating process,
occurring in parallel to normal Execution, results in the Module not being
Authenticated.
Method For Constructing Each Data Category '
A Data Category is divided into Data Classes, each of which is one of the
Classes -
highest-level groupings - of Data from that Data Category. Taking the word
'chair' as an
example of this, and asking the question 'what type of thing is a chair?"
gives the answer 'a
chair is a type of furniture.' Repeating the question; 'what type of thing is
furniture?' gives the
answer 'furniture is a type of man-man thing.' Again repeating the question
'What type of
thing is a man-made thing?' only yields the answer 'it is a material thing' -
which is the Data
Category of physical universe Matter. Hence in the Matter data Category, the
first division -
in fact the first two data Classes are 'Man-made things' 'Not man-made
things.'
When using a computer to accept commands, all commands concern man-made
things and hence, 'man-made thing' is synonymous with the data Category Matter
and does
not need to be separately expressed. However, if a full Language Processor is
in use, then
616
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
each Matter Data Category item does need to be coded for Man-made or non-man-
made, as
both can occur.
A Data Class can be sub-divided without limit and hence, a Data Sub-Sub-Sub-
Class
can also exist. For convenience a Data Sub-Class is referred to as a Data Sub-
1 Class, a
Sub-Sub-Class is referred to as a Data Sub-2 Class etc). The following table
gives an
example of dividing man-made physical universe things into type and sub-type
Data Class Sub-Class Sub-Sub-ClassSub-3 Class Sub-4 Class
Man-made
Thin
Furniture
Chair
Louis IV Chair
Transport
a thin
Vehicle
Car
Buick
Ford
I I ~ T Bus
As this example shows, some names of things - car for example - have more
senior
divisions that others - chair in this example, and therefore, it is convenient
to re-arrange the
classification as follows, so that they each name falls into a column of its
own type:
Data Class Sub-Class Sub-Sub-ClassSub-3 Class Sub-4 Class
Man-made
Thin
Furniture
Chair
Louis IV Chair
Trans ort
a thin
Vehicle
Car
Buick
Ford
Bus
Doing this shows that the columns can now be given working names:
Data Class Sub-Class Sub-Sub-ClassSub-3 Class Sub-4 Class
Brand or Special
Overall TypeType Sub-Type Name of thing
Name
Man-made
Thin
Furniture
Chair
Louis IV Chair
Transport
a thin4)
Vehicle
Car
Buick
Ford
Bus
617
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
METHODS TO ENABLE A COMPUTER TO RECORD INFINITE RELATIONS BETWEEN
DATA
The following describes the Any-to-Any machine methods by which Data
Components
and assemblies of Data Components can be related to one another using the
basic structure
of the Any-to-Any machine.
- Reciprocal references
AND and AND WAS 'H' and 'V' references are an example of what is called
Reciprocal References. Each record, in this instance, contains either a
reference, or a
pointer to a reference record that indicates the other. While this one method,
it may not
always be possible to ensure that every record is reciprocal. The chief
advantage of
reciprocal records, is that it makes it faster to move between the pair.
However, when
reciprocal references are not possible, then logic should find the other item
concerned using a
search. For example, supposing that one Data Relation Table field - number 1
for example
contains a reference to another Data Relation Table record, number 2, but
number 2 does not
contain a reference to number 1. If the user is in record 1, logic can move
him directly to
record 2. if the user starts in record 2, then there is no pointed to number
1. In this case,
there are two options;
Option 1 is to add a Reciprocal Reference Record or records that contain the
pointers
to the data record of the pair that does not have a reciprocal reference.
Option 2 is that logic that may be concerned for the presence of a reciprocal
reference, calls a search (as previously described) that find the reference.
Method to Create relate Data Relation Table Record Types for any Data Relation
table
Specification.
As stated previously, any data at all can be recorded in the Data Relation
Table, since
all data that can exist faNs into one or more of the five Data Categories. In
addition, as
described previously, any Data Category and any Data Class can have a Data
Relation Table
of its own type.
Additionally however, any Data Sub-Classes and Any combination of Data Class
or
Data Sub-Class values can have a Data Relation Table record of its own type.
if for example, in a particular Data Relation Table record, the following
value is
recorded:
Administration Field Record number 1444912
Data Category Life Data Class Language English
Data Category Matter Data Class Type of thing Test
Data Sub-Class Sub-Type Student
618
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Data Class Reference No 12994Y
The values in record number 1444912 state a Specification, which is: 'English
Language Student Test, number 12994Y'. Record number 1444912 can have record
numbers of its own type - they are a type 1444912 record, in other words, they
are records of
type 'English Language Student Test, Reference number 12994Y'.
When a specific Data Relation Table record is made into a record type, this
fact is
recorded using the Administration Field 'Record Type Number'. When a Data
Relation Table
record such as the above forms the basis for a type of record, the record
number is recorded
in the Record Type Number field, and the fact that it is a Base Record,
setting the
Specification for further records is record in the Base Record Administration
field. In the
illustrative implementation, different software manufacturers include their
own manufacturer
number (similar to a UPC code) as part of the Record Type Number for their
records, thereby
avoiding confusion with the software of another manufacturer using the same
number.
Referring to the above examples, records of the type 1444912 could, for
example,
provide records of test results - acting as a Condition Record - that are used
by the
accompanying Software Module, and these are compared to data the student
enters. The
Director Record that accompanies the Condition Record can cause other Software
Modules
to activate, the number of the Help record to change - thereby providing the
student with
further information - etc.
In this manner, any Specification whatsoever that is recorded in one or more
Data
Relation Table records can be the basis for a series of Data Relation Table
records of that
type.
The Administration Sub-Level Number and Number in that Sub-Level fields, allow
the
programmer to create a large number of sub-types of a given record type. Using
Unlimited
Numbers, the number of sub-types can be unlimited also. Effectively the
Unlimited Principle
is complied with, since the possible complexity of records will exceed the
ability of a person to
understand them, and hence, the human will limit himself before the numbering
system limits
him.
Method to Construct a Typical Find Module
A constant problem in many organizations is that incoming communications from
the
public, who do not know who does what in the organization, constantly arrive
in the wrong
place, delaying handle of the matter and also resulting in the person
responsible not having
all the data he needs and wants in order to his job. When a person states in
the form of a
Condition Record, the information he wants to see, all incoming communications
can be
checked by suitably constructed Routing Modules, that check the incoming
communications
619
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
against such Condition Records, and either automatically route the
communication to the
correct person, or send him a copy.
Method to Enable A Computer to Copy Records for different users.
Programmers create the first Field Designator Condition Records; when this
type of
record is created by a programmer, it is distinguished from any records
subsequently derived
from it, be designating it as a Base Record in the Base Record field that is
part of every Data
Relation Table record. Subsequently, when a user changes a particular field
selection by
changing any arrangement provided stated by the programmer in the Field
Designator
1 D Condition Record, the changed Field Designator Condition Record is saved
as a new record,
and related to that user using the User Number field in each Data Relation
Table record. The
original Field Designator Conditiori Record is left intact and is available as
simply another
Filed Designator Condition Record. If another user chooses to do something
that uses the
Field Designator Condition Record belonging to another user, that record is re-
recorded, but
with his own User Number in the User Number field. This description forms an
example of
the general method of the Any-to-Any machine for allowing a user to make any
changes he
wishes to anything created by the programmer. In effect, the programmer is
treated as just
another user. In the general method of the Any-to-Any machine, any user can
use something
created by another user - unless prevented from doing so by Confidentiality
Data Relation
Table records. If he changes that other thing, the changed version is recorded
under his
name. If he wishes to change an original, he needs the owner's permission and
methods
exist to obtain this. These methods consist of saving the changed copy as a
changed copy,
and requesting permission from the owner to make the change to the original
also. If the
permission is granted, the change is made, and if not granted, the person who
wished to
change the original is informed. When one user does change something belonging
to
another user, the copy is done in the form of copying references, field by
field, so that each
field refers to the corresponding field in the record that is being copied.
Hence, if the original
is changed, the copy is changed also, without any specific 'linking'
technology being required.
In effect, anything the user changes, simply over-writes the reference to the
original that was
in the Data Relation Table field concerned. An option is available to make a
fresh copy - so
that the copy does not change if the original changes, and in this case, it is
the values in the
records being copied that are placed in the new copy, with the new user
however, designated
as the owner. Since the owners are different, the two recordings are
different, and the
requirement to maintain one instance of one thing is maintained. When a search
records that
are identical in all respects except for their owners, then only one of the
identical records is
displayed or used.
620
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Method to Enable a Computer to Decide: Construction of a Decider Software
Module
uses as its input, the Data Relation Table that is the output from the Module
containing
the result of the manipulation performed by a Module whose manipulation result
can require
different steps to be taken depending on the manipulation result.
The Decider Module uses any number of Condition Records that between them,
state
all possible outcomes of the previously manipulation. Such a Condition
necessarily need to
state all possible combinations of outcome, because the Any-to-Any machine
method handled
each field on an individual basis. However, as a minimum, enough Condition
Records should
exist to state, for each field, all possible outcomes for that field, in such
a manner that no
more than one outcome per one field is stated in one Condition Record.
However, if it is
desirable to do so, a single Condition Record can contain combinations of
output field values,
and if so then it is referred to as a Condition Combination Record, and one
Condition
Combination Record is required for each combination of values that could
occur.
The Execution Record of the Decider Module tests the previous Module's output
(1 )
against the Condition Records concerned (2) to determine which Condition
record is matched.
If a Condition Combination records are used, then each such record also
contains in
its Director field, the Name of the Software Module that is to be called if
the Condition it states
is found to be true. The Decider Module Execution Record, finding a match for
such a
Condition Record, creates a new Data Relation Table Token Record and enters
into it the
'Next Software Module Name' it has found and the number of the output record
it tested and
passes this to the Execution Module that activates the named Module.
If Condition Field records are in use, where the outcome of a manipulation in
one field
does not affect the course of action that will be taken in another field, then
the 'Next Software
Module Name' of such a Condition record points to the Data Relation Table
record number of
a type of record called a 'Director Record.' When Director Records are used in
this manner,
one Director Record works as a pair with a Condition Field record. Each field
of a Director
Record contains the reference number for the name of Software Module that is
to be called if
the Condition stated in that field of that Condition Field record is found to
be true. In this
case, there is a one-for-one correspondence between the Condition stated in a
given field of
the Condition Field Record, and the name of a software Module that is to be
called if that
Condition in that field is found to be true. The logic in each field of the
Decider Module,
finding a Condition in its field of the Condition Field Record to be true,
looks up the reference
number of the Software Module contained in its field in the Director Record.
It passes this to
its Controller Logic, which creates a Data Relation Table Token Record and
enters into it the
621
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
'Next Software Module Name' it has found and the number of the output record
it tested and
passes this to the Execution Module that activates the named Module.
This outlines the method used by the Any-to-Any machine to handle branching.
Any
Condition Record can be used by the Decision Module, and tested against Any
output record
and used to cause Any subsequent Execution. While the method is perhaps more
laborious
than state of the art software construction, it results in order of magnitude:
Decrease in the volume of code required. Because of this, system requirements
are
less and overall Execution speed is increased.
Increase of code flexibility and ease of correction
Increase of code reliability arising from reduced complexity
~ Method to Enable a Computer to Use Organizational Structures
~ Method to Enable a Computer to Keep Organizational Planning
~ Method to Enable a Computer to Make and Keep Organizational Statistics
~ Method to Enable a Computer to Respond to Emergencies
~ Method to Enable a Computer to Control other Computers
~ Method to Enable a Computer to Tell Differences, Similarities and Identities
~ Method to Enable a Computer to Tell of a Statement is Complete
~ Method to Enable a Computer to Tel1 if A Statement Makes Sense
~ Method to Enable a Computer to Make Recommendations
Recommend DO Under some circumstances, the ability is required to use the
incoming data to select the Software Module to be used to manipulate itself,
and then
proceed further to select a suitable View. Most incoming orders include an
Execution, but
occasionally, the Execution can be very general. For example, a Boss may say
to a
Secretary 'I have received this customer complaint. What should I do with
it.?' The secretary
might answer ' Send it to Joe Brown in customer service.'
~ ADDITION -LANGUAGE PROCESSING
DEFINITIONS
Stage I Language Processing is defined as:
Processing a user's orders in a given human language directed to a computer
to be executed by the computer, that is composed in the same or similar manner
that
the person would transmit it verbally or in writing to another human, in such
a way that
the output can be used by suitably constructed software to control the
operation of a
computer on behalf of the user. In addition, taking any software responses
from the
result of an execution of a user order or concerning a human order and
transforming it
622
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
into the same or sufficiently similar output the output one person who had
manipulated
the same data would give it to another person.
Stage I Language Processing covers only the domain of user orders given to a
computer; Stage I Language Processing is also specified as covering a
particular
human language and an example of such a specification would be Stage I English
Language Processing.
Stage II Language Processing is defined as:
Processing all and any Normal Language text data received from a person in a
given Language, covering a given domain, that is composed in the same or
similar
manner that the person would transmit it verbally or in writing to another
human, in
such a way that the output can be manipulated by software to produce the same
or
similar result to the result that would have been produced by another human
manipulating that same data. In addition, taking output of data that has been
manipulated by software and transforming it into the same or sufficiently
similar output
the output one person who had manipulated the same data would give it to
another
person.
Hence, Stage II Language Processing is specified as covering a particular
human language and a particular domain of knowledge within that language. An
example of such a specification would be Stage II English Astronomy Language
Processing. Stage II Language Processing is defined in this manner because
each
subject in a given human language has its own particular conventions for
expressing
data, and its own particular vocabulary.
Both methods are capable of translating between languages if more than one
language is installed.
STAGE I LANGUAGE PROCESSING CAPABILITIES AND REQUIREMENTS
The domain of Stage I Language Processing concerns the processing of orders to
a
computer and responses from a computer only. Stage I Language Processing does
not
process Content at all, and if only a Stage I Language Processor is installed,
then Content is
stored as a block, either in the Data Relation Table field, or as a disk file,
as already
described.
Stage I Language Processing can be used without a Visual Interface, or
alternatively,
can be used instead of a Visual Interface of the type described herein.
Stage I Language Processing is particular useful in the control of small
devices such
as palm-size computers, telephones, VCRs, household machines, where the small
size of the
device or the physical conditions in which the device operates - for example,
an embedded
application in a car - makes the use of a Visual Interface either impractical
or only enables a
623
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
relatively small visual interface to be used. Under these conditions, Stage I
Language
processing is particularly useful if reliable voice recognition software and
text to speech
software is also installed.
In a small device such as a VCR, an extremely reduced Data Relation Table is
used,
containing only the Data Classes and fields that are relevant to the
application in question;
some of the Data Relation Table fields for such an application might be:
Administration Fields: Record Number
Type
Sub-Type
Sub-Sub-Type.
Administrative Name
LIFE Data Category Nickname (User)
Group Name (Station Name)
TIME Data Category Start Time
End Time
SPACE Location (Storage location of the cassette)
ENERGY Data Category User Action
Software Module Name
MATTER Data Category Item Name
Item Type
Storage Medium Name (e.g. number of the cassette)
A small Data Relation Table of this type can be provided with any of the
mechanisms
in the Any-to-Any machine. Because such a Data Relation Table, and other
Tables and the
mechanisms in such an application are only a smaller, but parallel version of
the Data
Relation Table, Tables and mechanisms in a more full size version such as that
described
herein, in order for the larger version to 'talk' to the smaller version, the
requirements are:
1. As connection between the two
2. A Convert Software Module in the larger version that prepares records
for the smaller version
3. When preparing these records, Convert leaves out the unused fields in
the smaller version.
4. When a device using a smaller version is first connected to the larger
version, it transmits the a) the numbers of the fields it uses b) a Label
record for the
default Label 'names' for each field. C) Its name in Spoken Concept Language.
5. Convert, on receiving this information:
624
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
a. Copies an existing Talk Module plus its View, re-naming it with
the name of the device
b. Removes the unused fields from the re-named Talk Module
6. Convert launches a further Module that finds out how to connect to the
device.
While a large application can easily communicate to and control a smaller one,
a
smaller one, while it can communicate to a larger application, has greater
difficulty controlling
a larger one, as its Data Relation Table and contents of its Data Class Tables
will be
considerably smaller. Some methods that can be used to assist with this are as
follows:
1. As previously described, Sub-Type and Sub-Sub-Types of a given Data
Class can appear each in its own field in the Data Relation Table or all of
these
together in a Sub-Type and Sub-Sub-Type field for that Data Class. A smaller
device
can use the latter method, while the larger application, receiving such a
record, uses a
Convert Module to transform those records into the type of record it uses.
2. Within the limits of its vocabulary storage possibilities, the smaller
device, provided with suitable Software Modules, can cut each of the larger
application's Data Relation Table records into several smaller records that
together
make up one full record in the larger application. In this case each of the
different
records making up a single record in the larger application are a Sub-Type of
that
larger record where execution occurs normally. This is called the Direct
Remote
Control Method, where the smaller device constructs a valid order and then
transmits
it to the larger application.
3. Since it is typically easier to provide more services in the larger device
however, the method that is usually easier and is therefore desirable to use
Indirect
Remote Control use the smaller device simply as a data recorder that records
the
order from the user and then transmits the recorded order to the larger
application. In
this case, the smaller device only needs to add one more records type to its
Data
Relation Table that it normally needs for itself, namely a Remote Order
record..
4. A Remote order record contains in most of its records, the details of
surrounding the order itself, while the Content field of such a record
contains the
actual order in the form a text file that is the entirety of the order.
5. When the bigger application receives the Indirect Remote Control
record, the Indirect remote Module takes the contents of the Content field,
and feeds it
to the normal input mechanisms installed in the larger application.
6. Messages going back to the smaller device are handled in the same
manner, with an Indirect remote record which, in this case, contains the part
of the
625
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
response that cannot be displayed or used by the smaller device, in the
Content field.
The smaller device, receiving such a record, plays back the data in the
Content field to
the user.
However, by far the simplest method of controlling a larger device with a
smaller one
is if the smaller device is a telephone and in this case, if voice recognition
is installed in the
larger application, then the received communication is put into text by voice
recognition
software and the result is turned into the form of a command by the Stage I
Language
Processor.
1 O STAGE I LANGUAGE PROCESSING CAPABILITIES AND REQUIREMENTS
When a Visual Interface only is in use Stage I Language Processing is done
with the
following methods:
Orders given by the user may be entered into suitable Views, and I this
case, the Active Elements of the View enter the values received into the Data
Relation
Table in the fields - and hence into the Data Glasses - to which they apply.
2. When the user wishes to Find an item, and a Find Screen is used, any
value entered into the Active Element is checked with the values recorded in
that Data
Class, and, if the value does not exist in the Data Class, then there can be
no item
created With the application that contains that value. The user can be alerted
to this,
and can then, if he wishes, immediately revise the value.
When a Visual Interface is in use with a Stage I Language processor, then, the
following methods, in addition to those given above are also used:
1. Ideally, each Data Class is pre-loaded with the words, except Operator
words, that apply to that Data Class. However, even if Data Classes are not
pre-
loaded, a data Class table for Operator Words may be created and this table is
preloaded with all Operator Words in normal use.
2. W hen an order is received by entry into Order Box - a data entry area
for orders - the Fax Module concerned is first identified, using the methods
previously
described. If it cannot be identified, then a user message states something to
the
effect of 'I do not recognize what I am supposed to do, could it be one of
these? If it
isn't then it is something I don't know how to do yet.' - the Software Module
uses a
Sub-View to supply a list of Software Module Names. If what the user wanted
turns
out to be one of those, execution proceeds and the user's name for that action
is
entered into the Software Module Data Class User Equivalency Table. If the
Module
the user wanted does not exist, and if the If Not Found methods are in use,
the
626
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
Software Module provides a message such as 'Just a moment, I will try and find
out
how to do that' and the If not Found mechanisms are followed. -
3. Thereafter, the remaining words in the order are checked and those in
the Operator table are ignored. The remainder of the words are checked one by
one
against the Data Class Contents Table. The Data Class Contents Table is a
single
table containing a full list of all the entries that would normally be found
in each Data
Class table. In effect, with this method, instead of each Data Class being
kept in a
separate table, all Data Class Contents are kept in a single Data Class
Contents
Table, in which each record contains what would be the contents of one normal
Data
Class Table record. In the Data Ciass Contents Table - which includes the
contents
of the Operator Word Data Class Table - an additional field is used to state
the
number of the Data Class Table to which that record belongs - which is the
same as
the number of the Data Relation Table field that Data Class Table services.
4. If a word is not found, then a Designate Software Module uses its Sub-
View to find out from the user - by displaying all Data Class Labels that are
in use in
the Data Relation Table - which Data Class the word applies to. W hen this is
found
out from the user, the value is entered into that Data Class - i.e. by
entering it into the
Data Class Contents Table - and then used. Every unknown word should be
identified in this manner, but only need so identified once.
5. When the user wants to Find an item, once the Execution is identified
as per the methods previously described, the Data Class to which the remaining
wards
belong are identified by looking them' up in the Data Class contents table,
and then
placed in the New Record being created in the appropriate field. Again, if a
word
entered into the Find Specification by the user is not found iri the Data
Class Contents
Table, it is already known that such an item does not exist and the user can
be
advices, at the same time that the opportunity is taken to record the new
word.
However, when such a new word is learned, in the course of a Find, it is a
word that
does not exist in an item, and therefore the Data Class Contents Table
contains a field
to mark items where the words have been learned, but the word does not exist
in an
item.
6. In this method however, the Content field again provides an exception;
in this method, where Content is being recorded as a block, a word contained
in the
Content that has not been recorded in the Data Class Tables or Data Class
Contents
Table, is not an unidentified word as far as a user is concerned, and
therefore does
not need to activate the Designate Module.
627
CA 02360067 2001-07-11
WO 01/35216 PCT/US00/31231
7, On the other hand, when the user is referring to Content - which will
occur from time to time during a Find and can also occur when the user is
giving an
order in which he wants content to be transmitted or recorded - methods are
needed
to identify Content. The general methods used to do this are similar to the
methods
already described for identifying an Action and distinguishing it from a
Thing. Specific
phrasings designate when Content follows:
Saying
Talking about
Containing
About - except when a word in the Time data Category follows
Referring to
Similar to the method previously described for detecting Actions, an effective
method
is to obtain a large number of phrasings from users containing references to
Content and
then to review these for wordings and combinations for workings and
combinations of
wordings that indicate that Content follows, avoiding those that are used to
indicate
something other than Content follows. When doing this the primary rule is born
in mind -
namely, that if a human can detect that content follows, then a rule, or rules
exist that can be
isolated and used.
Although embodiments of the present invention have been described herein, the
above description is merely illustrative. Those skilled in the art will
recognize that the method
and apparatus of the illustrative embodiment of the present invention has many
applications.
Further modification of the illustrative embodiment of the present invention
herein disclosed
will occur to those skilled in the respective arts and all such modifications
are deemed to be
within the scope of the illustrative embodiment of the present invention as
defined by the
appended claims.
628
