WO2001035216A2 - Any-to-any component computing system - Google Patents

Any-to-any component computing system Download PDF

Info

Publication number
WO2001035216A2
WO2001035216A2 PCT/US2000/031231 US0031231W WO0135216A2 WO 2001035216 A2 WO2001035216 A2 WO 2001035216A2 US 0031231 W US0031231 W US 0031231W WO 0135216 A2 WO0135216 A2 WO 0135216A2
Authority
WO
Grant status
Application
Patent type
Prior art keywords
data
record
user
field
number
Prior art date
Application number
PCT/US2000/031231
Other languages
French (fr)
Other versions
WO2001035216A3 (en )
Inventor
Peter Warren
Steven Lowe
Original Assignee
E-Brain Solutions, Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/451Execution arrangements for user interfaces
    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10LSPEECH ANALYSIS OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00Speech recognition
    • G10L15/26Speech to text systems

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.

Figure imgf000081_0001
'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:

Figure imgf000082_0001

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'

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

Figure imgf000082_0003

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

Figure imgf000083_0001

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:

Figure imgf000084_0001

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:

Figure imgf000084_0002
'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

Figure imgf000088_0001

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

Figure imgf000089_0001
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

Figure imgf000096_0001

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 & 1st St *

4th 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 & 1st St * 4th Floor & Suite 298' and does not say 'at Broadway & First, 5th 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 24th 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'

Figure imgf000141_0001
Figure imgf000141_0002

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 4th 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

4th 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 6th 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:

A computer, within the limits of the capacities of its hardware, should never limit a user in a manner that he does not limit himself.

Most state of the art software violates this principle when dealing with multi-data type called 'addresses.' For example a single person may have many locations at which he is from time to time - one or more work places, one or more homes, places where he does sports, and so on. Each of these places has its own coordinates - its own street address.

Equally, this single person is related to many documents in his computer - either by the fact that he created them, or by the face that he received them. As far as a human is concerned, he is related to both his documents and his locations, but he is neither of these things. He is not a document and he is not a location. However, the only representation of that person in the computer is his address record - if he even has an address record for himself, which is not certain.

The address record creates a fixed relationship between the representation of the person in the computer - his name - and one location. Sometimes software, in the state of the art offers up to three possible addresses: 'Home' 'Business' and 'Other.' If an attempt is made to create a Computer that Understands with software such as this, which violates the Unlimited Principle, the attempt will fail, as follows.

As soon as a person needs to enter a fourth location for 'Joe' the computer will cease to understand. The work around solution to this is to create another address record for the same person, meaning that there are now two representations for one person in the computer containing Locations numbers 1 , 2 3 and 4. This has now created a fixed relationship between one name and two sets of locations. As shown above however, as far as humans are concerned, a person who communicates with him - for example by e-mail - is related not only to that persons two sets of locations but also to all the e-mails he sends to the user. Should the documents received be related to the first instance of the name or to the second or to the third? Unless the spelling of the name in each of the sets of address record is utterly identical, the relationships will be lost. Suppose that accidentally, the user entered the second set of locations using 'Joey' with an added 'y'. Supposing that the person who sent the e-mails now moves to a new location. The user enters Location 5. He then issues a Unique Data Specification: 'Get me the e-mail Joey sent me about Bananas when he was at his old location.' The specification fails because 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 & 4th 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: 4th 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 1st avenue and 6th 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, 20h

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:

(An2) x ( Bn2>) x ( Cn2)) and is effectively unlimited

The number of different items that can be assembled is always less than the number of different selection criteria - consisting of combinations of Component Part references - that can be created to select any of the created items, since criteria can be created for which no Component parts exist. Equally, a criterion can always be created that will find any item that exists that will also exclude every other item that does not include that combination of Components. For all practical purposes (since the user can add as many different Component parts as he wishes in each of the classes A, B, C... ), both the number of different items, and the number of different selection criteria are effectively limitless.

It can be more compressed and compact to store or to transmit the references to the Component parts, and their relationship to one another, than to transmit Components themselves.

If two or more parties have each stored the same Components, and use the same Component part references, then an item can be transmitted between them by transmitting only the Component references and their relationships. Such transmission is confidential from anyone who does not have available the Components themselves. If new Components are created by one of the two parties, only the new Components need to be transmitted when transmitting Component references and their relationships that contain a new Component part. If Components and the references to them that represent items are transmitted between parties at different times and by different methods, the item cannot be reconstructed by anyone 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:

Figure imgf000186_0001

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:

Figure imgf000194_0001

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.

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

Figure imgf000211_0002

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'

Figure imgf000211_0003

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'

Figure imgf000212_0001

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

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

Figure imgf000214_0001

The Co-reducing Concept Method is used frequently in this Any-to-Any machine and is one of the fundamental understandings, teachings and methods of the Any-to-Any machine that enable and make possible the remainder of the Any-to-Any machine. When the Co Reducing Concept Method is presented in the description of this Any-to-

Any machine, it is represented by the symbol '&' used with a special meaning in this description to mean:

'"&' shows that the two words with which it is used are acting on the Co- reducing Concept Principle and therefore have a specific relationship to one another to convey the meaning of this concept.'

The Co-reducing Concept Principle can be stated simply and colloquially as 'in order to Specify something, meanings are added together by stringing their representative symbols (words) together, each added symbol reducing the scope of the previous meanings, until the remaining meaning is the exact meaning required.' More precisely it is defined as: An item is Specified by adding any one word or any one symbol to any other word, or other symbol with the corresponding result that the Concept encompassed or represented by each word or other symbol is co-reduced to that part of the Concept of each that is common to the other. The process is continued by adding any other word or other symbol - and hence its corresponding Concept - to the pre-existing words or other symbol - and hence to their Concepts. Each new word or other symbol that is added further reduces the Concepts encompassed by the previous words or other symbols to that part of the Concept of each of the words or other symbols that is common to all of them. The process is continued until the part of the Concept common to all words or other symbols present is the Concept that the person wishes to state. (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 12th 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:

Figure imgf000265_0001

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:

Figure imgf000272_0001

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:

Figure imgf000336_0001

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

Figure imgf000341_0001
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 wh