EP1247174A2

EP1247174A2 - Any-to-any component computing system

Info

Publication number: EP1247174A2
Application number: EP00978614A
Authority: EP
Inventors: Peter Warren; Steven Lowe
Original assignee: E-Brain Solutions LLC
Current assignee: E-Brain Solutions LLC
Priority date: 1999-11-12
Filing date: 2000-11-13
Publication date: 2002-10-09
Also published as: WO2001035216A3; WO2001035217A2; RU2001122576A; EP1259880A2; CA2360067A1; IL144319A0; CA2359997A1; AU1606201A; ZA200106526B; NZ512939A; JP2003529818A; WO2001035216A2; AU1611301A; WO2001035217A3; RU2001122574A; IL144314A0; JP2003514300A

Abstract

A universal data and software structure and method for an Any-to-Any computing machine in which any number of any components can be related to any number of any other components in a manner that is not intrinsically hierarchical and is intrinsically unlimited. The structure and method includes a Concept Hierarchy; each concept or assembly of concepts is uniquely identified and assigned a number in a Numbers Concept Language or uniquely identified in a Non-numbers Concept Language. Each Component or assembly of Components is intrinsically related to all other data items that contain common or related components.

Description

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.

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. 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. 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 cannot change. The situation throughout the prior art is analogous to a factory in which a 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 import export 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 learning to use a new 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 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 computing 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 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 or 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. 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) concept(s) or meaning(s) 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 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) 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 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 and/or 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, all 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- 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 condition/s 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 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 transformation 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 all 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 email 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 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 lends 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 multiple 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 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 overwriting (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 I 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 he ate for lunch the previous day, he will 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. 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 field/s used to record actual words and phrases in a particular language. Nevertheless, a simpler and more limited but still 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, 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 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 defines 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 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. 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 effectively 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 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 lists, 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 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 - allows 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 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 logics 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 data/software 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 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 far 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 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 one or more junior- senior relationships. In 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 10 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 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 natural 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 software 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 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 it, 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 least 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 stored 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 may 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 module/s concerned are so constructed that the Field Logic in a given field is able to handle and in nearly all 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 and/or 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. 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 well 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 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 requirements for all the meanings. Once an unambiguous meaning has been selected for 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 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: life, 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 example, 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 data records from any two or more different Data Relation Tables are effectively interchangeable because a Data Class 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 been 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 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.

In 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 ' ax" 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 fax(es) 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 single 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 multi-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 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 - in 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 described in this example, the number of associated field parallel records is not limited, and while 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 1A 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 record/s 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 interface. 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 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 fixed number 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).

FIG. 9 is a logic flow diagram 100 illustrating a process for responding to natural language commands in the Any-to-Any computing machine 10. 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. 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 14 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 record/s 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. (In 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. 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. 10 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 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 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 language 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 118 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 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 Ε-MaiP 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 14 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 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 all 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/logical 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 pointer 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 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 IV 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 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 symbols 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 fundamental/atomic 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 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 View, 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 well as other administrative fields, as desired. Since a Reference 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 value(s) 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 Table, but such a table need not contain only values of one concept. In practice, the tendency is to store Data Class Values with 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 forward 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. 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 (me@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 FIG. 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. Email. Email__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 "me@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 "me@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 another, 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 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. 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 listed, 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 all. 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 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 for 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 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 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 . 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 word '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. 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 decompressing 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 everything 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: 'Oh!' 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. 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 realized 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.' Now asking the same question of the word 'train': 'Is train a way of doing something?' could yield the answer ^lyes, 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. 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 all 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. 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. 7) Devising Questions to Detect Lossy Compression and help 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 & 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 4 - 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's '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' (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.

If 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 letter. 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 & completed' and finds 'printed'

Computer to person 'printed the letter.' 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, 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 'Invif. 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 'invif as an action, are both actions, that are requests to someone to change the space they are in, with 'invif being more formal than '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 exisf, 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. 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 'Invif 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, I like this.' or 'Stop. I like this.' But when spoken, there is no comma or period - the words 'stop I 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 decompression 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) decompress 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 addressed is a lossy compression confined in the word "stop' when used as a first word) Rule 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, then (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 e 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 Decompression 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. 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: . 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. Modules to perform specific actions such as the 'Stopcheck' example, can not require opening a multi-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 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-f 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 long 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'. 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 and 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. '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 commands 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 not 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' 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 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) In 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. If 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 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. 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 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 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 learning 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 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 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 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 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 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 T 'I will 'will' satisfies T 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'

I 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. 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. 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'. 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?' The user will reply 'yes'

Further routines that are the province of associated software can revise the definitions of 'telephone' and 'roam'. It 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. 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 REIation 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 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 object of 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 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 aiso 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 REIation 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. 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 REIation 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 letter 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 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 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 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 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 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 Ε-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 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 alone, 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 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. 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. Secretary to Boss: Oh that one. OK, I'll get it.

The first Data Specification "get me the letter', used the word 'letter' - 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 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 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); , 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) I wrote (Action) I edited (Action) I printed (Action) I sent (Action).' • Concept Language Requirements. B. Enabling Human Unique Data

Specification in a Computer. - The Co-Reducing Concept Method. 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 REIation 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 letter 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' 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:

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'

The two concepts 'my' and 'New York' co-reduce one another. ord with the meaning 'all about

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 '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 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. 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 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:

'Roam(m)' = telephone & connected & 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 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 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 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 '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 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). This gives a final list of the categories of Meaning Words that can be recorded in a computer: 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 common 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 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: Response from Time Response from Response from from Matter Category Location Category Action Category category

Park Avenue I printed Letter

Christmas printed Letter

'Christmas I Park Avenue Letter

Christmas I Park Avenue I printed

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: 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 Class, 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 word '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. 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 .greatly 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

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 list that is impossibly long and therefore useless, as well as taking an inordinate time to execute. 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 onl 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 specificJtems 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 be translated into a Concept Language includes the General Use Words 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 one 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. 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 account of different phrasings used to say the same thing, nor will 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. 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 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 & 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 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 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. 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 & bus do & move & travel & car 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 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 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. 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 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 Stepl above. Three of the answers might be:

It can print things, store things, fax things. It can make text bold 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 list 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 & printOO And the Concept Hierarchy for fax (the action of faxing something) would be: Do & output & communicate & fax 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

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 even/ 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. 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 meaning.

• 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: 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. 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). 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 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 live. 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 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 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 from 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. 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' 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 & 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 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.'

In 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. 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 REIation 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. 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 Operator Rules are the rules concerning Operation Words. They first of all detect which 'meaning' of the Operator Word 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 REIation 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. 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 prerecorded, 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 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 long. 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. 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% 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. 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 = 444 199

Fly = 444 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 199 3416 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 all 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 & Screen Do & Appearance & Italics 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 REIation 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 manner 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 needing to be queried twice. It 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: '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 11891944419934162 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? 112313 4? (Joe do?) 4441993416 (flew)

Where? 118919 4441993416 3? 398989 (New York) When? 4419934162? 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 Format 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 multiword 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. 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 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 REIation 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 REIation 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 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: 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 • 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 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 is termed Space/Matter 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 rule.

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. 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 & New York City & Broadway & 1^st St *

4^th Floor & Suite 298 & Room 4.

Location Hierarchies enable a computer to emulate human query procedure: ^•Where 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 & 1^st St * 4^th Floor & Suite 298' and does not say 'at Broadway & First, 5^th 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....' 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 - Interrelationships 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, '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: '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 now. 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 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, 1 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 I 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 'l say so & 5 minutes.' 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 I 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 Locatio 'When 24^th 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. 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: 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 REIation 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 I 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) 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 REIation 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 REIation 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, uninvitable, 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 1 ) Placing the above forms into any sentence or phrase

1. 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 Jill

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: - A response of with some value - other than 'Not found' or 'don't know' - will 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 wholly and only a unique symbol for 'that part of the meaning of a word (which takes multiple forms) that is common to all 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 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

5 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-to-Any machine, because, and only because, it makes sense to a human. 0 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 I 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

-| 5 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

20 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,

25 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.

30 (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

35 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 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 does 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 between words: 'he.. said..i.. will..go.. to..the..house.. tomorrow' they are still 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 most unlikely places and the sense is still retained: 'I..amΛangry..jill.Λis.. difficult.. iΛshalLfireΛher'.

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 follows.

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 Jill 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 Blue 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: 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 'jill is' omits the data of what 'Jill' 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. 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, 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 "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 3020 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: 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 will 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 words 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'

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 Record/s do not satisfy the Condition Record/s - and hence the statement is an Incomplete Statement, it does not 'make sense' - the reason it does not satisfy the Condition Record/s 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 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 REIation Table implementation, all 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 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. Word 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:

1 ) 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. Because of these requirements, it is desirable that the basic construction of a Concept Language takes account and is compatible with all 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. 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 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 4^th Floor

2911 18 Broadway, The Bronx

New York City 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^th 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^th 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 that, when used together, are labeled 'an address' are correctly assigned to 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:

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 Joey - with a 'y' - can not be related to the documents sent by Joe No Time is recorded for the new Location, so which location is old and which is new can not be found. In effect all locations are Time Now'. Often the only way to 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 'old' 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 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 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) location/s can be related to - connected with Any (or Many name/s. All that is requires is a mechanism to show which Name/s apply to which Location/s 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 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 entirely 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 prerequisite 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 REIation 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 & USA & New York State & New York City & The Bronx & Suite 298 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^th 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 & 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 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 locate 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 one 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.

If 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 for 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 termed a way-point 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 & 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. 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 rename 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: 4^th 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^st avenue and 6^th 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 It 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. 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 fact 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 - 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 letter'. 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 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 'I like the New York building mentality. Build 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 good.' '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) Time 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 - 1 come here just as often as I go to New York 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.. 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 Joe Matter Invitation put the invitation in the post

60) Numbers. Number 20, 20^h

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 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 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 will 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 8 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: 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.' o®. 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.' 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 & 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 REIation 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 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 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 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 theO 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 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 to 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. 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: 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 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: 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.' 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 least 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. 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 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, all 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: 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 machine, in order to construct an Any-to-Any machine, any kind of data in the computer - 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' signature/s

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 title/s

8. One or more Sender's qualification/s

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 Number/s

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 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) 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 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 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 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 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 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. If 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, When 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 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. 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 state 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 use 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 file format in one or many other locations, and 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: 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. 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:

(An²) x ( Bn^2>) x ( Cn²⁾) 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 who 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 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 me 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 '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 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 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" Now supposing that the user's name - 'me' in the above, was actually Bob, the Specification in this order can be analyzed as follows:

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 '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 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 symbols 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 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 / cat / bacteria died because it was sad." But people do not tend to say "the car / flower pot / swimming pool / 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 not 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 do not exist at all if life 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 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 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 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 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 far as 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. 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 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 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:

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 available value. The same method 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 - 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, Town/City.

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 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 platform/s 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). 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 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. 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 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 Record/s 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. 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 all written so that they are independent units:

1. Whose code is complete in itself, and contains al! 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 RunTime 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. 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:

1. 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. 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 reboot. 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 same 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:

1. 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 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 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 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 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 ASCII 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 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. Normally, 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 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. 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 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). 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.

s 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:

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'.

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 clients'

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 reductio st 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: 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:

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:

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. (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:

1. 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 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 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, al! 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 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 II 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 later, 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 Table, 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. 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. 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: 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 I 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 tools 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 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 letter 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. 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 Logic'.

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 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 normal 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 long 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 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, no 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 role of the interface mechanism, but in general, both the availability and the 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. 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. 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.

Finally, 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 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 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. Only 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 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 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 Module 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 will be required to perform a single manipulation, and/or 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, 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:

1. 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 Field 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 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 original 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 Record/s 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 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 he 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) 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 wrong 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 parameter/s 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 post-Execution Conditions. For example, a secretary will 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. In 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 Table data record/s that contain the order that it is Executing. Typical examples of entries in the 'Status' field could be 'Scheduled', 'In 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 Logics 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 etc. 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 'V, '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. Only 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 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 Record s 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:

1. 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 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, no 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. - 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 difficult Executions. Referring to the boss / 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.' 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 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 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. 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 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 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 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 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 reference number for the field is provided by the Data Class 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 12^th 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 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 field can contain are sufficient to allowed to 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): 'If 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. 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 all, 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 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 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 act in 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 call 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 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. 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 real life 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 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 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

Module 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. 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. 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 file, 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 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 file 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. 7. The Translate file 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:

1. The Language Processor Interface creates - using the New Record Module - a new record where it records the users order, in Data Relation Table 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 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. 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 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. 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 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 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. - 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 little 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 input/output 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 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. In 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. 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 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 Table 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 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 of the 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. 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 Yes/No, or to... etc - and Many different values (but only 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-to-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 al! 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 and/or 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 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 table/record/field 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 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 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:

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 art database field name from the field, and 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 and 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- 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 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 record/s. Alternately, the reference displayed by an 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 Interchangeability 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 large 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. 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 involved 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 stored separately in order to preserve 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 1 8 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 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?' 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:

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). It 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, 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 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. 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 Help 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 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. 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 field, 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, 'Relation' 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:

1. 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) 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 completely 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 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, when 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 even/thing 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 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 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 if:

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 may 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 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 Interchangeability 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 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 using 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 part/s of any item/s. 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 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 implemented 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). 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 spreadsheetlike 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. 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. n 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?' 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 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 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 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 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:

1. 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. - 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 '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 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 Υou 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 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. 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 location/s 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 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 lists 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 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 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 part of one object cannot occupy the same space as the any material part of another object. Thus the physical Empire State 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 dynamically 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. 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. 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 nonelectronic 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 correlations 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 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 altemative 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- 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. 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. 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 Help, 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 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. 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. 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 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: 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 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 Table field. Logics are assembled with one another, by assembling their references. While this slows 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 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. I.e. 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 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 'over-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 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 %+7/Λ\\\433##' is not very likely ever to be a useful Component

Assembly. Under normal circumstances, adding '%+7/Λ\\\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 By extension, Software Component Assemblies - i.e. assemblies of Logics, or Component Assemblies that 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. 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:

'The 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 function(s) 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: 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 does 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. 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. 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 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. 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 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 '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.

In 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 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 all 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. 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 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 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 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 multi-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. 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. In 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 them will described when describing Data Class Tables . Additionally, software Components - Logics - once written 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 l,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 'letter'. 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 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 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 'faxf, 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 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 Words 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+'. In 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 = 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 meaning 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' 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. While 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:

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. The number of different meanings attached to given word symbol 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. 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 happies 123 Wednesdays 1 3 spaces

123 jumps 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 will 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: 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, 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).

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 In 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 Class 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 fields of the entire Data Relation Table. In this case, it can be worthwhile to make one of two provisions:

1. Write 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 translated 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 Table field where that value is used. If all instances of a given value or a given type of value in an Associated 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. 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 Class 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 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. 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. 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 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 will 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 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 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 light 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 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 / 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 iike 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: 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: 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 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. 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. When referring to 'Content', the framework that has so far been described - giving orders to a computer - no longer 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 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 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. 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 list 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). Send a fax I 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 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 meaning(s) 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 word/s 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 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'. 1 . 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 'Resolve'. 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. 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 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 line (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. 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. 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 will 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: I 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: 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 Table field for which a value is required. While every Data Relation Table field is available in each Condition 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. 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 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 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 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 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 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 Table 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 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 all 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 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 'ff 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 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 if, 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 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:

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: 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 eariier 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 last 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

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 Table 3 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 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 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 I 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 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 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 them 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 Record/s 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 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 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 Time 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. 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 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 Relajion Table that 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 - '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. 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 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 Tm 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 Tm 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, 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 for 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 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 time/s and day/s, 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 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, or 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 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. In 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 record/s stating 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, 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 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. 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 all 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. 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: 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 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 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 Relation 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 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 last 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 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 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 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 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 load 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 Logics 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 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 full 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 the record may well have a meaning in the field the data Class in which they are 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 down 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 Sequence 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 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, 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 all. 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 ability 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: 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) Identically 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. 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, 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 input/output 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 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. - 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, legs 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 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. 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. - 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) File 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 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 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 / 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 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. Input 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 and/or by manually changing between 'views'. Such a solution is not satisfactory because 1) 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^' 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. • 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. 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. 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 & 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 Input/Output 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. 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, and, 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 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.' 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 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 / 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:

1. 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). As an example of this, suppose that one human says to another:

'Get. This e-mail is a problem - 1 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. 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^NM. It becomes effectively difficult, in practical terms, to trace or state relationships and considerable confusion results. If these N 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 χ^NM . 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 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 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 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. In 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 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 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 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 - input/output 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, in/put 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 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 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, or 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 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) 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 not permitted for commercial or 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:

1. 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 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 View/s 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 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 reactivated 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. - 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 Single 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 'letters 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. While 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 manher, 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 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 1. 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 preloaded 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 least 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 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 relationships 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. MENUS

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 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:

1. 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 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. 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 all 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 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, subtype 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 Interface 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 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:

1. 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 - in 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 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 may 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 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:

1. 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 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 advance, 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 0,000,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. 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 Start 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 are used to lay out in sequence all the Coordinate Sets for a specific Interface Element. In this case, the Grid Start 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 Start 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.). 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. 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.

1. 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 Element 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 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, in the manner to be described, how 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 Element 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 in a Visual Interface or by a Language 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 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 the user, a Sub- View will be required to display the appropriate Device Record with its Associated Label record/s.

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:

1. 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. - 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 place. 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 'readable manner', and this is achieved using the Minimum Standard Size Method as follows:

1. 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 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 input/output device name as stated by that user 4) the 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 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 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 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. 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) 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' will 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 describing things. It has similarities to both groups, because one of 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):

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. 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. 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 and/or 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:

1. 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. Interface 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. 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 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^nd (3^rd, 4^th) 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 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 ofthe unabbreviated data in the Spoken Concept Language and 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 Class. 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 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 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 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:

1. 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, like 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 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. 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 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 Numbers Concept Language. All Enhancements can be placed in one Data Class 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. CONDITIONAL 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 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 Control, 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 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 Condition 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 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 is 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 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 - or 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 Note Itself. Effective Footnotes and Endnotes are easier to manage when the Content is prepared with a Full 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, all Associated Record values in that field should be replaced also. 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 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 even/thing 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. 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 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 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 Intervention 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.

1. 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). 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. 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 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 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 record/s) 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 Record/s. Hence, the User Master View for a screen, has available the following data:

1. 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 Element/s 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 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. In this manner the previous arrangement/s 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 Element/s, 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 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 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 Within X % 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, 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.

In 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. 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 1^st, 2^nd, 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. STARTUP SCREEN SELECTION

When an application is started, the Field Logic of the User field of the Controller Interface Module calls the User l/D Software Module using a Token. The User l/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 l/D Module is identifying the user, the First Use Module identifies all the 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 l/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 l/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 l/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 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 l/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 l/D Module sends Token with the User Number of the Authorized User on to the Controller Interface Module 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 l/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 l/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. 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 Module/s are used and called by the User l/D Module to perform the User Identification using the hardware concerned. Thus the User l/D Module calls the Transparent User Recognition Module/s if installed and if not calls its own Sub-View; equally, if Transparent User Recognition fails, the User l/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 l/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 l/D Software Module and Transparent User Identification Modules:

1. 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 blank the screen also. 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 l/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. 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 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:

1. 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 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. 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: 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 input/output 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 all 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 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:

1. 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 on 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 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- 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 renaming 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. In 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 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 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 been changed - 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 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 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 disk.

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 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 marked '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 point 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. 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. Content 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 file..

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. 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. 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 rerecorded 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. 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. 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. In 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 old 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 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. 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, Template 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 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 item 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. It 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 'all' plus the value he wants. The effect of entering 'all' 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: 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 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'. Al! 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, all 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 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 will 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:

1. 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. Item Find Modules Each Item type can have its own Find Specification record/s. 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 preloaded, 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:

1. 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. 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. 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 and/or 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 spreadsheef is created with the Any-to-Any machine methods, as for all other items, a Spreadsheet Module is used to create 'a spreadsheef. 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 spreadsheef 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 ot 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 spreadsheef. 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, 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 spreadsheef 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 spreadsheef 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 spreadsheef 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 Product; 1 250^';0.0Q

Prfducf 2 125,001)

PV ducI 3 30^*Q Qqi

P 'duet 4 2 θ,UQQ

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:

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 spreadsheef, 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. Three main ways exist of creating 'a spreadsheef in the Any-to-Any machine:

1. In Data Relation Table records in the normal manner

2. In a separate Data Relation 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 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 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 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 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. 4. A Number Data Class field 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 spreadsheef 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 in 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 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 input/output 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 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 problems 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 spreadsheef 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 / 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 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 / 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, 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 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 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 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. 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 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. b. If the fields concerned are not already a group, then the

Reference Creation Module should first group them according to the Any-to- 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 spreadsheef - 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 spreadsheef 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 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 value/s 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. 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 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: - In the Administration fields of the records making up an item, particularly using the Base Record, Sub Level Number, Sub-Sub-Level, Sequence 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 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-Leve! Administration fields. 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 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 for 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. 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 page/s 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 entirely 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. • 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 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. 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. 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. 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 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 l/D' 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. The Data Relation Table Identity Data Class is normally 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. 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. f. 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 Modules 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 Table 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 while a Write Check Software 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 record/s in the standard manner to determine the Condition that exists, and the Companion Director Record/s 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 Module. 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 Module 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 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 Token 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. 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 Modules 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. 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, while 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 l/D' when displaying it to a programmer.

SUB-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 Table/s 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 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. 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. 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. 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 Seniorities. 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 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 record/s stating the date of the most recent record removed. 11. It activates a Converter Module that, when user data is not found, converts the Find Specification record/s - 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. 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 CUSS 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 field needs to be unique. Normally, 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 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 record/s 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 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 FIELD, 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 CLASS 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

SUB-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-Leve! 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 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. 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 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:

1. 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 Spreadsheef - 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 spreadsheef to be any size vertically, and removes the distinction made in the state of the art between 'a table' and 'a spreadsheef 'a tabular database display'. With AND V field all 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 letters - 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. AND V DATA ASSEMBLY AND DATA CLASS TABLES AND SOFTWARE MODULES

The requirements for a Numbers Data Class apply.

10) Field 10 - 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 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 WAS 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 Spreadsheef 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 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 spreadsheef 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 for 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 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 SEQUENCE 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 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 can 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 and or records, a suitable View or Sub- View use Sequence 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. 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.

SEQUENCE 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 genera! 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. MARKING DATA ASSEMBLY AND DATA CUSS 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 one 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 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 1 1 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. 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 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 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 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 aspect of what it termed a 'callouf 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 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 relation/s 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 centra! 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 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. When 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. If 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 than zero are those Software Modules and data 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 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, 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 for 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. 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 will 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' 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 Element/s 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. 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 and/or 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 CUSS 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 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, 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 Time 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 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 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 Module/s, Sub-View/s and Single Active

Element button/s 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: 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 number 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 Table 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 Field 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 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 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. Startup

When the User l/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. 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 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 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:

1. 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 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), subtype 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. 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 list - 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 Table. 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 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 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 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. 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 number/s of the newly arrived record/s 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 record/s 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 / Off

5. Image Set 6. Image Number

7. Sound On/Off

8. Sound Set

9. Sound Number

10. Screen On/Off 11. Screen Set Number

12. Screen Number 13. Label On / Off

14. Label Level

15. Label Style

16. Label Number 17. Prompt On/Off

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. 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 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 files contain recordings of spoken text 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 Sound 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 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:

1. 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 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 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 / 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. 5. Style. This field contains the number of the style in which the particular Label / Prompt / Help entry is written - styles can be friendly, subservient etc.

6. Label / Prompt / 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. 9. Data Type This field contains a written description of the field name and value to which this Label / Prompt / 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 al! 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. Once the user has chosen a particular Label / Prompt / Help style and level, the number of the chosen Style and the number of the chosen Level is entered into the Label / Prompt / Help field/s 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, and/or hear, hear particular Label / 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 / 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: 1. 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. 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: 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 all 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 CUSS 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 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. 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 Item Administration is taken care of by the Original item Field Logic in the appropriate Software Modules. 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 field 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 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.^' 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. Destination Records accompanying a transmission of Data Relation Table records can be used to control the routing 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

1. 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 if 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 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 CUSS 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, 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. 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 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 following 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 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 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

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:

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 falls 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 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 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 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 Condition 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. 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 '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 Tell 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 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 ll 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 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: 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 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.

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:

1. 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 Classes - 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. When 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 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 Class 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. When 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 words 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 in 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. 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 bom 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.

Claims

CLAIMSThe Invention claimed is:

1. A computer storage medium storing computer executable instructions defining a method for storing data having an original meaning, comprising the steps of: disassembling the data into data components the further disassembly of which would cause the loss of substantially all of the original meaning; and storing each data component independently.

2. The computer storage medium of claim 1 , further comprising the steps of: storing software having a required function by creating the software as a plurality of software components, the further disassembly of which would cause the loss of substantially all of the required function; and storing each software component independently.

3. The computer storage medium of claim 2, further comprising the steps of: classifying the data components into data component types; and storing one or more software components or assemblies of software components that is configured to perform an operation on an associated data component type.

4. The computer storage medium of claim 3, further comprising the steps of: classifying assemblies of the data components into data component assembly types; and storing one or more software components or assemblies of software components that is configured to perform an operation on an associated data component assembly type.

5. The computer storage medium of claim 4, further comprising the steps of: defining a data classification interface comprising a plurality of semantic data classes for categorizing data items; defining a plurality of records comprising fields configured for containing numerical indicators corresponding to the data items; the numerical indicators being defined within a numbers concept language dictionary in which each numerical indicator is uniquely associated with a base data item; correlating 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; and storing the data components as records expressed in the data structure.

6. The computer storage medium of claim 5, further comprising the step of storing the software components as records expressed in the data relation structure.

7. The computer storage medium of claim 6, wherein 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.

8. The computer storage medium of claim 7, further comprising the steps of : receiving a natural language block; converting the natural language block into one or more corresponding records expressed in the data relation structure; and storing the corresponding records in the data relation structure.

9. The computer storage medium of claim 9, further comprising the steps of : identifying one or more fields of the corresponding records containing numerical identifiers; identifying one or more software components configured to operate on data components having numerical identifiers in those fields; and calling those software components to operate on the data components.

10. A computer storage medium storing computer executable instructions defining a computing system including an order execution system operable for receiving data inputs and performing operations in response to the data inputs, the order execution system a including a data relation structure comprising: a data classification interface defining a plurality of semantic data classes for categorizing data items having original meanings; a plurality of records defining fields configured for containing numerical indicators corresponding to the data items; the numerical indicators being defined within a numbers concept language dictionary in which each numerical indicator is uniquely associated with a base data item; and the data relation structure correlating the semantic data classes 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.

1 1. The computer storage medium of claim 10, further comprising: a data block having an original meaning disassembled into data components, the further disassembly of which would cause the loss of substantially all of the original meaning; and each data component being stored independently as a record expressed in the data relation structure.

12. The computer storage medium of claim 11 , further comprising: software having a required function constructed from a plurality of software components, the further disassembly of which would cause the loss of substantially all of the required function; and each software component being stored independently as a record expressed in the data relation structure.

13. The computer storage medium of claim 12, wherein the data relation structure is functionally configured as a data relation table.

14 The computer storage medium of claim 12, wherein the data relation structure is functionally configured as a semantic network.

15. The computer storage medium of claim 12, wherein: the data classes of the data classification interface are grouped into a plurality of semantic data categories selected from the group of categories including: administration, life, time, space, action, and matter.

16. The computer storage medium of claim 12, wherein: the records expressed in the data relation structure are selected from a group of record types including: data records, condition records, code records, prompt records, label records, and help records.

17. The computer storage medium of claim 12, wherein the computing system further comprises: an interface control system operable for receiving a natural language block; and a language processing system operable for: receiving the natural language block from the interface control system, converting the natural language block into one or more corresponding records expressed in the data relation structure and connoting a unique meaning ascribed to the natural language block, and passing the corresponding records to the order execution system.

18. The computer storage medium of claim 17, wherein the order execution system is further configured to: receive the corresponding records from the language processing system; determine whether the corresponding records define an unambiguous command; execute the command if the corresponding records defines an unambiguous command; and cause the interface control system to prompt the user for additional information if the corresponding records does not define an unambiguous command.

19. The computer storage medium of claim 18, wherein: a plurality of contiguous code records expressed in the data relation structure define a software module for performing a multi-step operation.

20. The computer storage medium of claim 18, wherein one or more data records containing numerical identifiers in a particular field and one or more code records containing numerical identifiers in that particular field identify software defined by the code records that is configured to operate on data defined by the data records.