(PICTURE)(PICTURE) (PICTURE)Europäis hes Patentamt
(1 9) (PICTURE) European Patent Offi_e
(PICTURE) Offi_e euroPéen des brevets (1 1 ) E _ O _9_ 8O6 B_
(1 2) EUROPEAN PATENT _PECl FICATlON
(45) Date of pUbliCation and mention (51 ) Int CI.6_. _O6F _ _J3O
of the grant of the patent_.
14_O7_1999 BUlletin 1999l28 (86) InternationaI appIication number_.
PCTICA95lOO685
(21 ) Application number_. 95939199.6 (87) International publication number_.
(PICTURE)(22) Date of filing_. 11 .12.1995 wo g6l18g58 (2o.o6.1gg6 _azette 1gg6l28)
(54) METHOD FOR BINARY-ORIENTED _ET _EQUENCING
VERFAH REN ZUR BINÄR ORl ENTl ERTEN G RUPPENANREIHUNG
(PICTURE)(PICTURE)
PROCEDE POUR LA MISE EN SEQU ENCE D' ENSEMBLES A ORl ENTATlON BINAl RE
__
_
O
OO
h
_h Note.. w._th._n n._ne months from the pubI._Cat._on of the ment._on of the grant of the European patent, any person may g._ve
o nOtiCe tO the EUrOpean Patent OffiCe Of OppOSitiOn tO the EUrOpean patent granted. NOtiCe Of OppOSitiOn Shall be filed in
ii a written reasoned statement. It shall not be deemed to have been filed until the opposition fee has been paid. (Art.
w (PICTURE)99(1 ) European Patent Convention). Printed by Jouve, 75OO1 PARIS (FR)
EP O 797 8O6 B1
Des_ription
(PICTURE)BACKGR UND OF THE I NVENTION
5 1 . FieId of the Invention.
[OOO1] The present invention discloses a method and apparatus for data organization, storage, retrieval and process-
ing, that eliminates locational, structural or associative limitations.
1O 2. Description of Related Art.
[OOO2] Currently, information organization is implemented using many methodologies, which often serve different
and distinct purposes for different general kinds of information. If the information is composed of specific facts, figures,
names, and relationships, then the current approach forces each specific application to provide its own way of defining
15 and using records. The onIy process who can possibIy know what the information is, is the one appIication which
creates/maintains that kind of information. At the lower OS level, data can be any type as far as a database or any
other application is concerned. So files and directories are used to organize information, where physical and logical
organizations of information are one and the same.
[OOO3] To find qualified and desired information, a process must first deal with files and directories. The process must
2O incorporate and refIect the physicaI directoy and fiIe hierarchy into its IogicaI information organization. Many current
containment shells such as WINDOWS and DESQVl EW, attempt to provide a seamless gap between the OS and
applications, so that a process does not have to deal with OS details. Aside from being unstable, such shells are still
constricted by containment. That is, the logical and physical organizations of information become the same at some
Ievel. That is the level at which logical expansions, reorganizations, and further associations become impossible for
25 containment.
(PICTURE)SUMMA Y OF THE INVENTION
[OOO4] To overcome the limitations in the prior art described above, and to overcome other limitations that will become
3O apparent upon reading and understanding the present specification, the present invention discloses a computer-im-
plemented method for information organization, wherein atomic information can be both static and dynamic, but the
compound information (e.g., associations, groupings, sets, etc.) of such atoms always remain dynamic. Unless other-
wise directed, a compound information entity is always dynamically determined and generated. This determination is
based on the processing of a defined condition, wherein all atoms qualifying the condition are included in the compound.
35 This dynamic determination eliminates the need to ''update'' the compound, when atoms and/or compounds common
to two or more compounds are changed. Further, each information compound can be dynamically generated based
on an existing definition for that compound.
BRIEF DESCRIPTION OF THE DRAWI NGS
4O (PICTURE)
[OOO5] Referring now to the drawings in which like reference numbers represent corresponding parts throughout_.
FIG. 1 is a block diagram that illustrates one possible hardware environment for the present invention;
FIG. 2 is a block diagram that illustrates the structure of an InfoFrame according to the present invention;
45 FIG. 3 is a bIock diagram that iIIustrates the associations present in a containment organization_,
FIG. 4 is a block diagram that illustrates the binary associations according to the present invention;
FIG. 5 is a block diagram that illustrates grouping in a containment organization to achieve a combined topic;
FIG. 6 is a block diagram that illustrates grouping according to the present invention to achieve a combined topic;
FIGS. 7A-7E are a block diagram that illustrates a current method of organization implemented according to the
5O present invention_,
FIGS. 8A-8B are a block diagram that illustrates a compound logical structure according to the present invention;
FIG. 9 is a block diagram that illustrates associative processing according to the present invention;
FIG. 1 O is a block diagram illustrating the structure of the Universal Entity Identifier (UEl) according to the present
invention_,
55 FIG. 1 1 is a block diagram illustrating the structure of the Endo-Dynamic Information Node (EDIN) according to
the present invention;
FIG. 1 2 is a block diagram that illustrates the valid combinations of the EDl N fields in terms of value according to
the present invention; 2
EP O 797 8O6 B1
FIG. 1 3 is a block diagram illustrating the structure of the Bond Information Record (BIR) according to the present
invention_,
FIG. 1 4 is a block diagram that illustrates the structure of an InfoFrame according to the present invention;
FIG. 1 5 is a block diagram illustrating the structure of the Bond Flags portion of the BIR according to the present
5 invention_,
FIG. 1 6 is a blockdiagram illustrating the structure of the Bond Organization Record (BOR) according tothe present
invention_,
FIG. 1 7 is a block diagram that illustrates logical bond organizations according to the present invention;
FIG. 1 8 is a block diagram that illustrates the structure of a command line according to the present invention;
1O FIG. 1 9 is a block diagram that illustrates the structure of an Endo-Dynamic Information Statement according to
the present invention;
FIG. 2O is a block diagram that illustrates the structure of an Expandable Table Set according to the present in-
vention_,
FIG. 21 is a block diagram illustrating the structure of the Expandable Table Record (ETR) according to the present
15 invention_,
FIG. 22 is a block diagram illustrating the structure of the Expandable Table Array Header (ETAH) according to
the present invention;
FIG. 23 is a blockdiagram illustrating the structure ofthe InfoFrame Control Record (l FCR) according tothe present
invention_,
2O FlG. 24 is a block diagram that illustrates the structure of an Activation _ist Example according to the present
invention_,
FIG. 25 is a block diagram illustrating the structure of the Infobase Definition Record (l BDR) according to the
present invention;
FIG. 26 is a block diagram illustrating the structure of the Set Definition Record (SDR) according to the present
25 invention_,
FIG. 27 is a block diagram illustrating the structure of the Module Definition Record (MDR) according to the present
invention_,
FIG. 28 is a block diagram that illustrates the structure of a Set Definition Equation according to the present in-
vention_,
3O FIG. 29 is a block diagram that illustrates the structure of an Endo-Dynamic Set comprised of Set Definition Equa-
tions according to the present invention;
FIG. 3O is a block diagram illustrating the structure of the Operator Information Record (Ol R) according to the
present invention;
FIG. 31 is a block diagram illustrating the structure of the Parameter Definition Record (PDR) according to the
35 present invention;
FIG. 32 is a block diagram that illustrates flat storage organization according to the present invention;
FIG. 33 is a block diagram that illustrates the structure of an Endo-Dynamic Set hierarchical data tree according
to the present invention;
FIG. 34 is a block diagram that illustrates the structure of an Endo-Dynamic Set structure definition according to
4O the present invention;
FIG. 35 is a block diagram that illustrates the structure of a program example according to the present invention;
FIG. 36 is a block diagram that illustrates the structure of an Endo-Dynamic Set comprising an interpreted program
according to the present invention;
45 (PICTURE)DETAl_ED DESCRl PTlO_ OF THE PREFERRED EMBODl ME_T
[OOO6] In the following description of the preferred embodiment, reference is made to the accompanying drawings
which form a part hereof, and in which is shown by way of illustration a specific embodiment in which the invention
may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made
5O without departing from the scope of the present invention.
(PICTURE)OV RVI EW
[OOO7] Information can be generally described as either being atomic or compound, where atomic information is an
55 elementary unit and compound information encompasses any combination of atoms and other compounds to se_e a
given purpose. The present invention, termed Binay Oriented Set Sequencing (BOSS), is based on the concept that
the minimal common information structure for any body of data is binay. This binary view of data organization achieves
an information management environment in which any information of any complexity and type can be represented,
3
EP O 797 8O6 B1
viewed, stored, and processed.
[OOO8] The present invention further adopts a view of information organization where atomic information can be both
static and dynamic, but the compound information (e.g., associations, groupings, sets, etc.) of such atoms always
remain dynamic. Unless otherwise directed, a compound information entity is always dynamically determined and
5 generated. This determination is based on the processing of a defined condition, wherein all atoms qualifying the
condition are included in the compound. This dynamic determination eliminates the need to ''update'' the compound,
when atoms and/or compounds common to two or more compounds are changed. Further, each information compound
can be dynamically generated based on an existing definition for that compound.
[OOO9] The present invention differs in several ways from conventional information storage and processing environ-
1O ments. These are listed below, and described in ensuing subsections_.
- The InfoFrame
- Binary Association
- Universal Entity Identification
15 - Dimensia
- Associative Processing
[OO1 O] As a result of these elements, an environment becomes feasible, where the elements of logical organizations
of all data are stored as nodes. Further, processes are able to view the same nodes in different ways. To be more
2O precise, BOSS can achieve any logical structure given the same basic set of information atoms. This means data is
maintained the same way, regardless of the process manipulating it, and regardless of the process'sviewof the involved
data. Instead of having to implement and store static single-purpose control structures and records, a process need
only store a set definition equation which results in a particular view of the data. This promotes an environment in which
a general pool of nodes for all kinds of different data can be used as the basis for dynamically generating different
25 views for all the different processes which use pieces of the collective data pool in different ways.
(PICTURE)HARDW RE ENVIRONMENT
[OO11] Figure 1 depicts the hardware architecture of the preferred embodiment in accordance with the principles of
3O the present invention. Generally, the present invention operates in a network environment 1 OO having a decentralized
hardware architecture, including one or more servers 1 O2, and a plurality of user workstations 1 O4, all coupled together
through the network 1 O6. In the preferred embodiment, the network 1 O6 is depicted as having a ring topology. Those
skilled in the art will be able to bring to mind other known network topologies such as, but not limited to, a star or a bus
configuration. Typically, the server 1 O2 will include a database 1 O8, although the workstations 1 O4 themselves could
35 store all or a part of a database 1 O8.
(PICTURE)THE NFOFRAME
[OO12] The present invention provides for the existence of a global (universal) Information Frame (lnfoFrame), where
4O all types of systems (lnfoBases) which include various programs and databases (modules), and various data structures
and datavalues (views and nodes) can co-exist in the InfoFrame, and data can be created, modified, organized, shared
and exchanged on a dynamic basis. Data exchange across the InfoFrame is trivial, no matter what the system type.
This makes all the processing of data import/export and usage across the InfoFrame invisible to all client processes.
[OO13] FIG. 2 is a block diagram that illustrates the structure of an InfoFrame 2OO according to the present invention.
45 The present invention orders all information in the following manner_.
- Information Frame (lnfoFrame) 2OO, which is the overall grouping of all information.
- Information Base (lnfoBase) 2O2, which is a set of information modules and other control information that provides
a self-contained set of consistent modules which provide for needs of a BOSS client.
5O - Endo-Dynamic Information Node (EDl N) 2O4, which is a binary association of two information atoms, Subject and
Attribute, as well as a Bond that binds them.
- Endo-Dynamic Set (EDS) 2O6, which is a dynamically generated, possibly ordered, list of EDl Ns 2O4that describes,
depicts, or embodies a subject, attribute, or bond.
- Information Module (IM) 2O8, which is a set of EDS's 2O6 and other control information that provides a selfcon-
55 tained set of consistent EDS 2O6 which provide for needs of a BOSS client.
[OO14] An EDS 2O6 may contain any number of EDl Ns 2O4 or be empty. The contents of an EDS 2O6 are dictated
by a condition for that EDS 2O6, wherein the condition is provided by a Set Definition Equation (SDE). The more
4
EP O 797 8O6 B1
complex the SDE, the more particular data and/or data relationships are required to satisfy membership in the resultant
EDS 2O6. However, SDE complexity does not directly effect the size of a resultant EDS 2O6. The size of a resultant
EDS 2O6 simply depends on the number of EDINs 2O4 which satisfy the associated SDE. This size depends on the
kinds of data being organized, and how frequently instances of that kind of data occur.
5 [OO15] All EDS's 2O6 are dynamically generated using one or more modules as the source of generation. A module
2O8 is primarily a set of EDl Ns 2O4 with no particular order. Modules 2O8 can then be included in one or more InfoBases.
Each InfoBase 2O2 provides evolved information access, searching, and processing, by including as many modules
as required to account for all data and processes. The InfoFrame 2OO is the totality of all InfoBases 2O2 and is the
Iargest possible data space. Evey individual computer or network has its own InfoFrame 2OO. When two or more
1O computers or networks are connected such that data exchange is possible, the InfoFrame 2OO has simply become
Iarger. In this sense, there is only one InfoFrame 2OO on a global basis, and it is just a matter of what portion of the
InfoFrame 2OO a user is connected to or has access to.
[OO16] An EDS 2O6 differs from a set, as that term is understood in the art, in several important ways. First, an EDS
2O6 can have a heterogeneous meaning. That is, an EDS 2O6 can contain any number of different meanings, data or
15 representations.
[OO17] Second, an EDS 2O6 does not have to conform to the concept of containment. Containment is where an
element ''X'' physically exists or is ''contained'' within set ''Y''. In a non-containment environment, there is no predefined
meaning between ''X'' and ''Y'', just because one contains the other. In set methodology, the only meaning that can be
derived is that ''X'' is contained by ''Y''. In the present invention, ''X'' and ''Y'' can have any number of relationships
2O defined directly in EDl Ns 2O4 or streams of related EDlNs 2O4.
[OO18] Third, it is possible to execute expressions to modify an EDS 2O6 or create a new EDS 2O6 in terms of a
meaningful formula. This formula is based on operators which can affect EDINs 2O4 or EDS's 2O6 in a number of
different ways. In contrast, set-based mechanisms are based on adding or extracting the meaning of the set by adding
or extracting elements from zero or more sets.
25 [OO19] Since, by default, all modules are accessible across the InfoFrame 2OO, each added module increases the
possibilities for different and new InfoBases 2O2 by a substantially large number. Clearly, this increase is non-linearly
proportional to the number of modules 2O8. Formula A below gives the number of unique possibilities, where ''n'' is the
number of modules 2O8. Formula B gives the absolute increase in unique possible combinations of modules 2O8, when
one module 2O8 is added. Formula C gives the real number of increased possibilities, by assuming that 3/4 of all such
3O unique possibilities have no meaning and serve no purpose in reality. Table l shows the calculated numbers based on
different module 2O8 numbers. A -- ni.
35 B -- (n + 1 )! - n!
4o C -- ((n + 1 )!- n!)/4
wherein the ''!'' operator indicates a factorial operation. As can be seen, this is slightly less than ''n x n''.
45
5O
55 5
EP O 797 8O6 B1
(PICTURE)TA LE I
5 (PICTURE)
1O
15
2O
25 [OO2O] The ease of integration and data sharing, combined with the rapid increase in potential new InfoBases, pro-
vides an environment where, as more data is added and as more processing takes place, the environment as whole
becomes more stable and capable. Further, using automation and chaining for all levels of the InfoFrame 2OO (including
the InfoFrame 2OO), clients can tie together InfoBases 2O2 in particular ways, such that automatic activities take place,
3O these activities including the monitoring, retrieval, storage, and determination of_.
- Entity value;
- Entity organization;
- InfoBase 2O2 chaining and the determination of chains;
35 - Module 2O8 chaining and the determination of chains; and
- InfoFrame 2OO native processes and settings.
[OO21] Given a defined InfoFrame 2OO, client processes can use BOSS operators as to manipulate part or all of the
InfoFrame 2OO in variety of ways to display, modify, process, search, etc. , the information. A BOSS client always calls
4O the Endo-Dynamic Processor (EDP), passing it a list of operators (and their parameters). The EDP is a software Com-
mand Processor (CP), which accepts an operations list as input and executes each line in the order specified by the
operations list. Note that the operations list is an EDS itself, providing for variable number of parameters for the oper-
ators. In a pure BOSS environment, a top-level operation list (program) would be executed at power-on. This program
is an infinite loop where exit is possible by satisfying monitor processes, and where each required InfoBase is located,
45 verified, and initiated. In a multi-tasking environment (e.g. , Windows), linear module chaining and InfoBase chaining
is possible. In a multi-processing environment (e.g., Windows-NT), real-time (and therefore non-linear) InfoBase chain-
ing and module chaining is possible.
[OO22] In a multi-site (computer) environment, each site executes operations lists via its own EDP and accepts remote
operations lists as well. Since a Universal Entity Identifier (UEl) identifies the site from which data originates (i.e. , is
5O located on). remotely located data is potentially slower, but is handled via EDP-to-EDP communication and data transfer
that is invisible to the client. Therefore, it is possible for one site to initiate a process that will execute via the EDP of
another site. thereby leaving the original site free to perform further immediate processing.
BI NARY ASSOCIATION
55 (PICTURE)
[OO23] In a logical information organization, an atom of information can be a logical representation for a topic, event,
process, or entity which can exist, be identified, and requires processing. A logical organization exists when the infor-
mation atoms are associated in different ways to produce a structure. In current information organization methodologies,
6
EP O 797 8O6 B1
the only kind of association between two atoms of information is containment. This is true no matter how evolved the
containment method may be. For example, in object-oriented programming methods, objects can have associated
predefined processes, where this is accomplished by the object containing the processes or references to those proc-
eSSeS.
5 [OO24] Current methods maintain child-lists for each parent to record logical organization. A child is only recognized
as having an association if it is a parent itself.
[OO25] FIG. 3 is a block diagram that illustrates the associations present in a containment organization. In FIG. 3,
the atoms shown on the right, identified as B 3O4, C 3O6, D 3O8, and E 31 O, are the children of A 3O2. The containment
approach is to store the atoms (or identifiers to atoms) B 3O4, C 3O6, D 3O8, and E 31 O in the logical control record for
1O A 3O2. For example, a directory in DOS or UNIX is simply a file containing a list of that directory's contents.
[OO26] Unlike a conventional set-element, the EDl N provides two atoms (or identifiers of atoms)_. a Subject and an
Attribute. Each of the atoms given by an EDIN is an information atom in the sense described above. The Attribute
provides additional association, enhancement or qualification to a given Subject atom. As a result, an EDl N contains
a binary-association within itself. The EDIN is an independent entity, capable of existing in any EDS whose condition
15 (SDE) can be met. The Subject and Attribute atoms can be used in various ways to express any number of different
associations. As a result, an EDS (a set of EDl Ns) can contain any number of singular relationships to describe a more
general association.
[OO27] FIG. 4 is a block diagram that illustrates the binary associations according to the present invention. FIG. 4
shows four EDl Ns with a Subject of A 4O2 and Attributes B 4O4, C 4O6, D 4O8, and E 41 O. The condition for this EDS
2O is simply that the Subject of each EDl N must be A 4O2. Each EDlN provides a relation, but all EDl Ns together describe
the same tree as shown in FIG. 3. In this way, a collection of EDINs provide binary-associations between Subject atom
A 4O2 and the various Attributes 4O4-41 O.
[OO28] Note that it is equally possible to dynamically generate another EDS where the condition (SDE) is that the
Attribute must be B 4O4. This EDS would describe all atoms which have the Subject in a relation with B 4O4. Yet another
25 SDE could produce an EDS where all Subjects are A 4O2 and all Attributes are B 4O4. This EDS would describe all
the possible associations of A 4O2 and B 4O4.
[OO29] Containment methods also experience problems when two existing information organizations need to be
combined. FIG. 5 is a block diagram that illustrates grouping in a containment organization to achieve a combined
topic. The two existing organizations under A 5O2 and B 5O4 are combined to produce a combined organization 5O6.
3O No new associations are produced, the associations of A 5O2 and B 5O4 remain unchanged. Containment methods
have no way of actually integrating the two organizations because identification of atoms is based on location. Consider
the atom D 5O6 under topic A 5O2. This atom also occurs under topic B 5O4. In the resultant combined organization,
atom D 5O6 is duplicated, since the location of the two were different prior to combining the organizations. This is
actually not good as the duplicate atom in the new organization will confuse existing processes which access atom D
35 5O6. As a result, combing two logical containment organizations is often manual and always time consuming. Using
BOSS, the same two organizations can be combined without the problems common among containment approaches.
[OO3O] FIG. 6 is a block diagram that illustrates grouping according to the present invention to achieve a combined
topic. FIG. 6 shows an EDS format of the same topics A 6O2 and B 6O4 as in FIG. 5. Again, atom D occurs both under
topics A 6O2 and B 6O4 prior to the merge. The combined topic 6O6 simply contains all EDl Ns of both topics, where
4O the condition for the EDS is that the EDIN Subject must be either A 6O2 or B 6O4. The atom D occurs as the Attribute
of two EDINs, but is not duplicated. That is, both EDl N Attributes identify the same exact information atom.
[OO31] In this way, BOSS is independent of the location of information atoms in an organization. In other words,
BOSS achieves a complete separation of physical and logical locations of data. Note that this is only possible because
of the endo-binary nature of the EDIN, the derived binary association in an EDS, and universally unique data identifi-
45 cation and location.
(PICTURE)UNIVERSAL ENTITY IDENTI FICATION
[OO32] The next cornerstone of BOSS is the universally unique identification and location of items. In BOSS, each
5O set and each element is uniquely identifiable via a Universal Entity Identifier (UEl). This means that any topic/object
can be uniquely identified, under all conditions. If this were not true and a containment-based approach were used,
BOSS could be inadvertently rendered impotent because the Subject and Attributes of an EDl N could be ambiguous.
The ambiguity is introduced because if an item (Subject or Attribute of an EDl N) cannot be uniquely identified, it cannot
be uniquely or correctly associated with other items.
55 (PICTURE)DIM NSIA
[OO33] The next element of BOSS is called ''Dimensia''. Dimensia loosely refers to contexts or levels of abstraction
7
EP O 797 8O6 B1
that a method for information organization is able to achieve at both atomic and non-atomic levels. Most current systems
use flat or static multi-level methods for information organization. A flat method or structure employs one level of
abstraction. A static multi-level method provides a maximum of N predefined levels of abstraction.
[OO34] In all current methods, an information atom qualifies and/or describes itself. For example, an object in an
5 object-oriented programming system maycontain the atomic element's 32 bit number, string, and date. While describing
itself, the singular atom does not immediately provide a relationship to any other entities. For example, an atomic date
object element simply tells you that fact; it does not provide you with any relationships it may have to any other entities.
It is the object containing the elements which is known to have relationships with each atom. By further including object
deriving procedures in an object, one or more atoms may be related to other entities, but only the object driver knows
1O this fact, and the identity of the associated entities. So even in evolved containment methods, only a limited set of the
data relationships are given by the data itself; the rest is process dependant.
[OO35] FIGS. 7A, 7B, 7C, 7D, and 7E are block diagrams that illustrate a current method of organization, e.g., a
binary tree 7O2. To have this logical structure, the organization can be of two general types. It can be an array 7O4
where tree-traversal is performed via mathematically calculated indexes, based on current index. Or it can be a set of
15 records 7O6 with left and right pointers. ln either case, an inflexible control structure is used to achieve logical organ-
ization. These structures are inflexible because they are static in nature. For example, should the order of the elements
in the array 7O4 change, a different tree (if one is decipherable at all) is now represented. The record example 7O6 is
free of this problem, but the control record is particular and can only be used for binary trees and linked lists.
[OO36] In BOSS, each EDIN contains a Bond between a Subject and an Attribute. As described above and shown
2O by FlG. 3 and FlG. 4, an EDS 7O8 can represent a tree by collecting all EDl Ns with the same Subject. However, to
implement all levels in a tree, Attribute atoms in EDl Ns occur as Subject atoms in other EDINs. In FIGS. 7A-7E, to
record the example binay tree 7O2, an EDS 7O8 records enough EDINs to relate all required associations. Note that
to discern left and right children, the Bond specified in the EDl N can be used. Note that since an EDS is dynamically
generated, insertions and deletions to/from a weighted tree 71 O are trivial as shown in FIG. 7E, and do not involve
25 complex left or right sub tree rotation.
[OO37] In general, by duplicating the EDIN (i.e., twice the control data) with same Subject and different Attributes,
two or more relationships of the same Subject atom and various Attribute entities can be established. In each case,
the particular relationship is identified. In this way, all the different relationships an atom has to one other entity, as well
as expressing all the different entities with which that atom has a relationship, can be expressed. Therefore, using
3O BOSS methodology, the maximum number of possible individually defined relationships of one entity with others is
infinite and is only constrained by the amount of available storage space. This is a major aspect of Dimensia.
[OO38] When complexand/or compound logical organizations of data are used, current methodologies are alsoforced
to employ (and implement) complex and/or compound processes totraverse the organization. Considerthe case shown
in FIGS. 8A and 8B, which are block diagrams that illustrate a compound logical structure according to the present
35 invention. In FIGS. 8A-8B, each atom of the example binary tree 7O2 of FIGS. 7A-7E is also an element in a distinct
and separate two-dimensional array 8O2. Using current methodologies, new structures must be introduced, i.e., eight
two-dimensional arrays of DATA l DENTl FIER. The DATA l DENTIFl ER values of atoms ''A'' to ''H'' would then be stored
in appropriate locations in one of arrays, Al to A8. Now the program dealing with the data must not only include proc-
esses for the old binary-tree record 7O6, but also include processes to manipulate the arrays.
4O [OO39] To implement the example compound organization 8O2 using BOSS, new EDINs are introduced, not new
structures or processes. FIGS. 8A and 8B illustrate a simple (and inefficient) two-dimensional array implementation,
where the EDl Ns are sequenced based on a value calculated from two-dimensional values. The EDS 8O4 actually
encompasses all the arrays, where sequenced subsets of EDl Ns represent two-dimensional arrays. In each EDl N
subset, the atom which coexists in the binary tree 8O2 is shown; this atom would occur in the sequence resulted from
45 its array coordinates. Each such EDl N set is not a two dimensional array in the actual sense, and is very sparse. Again,
the dynamic nature of an EDS, means that the EDS is sequenced upon generation.
[OO4O] Note that the additional EDl Ns 8O4 to represent the arrays could be stored together with the EDl Ns for the
binary tree 7O8 of FIGS. 7A-7E in a module. Upon loading the module, and depending on the Set Definition Equation
(SDE) used, one or the other of the EDS's can be produced. In this way, Dimensia is made possible for information,
5O where no new processes or control structures are required. and only new SDEs and EDl Ns are introduced and proc-
essed (as per before) to produce different and currently incompatible views of the same atoms of data.
(PICTURE)ASSOCIATIVE PROCESSI NG
55 [OO41] The next cornerstone of BOSS is associative processing. As mentioned above, a Bond in a given EDl N iden-
tifies a native BOSS process associated with the Attribute of that EDl N, and possibly involving the Subject of that EDl N.
In a BOSS environment, it is possible to automatically establish and execute new associated processes, based on a
given information set. As a simple example, consider the two EDINs given as 9O2 in FIG. 9, which is a block diagram
8
EP O 797 8O6 B1
that illustrates associative processing according to the present invention. Based on these EDl Ns, the BOSS process
is able to automatically derive and store the third EDl N 9O4. From then on, the item ''X'' has direct relationships with
both ''Y'' and ''Z''. Note that the derived EDIN 9O4 can only be assumed to be correct when the relation is transitive in
nature (i.e., X BOND Y -- Y BOND X). For example, the ''brother of'' relationship is transitive, while ''father of'' is not.
5 Aside from simple association, BOSS can derive associations whose correctness is not absolute. Consider the EDl Ns
given as 9O6 in FIG. 9. Possible automatic derivations are shown as the EDl Ns 9O8. Such proposed EDl Ns can then
be automatically checked for correctness by gathering all data about ''A'' and ''C'' and then performing an exhaustive
cross check to establish one of the following general results_.
1O - Not enough data
- The correct and incorrect EDl N(s)
[OO42] Since EDl Ns with any contents and purpose can coexist in a given module, it is possible to automatically
derive new relationships and associated processing and store such new information in the same module, thereby
15 expanding the lnfoFrame of BOSS on an automatic and dynamic basis.
(PICTURE)HARDWARE EVOLUTION
[OO43] The principles of BOSS outlined thus far are hardware compatible concepts. It is possible to reduce the vast
2O majority of BOSS operators directly into hardware. lndeed, most of the BOSS operators and the Endo-Dynamic Proc-
essor have been designed such that they can be converted (or evolved into) hardware.
[OO44] This simple fact renders BOSS one of the most powerful data organization approaches in existence. Besides
being able to operate two to three orders of magnitude faster than conventional data organization approaches when
implemented in hardware, BOSS is infinitely more flexible.
25 [OO45] Based on the evolution of hardware devices, the demand for order of magnitude solutions is greater than
ever. Further, the existing approaches to solving the increasingly complex data organization, migration and integration
issues are being limited by the engines used.
[OO46] The BOSS methodology also promises interesting advances in CPU design. Consider that a UEl can also be
a machine code mnemonic. A natural result of this fact is that the data of an EDl N can also be a program, under the
3O correct circumstances. Further, it is possible to also create processing actions based on the binary relation found in
an EDIN.
(PICTURE)COM ONENTS
35 [OO47] Unless specified otherwise, when any component or list is stored to file, a number of operations occur. First,
a checksum of the component is calculated. Next, the checksum, followed by a size (or number of records) is stored
at top of file. Finally, the component is saved. Loading performs the reverse actions.
4O (PICTURE)
[OO48] FIG. 1 O is a block diagram that illustrates the structure of a Universal Entity Identifier (UEl), which is the heart
of information location and identification in BOSS methodology. A UEl contains twofields to provide a universally unique
Iocation for a physical body of data. These are the Site Owner Identifier (SOl) and the Site Entity Identifier (SEl). The
SOl is the serial number of the EDP operating at a given site or some other unique identifier for an EDP. The SEl is a
45 unique incremental number per site, where the SEl is assigned and incremented each time a new data entity is created.
An SOl and SEl together are called a Combined Data Identifier (CDl). A CDl combines the duties of identification and
physical location into a single entity. This is contrary to many current methods, where location is derived or is cross-
referenced based on a given identifier.
5O (PICTURE)
[OO49] FIG. 1 1 is a block diagram that illustrates the structure of an Endo-Dynamic Information Node (EDIN), which
comprises the elements in an EDS. The EDIN is the most atomic form of stored BOSS information. An EDl N is com-
posed of four fields, i,e., a Subject UEl, an Attribute UEl, a Bond UEl, and a Sequence field. The Subject, Attribute,
55 and Bond UEls can occur in other EDl Ns and in other fields. For example, an Attribute UEl can be a Subject or Bond
UEl in another EDl N. The Sequence field is used to enforce a predefined order for the EDl Ns in an EDS.
9
EP O 797 8O6 B1
(PICTURE)EDIN CO BINATIONAL BEHAVIOR
[OO5O] FIG. 1 2 is a block diagram that illustrates the valid combinations 1 2O2 of the EDl N fields in terms of value, i.
e., non-null, null, and ''any'' (i.e., could be either null or a valid value) according to the present invention. Since any
5 field in an EDIN can contain a null value, it is prudent to specify the exact set of possible combinations and their
meanings.
[OO51] The first and most common combination is for all valid EDl Ns which are simply elements in a set.
[OO52] The second combination is used when an item of information is ''nullified'' (see below). This has the effect of
making the Attribute item inaccessible in all non-edit BOSS processes.
1O [OO53] The last two combinations are shown for completeness. These combinations, and all others not shown by
FIG. 1 2, are illegal and invalid occurrences of EDINs.
(PICTURE)NUL I FIED EDI NS
15 [OO54] As shown in FIG. 1 2, if the Attribute of an EDl N has a null value, it is called a Nullified Subject Node (NSN),
where the Subject of a NSN is the item being nullified. When a NSN is created, all EDl Ns with the same Subject and
all the EDl Ns with the same Attribute UEl, as the NSN subject, are now prohibited from being including on all subsequent
EDS generations. This has the effect of hiding information, or hiding a particular section in an organization. To remove
a nullification (un-nullify), the NSN is simply removed from a module. Now, all previously invisible items or hierarchy
2O branches are made visibIe again.
[OO55] The NSN is strictly optional and it's presence or absence does not invalidate or limit the working of BOSS
methodology. If used, NSNs can augment BOSS with an information hiding capability.
BOND
25 -
[OO56] The third EDIN field is a Bond UEl value. This ensures that Bonds are universally unique. A Bond value
identifies a process where processing occurs based on an interpretation of the EDl N Attribute field; these include a
noun, verb, adjective, adverb, action, action-sequence, etc. In all cases, the Bond is known to be between the Subject
and the Attribute.
3O [OO57] FIG. 1 3 is a block diagram that illustrates the structure of a Bond Information Record (Bl R), which records
Bond information. A Bl R has three fields. The first is a Bond to provide a key in the Bond Information T_ble (BIT). The
BIT is a list of Bl Rs sorted by the Bond field. As shown in FIG. 1 4, the BIT is stored at the InfoFrame level. The second
field of the Bl R is a flag to describe the basic properties of the Bond. The last field of the BIR is UEl which identifies
the associated process to be executed (by the EDP). This is most often an EDO, but can also be a major subsystem
35 of the EDP which handles this and other similar bonds or a BOSS program. The images and any default values for
bonds are stored in the l MAGE-ETS and DATA-ETS at the InfoFrame level.
[OO58] As shown in FIG. 1 5, the Bond Flags field in the Bl R gives the properties of the Bond, as follows_.
Active/Passive - Active Bonds institute immediate processing and interrupt the active process flow until they are
4O terminated. Passive Bonds are relations which make a statement of fact or existence; they do
not instigate immediate processing, but are used in the various BOSS processes to generate
and process EDS's.
Operator - This flag indicates that the Bond is an EDO. Although redundant, EDOs are also Bonds recorded
45 twice. The UEI for the EDO Bond is identicaI to the EDO UEI given for that EDO in the Operator
IT (forces active as flag enable).
Call - This flag indicates that the Bond is a BOSS process including a SDE, BOSS program, EDP
command list (forces active as flag enable). When this flag is off, the associated process is
5O assumed to be an OS binary program.
Spawn - This flag indicates that a non-BOSS process is to spawn concurrently or multitask (forces active
as flag enable and call flag disable).
55 User/Native - This fIag indicates whether the Bond is a native Bond as suppIied by the EDP, or a Bond created
by other person or process. Whenever a Bond is created, this flag is set to User, since any native
Bonds would be supplied by the EDP or shipped as upgrades.
1 O
(PICTURE)
EP O 797 8O6 B1
[OO59] In order for Bonds to make sense to a user, not only do they have to have names, but also some form of
organization. The names/images for all Bonds are stored in the IMAGE-ETS, using the Bonds as the search key.
[OO6O] In order to provide organization, the Bond Organizational Record (BOR) is used. A minimal form of the BOR
is shown in FIG. 1 6. This BOR contains only two fields, a SELF and a RELATED Bond. Using this simple record, almost
5 any logical organization of Bonds can be achieved.
[OO61] As shown in FIG. 1 7, anything from a multi-level tree 1 7O2 to a simple list 1 7O4 is possible. Depending on
the running process, different logical structures can be adopted.
[OO62] A Bond value should always occur in the Bond EDl N field. Consider a bond UEl which is recorded as a subject
or attribute of an EDl N, with some other Bond value in the EDIN bond field. When this EDIN is processed, the bond
1O recorded as subject or attribute will behave as a subject or an attribute, and not as bond. This can cause errors in EDP
processes and clients which require and recognize the subjected/attributed bond for their critical processing.
15 [OO63] Any dynamically generated or simply loaded list of EDl Ns is an Endo-Dynamic Set (EDS). An EDS always
has a particular purpose and meaning, as known only to the process using the data. For example, an EDS generated
from a program module could be a program data structure, a program data occurrence, or a procedure occurrence.
The EDl Ns in the EDS also may be or may not be ordered, depending on the requirements ofthe data being represented
by the EDS as a whole.
2O [OO64] EDS's are identified by UEls, but for the most part, this is done indirectly and not in the same manner as other
entities. The UEl associated with most EDS's is actually the identifier for a Set Definition Equation (SDE). Given any
module, the SDE can be used to (re)produce an EDS with the same exact membership conditions and potentially
different elements. Instead of storing the distinct EDS's present in a module, only the equations (SDEs) need be stored.
This is required to ensure EDS's generated via SDEs remain dynamic at all times, and is somewhat smaller since set
25 elements need not be duplicated. Since an SDE is itself implemented as an EDS, it is necessay to store the SDE-
EDS in the same module.
(PICTURE)BASIC DI N SEOUENCES
3O [OO65] Information can be generally categorized as being active or passive. In this view, EDl N sequencing in an EDS
takes one of two basic forms_. active sequence and passive sequence. An active sequence is always an executable
process of some form; a passive sequence always expresses the structure, existence, qualities, properties, values,
etc., of some information. Put differently, an active sequence performs some activity, while a passive sequence provides
data about some information. Further, BOSS methodology allows for any combination and number of occurrences of
35 both kinds of EDl N sequencing in the same EDS. However, this would involve overhead processing, and the availability
of a client program to process the passive sequences. Some passive sequences have associated native processes
which handle or drive those particular kinds of passive information required for BOSS operations. In both cases, the
EDIN sequence field is used to establish the EDl N order. For active sequences, the EDl N sequence value starts from
zero and goes up to the number of required EDl Ns, where an EDIN sequence value is never duplicated in an active
4O sequence. For passive processes, the EDIN sequence may or may not be required, depending on the information
being represented by the passive sequence. For example, if the passive information comprises files maintained hier-
archically in directories, which exist in volumes, the sequence field is not required. However, if the passive information
is a data structure definition, with elements in some depth, the sequence fields are used to order the elements of the
structure. The only EDl N sequence value which can be duplicated in a passive sequence is a ''null'' value.
45 [OO66] To express an active sequence, one or more Endo-Dynamic Command Lines (EDCL) are used, where the
order of the EDCLs, as established by the EDl N sequence fields, embodies the required active sequence. To express
a passive sequence, one or more Endo-Dynamic Information Statements (EDIS) are used, where the EDl Ns may or
may not be ordered by the EDl N sequence field.
5O (PICTURE)(PICTURE)
[OO67] The BOSS central process, the EDP, takes command lines as input. An Endo-Dynamic Command Line (EDCL)
is dynamic in nature, and variable length. The basic EDCL 1 8O2 is shown in FIG. 1 8. First, any number of EDl Ns bond
any number of parameters to a subject identification, the subject being an EDCL 1 8O2. Then, an EDIN bonds the EDCL
55 1 8O2 (same subject) to an executable entity, shown as ''XXX''. The EDl Ns are ordered by the sequence field to place
parameters before the execution occurrence. The executable entity XXX could be an endo-dynamic operator, a BOSS
process (including SDE, BOSS program, activation list, etc.), or an OS executable program.
[OO68] EDOs form the ''instruction'' set available from the EDCL 1 8O2. EDO EDCLs 1 8O2 are the fastest to execute,
(PICTURE)
EP O 797 8O6 B1
and require the least amount of overhead processing. A BOSS process is any ordered list of EDCLs. This could be an
SDE, a BOSS interpreted program, an activation list for an InfoBase or InfoFrame, etc. An OS executable program is
externally executed and requires the most amount of overhead processing.
[OO69] The EDCL 1 8O2 differs from conventional command lines in several ways. Clearly, the EDCL 1 8O2 is variable
5 length in that any number of parameters are possible. The EDCL 1 8O2 is also dynamic, in that parameter and execute
EDINs (all EDl Ns for an EDCL 1 8O2) can be changed dynamically, and the EDCL re-executed. Note that the EDCL
1 8O2 trigger for the EDP is the Bond field of the EDl Ns, not the subject or attribute fields. This is an important aspect
of BOSS methodology. Using the Bond as a trigger means that, in EDCL 1 8O2 processing, information subjects and
attributes can occur freely and without affecting the process flow.
1O [OO7O] The EDCL 1 8O2 forms the basis of BOSS processing. Using combinations of EDCLs 1 8O2, any process what
so ever, using any kind and number of parameters, can be accurately recorded and executed. Using the generic EDCL
1 8O2 enables all BOSS clients to dynamically create and modify any kind of EDCL group, and then have it executed
and re-executed by the EDP. As should be obvious, the EDCL 1 8O2 provides a simple and powerful way of implement-
ing, maintaining and executing genetic algorithms. Many of the EDP initialization, and default information processes,
15 are expressed and stored as an ordered list of EDCLs 1 8O2. Any ordered list of EDCLs 1 8O2 is referred to as an Endo-
Dynamic Command Set (EDCS) 1 8O4.
2O [OO71] An Endo-Dynamic Information Statement (EDIS) is two or more EDl Ns which make a statement of fact about
some subject. The basic EDIS 1 9O2 is shown in FIG. 1 9. In this figure, several attributes are bonded (possibly via
different bonds) to the same subject ''A''. When order and hierarchy are required for the information, an EDIN attribute
UEl (shown as ''B'') occurs as the subject of other EDINs, whose attributes further describe the UEl (i.e., ''B'') originally
occurring as an attribute of a subject.
25 [OO72] This is an important aspect of BOSS methodology. The interchangability of the subject and attribute UEls
means that any depth and breadth of information hierarchy can be achieved. Further, upward or backward links can
be introduced into the information hierarchy, such that a workable information networMgraph is achieved.
[OO73] The EDIS 1 9O2 is dynamic in nature, so that the expressed passive sequence is a dynamically established
one. Since EDl Ns can be freely inserted into an EDS, and the EDS reordered, any information represented as a passive
3O sequence remains dynamic. In the example shown in FIG. 1 9, the EDl N sequence fields are not used. However, many
passive sequences require this field to establish order among the EDl Ns. Any passive sequence of EDl Ns is called an
Endo-Dynamic Statement Set (EDSS) 1 9O4.
DATA AND IMAGES
35 (PICTURE)
[OO74] So far, all information has been referred to in terms of UEls. While the UEl does provide all required information
about an entity to a process, it means little to an end-user. For example, while a program can process and maintain
an EDS identified by the UEl value ''1 1 2_. 1 O'', it would be pointless for that program to display those numbers to an end-
user. Clearly, names and/or images must be associated with each unique entity, so that a program can use them in its
4O display interface. Hereafter, ''image'' refers to both a binay image and a name-string.
[OO75] Aside from an image, an entity (as represented by an EDl N), may also have associated physical data. For
example, a BOSS-applied database program would use EDINs to record logical relationships and groupings, but it
could not directly use EDl Ns to store the different data values being maintained by the database.
[OO76] Both images and physical data are examples of Variable Length Data (VLD). To maintain and store VLD in
45 general, a format called ''Expandable Table Set'' is used.
[OO77] As shown in FIG. 2O, an Expandable Table Set (ETS) 2OO2 is afile or memoy pair, consisting of an Expandable
Table Array (ETA) 2OO4 and an Expandable Table Composite (ETC) 2OO6. The ETA 2OO4 and ETC 2OO6 must exist
together or not at all. The ETA 2OO4 is a sorted list, where each element is an Expandable Table Record (ETR) 2OO8.
Each ETR 2OO8 identifies information about (and the location of) an Expandable Table Block (ETB) 2O1 O within an
5O ETC 2OO6. As shown in FlG. 21 , the ETR 2OO8 is a record containing a UEl key, a flags field, an ETB size, an ETB
checksum and an ETB file address. The ETRs 2OO8 in the ETA 2OO4 are sorted based on the UEl key. The ETC 2OO6
is simply a binary dataset composed of a number of variable-length ETBs 2O1 O, in any order.
[OO78] To find an associated piece of VLD, a binay search is performed of the ETA 2OO4 for the input UEl. The UEl
comparison is binary, so if any field of a subsequent input UEl is different, a different associated VLD occurrence exists.
55 Since the ETA 2OO4 is ordered by UEl value, one ETS 2OO2 can be used to store all VLDs of all data. Where two or
more VLDs are required for a single UEl, separate ETS's 2OO2 must be used.
[OO79] As shown in FIG. 2O, each ETA 2OO4 contains an Expandable Table Array Header (ETAH) 2O1 2 at the top,
followed by the actual ETA 2OO4 (list of ETRs 2OO8). As shown in FIG. 22, an ETAH 2O1 2 contains_. a flags field, a self-
12
EP O 797 8O6 B1
ETS UEl, an ETA size (number of ETR's) an ETA CHECKSUM field to enable verification of the ETA file upon loading
an ETC size, an ETC CHECKSUM field to enable verification of the ETC file upon loading, an ETA memory address,
an ETC memory address, an ETC buffer size, a current starting ETR identifier, and a current last ETR identifier.
[OO8O] Through usage, VLDs will come and go in a system. That is, when entities are deleted, their associated VLDs
5 are also deleted. This would leave holes of unused space between the used ETBs 2O1 O of an ETC 2OO6. Fortunately,
the process to optimize an ETS 2OO2 is trivial. First, a temporary ETC 2OO6 buffer is allocated. Then, starting from the
first ETR 2OO8, and by keeping a current pointer, all valid ETBs 2O1 8 are copied, back-to-back, into the temporary ETC
2OO6. To finish, the ETC 2O1 O is overwritten with the temporary ETC 2OO6 buffer and the temporary ETC 2O1 O buffer
is de-allocated.
1O [OO81] If memory is scarce, the optimization can be performed using a buffer as large as the largest ETB 2O1 O. In
such cases, ETBs 2O1 O would be swapped (using unused holes) until they are in a back-to-back order. Unlike the first
scheme, using a single ETB 2O1 O buffer, the ETBs 2O1 O in the resultant ETC 2OO6 may not be ordered in the same
order as the ETRs 2OO8.
[OO82] Since a BOSS element can have an image and have associated physical data, two ETS's 2OO2 are used for
15 each element. FlG. 2O also shows the minimum set 2O1 4 of ETS's 2OO2 required at any level to enable BOSS VLD
maintenance.
(PICTURE)I NFOFRAME
2O [OO83] FIG. 1 4 illustrates the components 1 4O2 of the Information Frame (lnfoFrame), which represents the highest
Ievel of logical and physical data organization in BOSS. The InfoFrame is a definition of the collection and usage of all
InfoBases found at a site, and other sites that may be connected to the home site.
[OO84] FIG. 23 illustratesthe components of an InfoFrame Control Record (IFCR), which is contained in the InfoFrame
to describe the default InfoBase processing, if any, for a site. The l FCR contains a Local Name UEl field to provide a
25 local name for the InfoFrame known to the current site that is used as key into the l MAGE-ETS for the InfoFrame (at
this site). A Flags field is used to record InfoFrame processing configurations. An SOl field recorded from the serial
number of the installed EDP is used to create all UEls generated at the current site. A Next SEl field is used to provide
the next available SEl value across the current site, and this value is incremented, once read, by the EDP processes
which create UEls. A Modifiers field is used to provide operational thresholds and guidelines for the InfoFrame, wherein
3O these modifiers are_. OLDEST VALl D EDS, START TlME, EDS MODl Fy OCCURRENCES, STOP TlME, and EDS
MODl FY FREQUENCY.
[OO85] To absolutely determine when EDS's require regeneration, it would be required to examine each EDl N in each
EDS, to determine all possible EDS's which that EDS is dependant upon (in some way). Clearly, this is atime consuming
and an infeasible methodology to adopt. Instead, the OLDEST VALl D EDS is used. This is a time scalar, indicating
35 how old a valid EDS can be. If this is a low number, EDS's are quickly deemed invalid and in need of regeneration. If
a high number, generated EDS's are deemed valid for long periods of time.
[OO86] While the EDP can record occurrences when distinct changes are made to individual EDS's or SDEs, this
fact is not enough to estimate when an EDS requires regeneration. For this reason, the OLDEST VALl D EDS value is
used.
4O [OO87] While this number can be assigned, an End-Dynamic Operator, ''DETERMINE-OLDEST-VALl D'', can be used
at anytime to automatically determine a value forthis number. The START Tl ME, and the three modifiers EDS MODl FY
OCCURRENCES, STOP Tl ME, and EDS MODl FY FREQUENCY, are used by the DETERMl NE-OLDEST-VALl D op-
erator. When first initiated, this EDO records the START Tl ME, sets the EDS MODl FY OCCURRENCES to zero, and
enables the RECORD MODl FY flag in the IFCR flags. This flag indicates that each subsequent EDS modification
45 requires an increment of the EDS MODl Fy OCCURRENCES modifier. Finally, this EDO prompts for a time duration,
and records a STOP Tl ME. At the appointed stop time, the EDS MODl FY FREQUENCY is calculated based on the
other assigned/accumulated modifiers. This frequency is then used to determine an estimated OLDEST VALl D EDS
value.
[OO88] The InfoFrame also contains a Default InfoBase List (Dl L), whose elements are EDl Ns and which comprises
5O an EDCS. FlG. 24 shows an example DlL 24O2 with three EDCLs. First, for each parameter required for an lnfoBase
activation, an EDIN occurs. No parameter EDl Ns are present if the InfoBase requires no parameters. After the param-
eter EDl Ns, the last EDIN associated with the InfoBase occurs, where the ''activate InfoBase'' EDO performs all tasks
associated with locating and activating a particular InfoBase.
[OO89] A Default Module List (DML) is used in the InfoFrame, whose elements are EDl Ns. The DML is an EDCS,
55 exactly as the DlL 24O2, except that the EDlN subjects are all a UEl generated for the lnfoFrame DML . The lnfoFrame-
DML is used and loaded before the Dl L 24O2, and InfoBase DMLs. This enables the EDP to load native modules which
may have a hand in loading and activating InfoBases.
[OO9O] The InfoFrame also contains an InfoBase definition List (l BDL), where each element is an IBDR. The l BDL
13
EP O 797 8O6 B1
is frequently updated to ensure any newly added InfoBases are included. The InfoFrame contains Data and Image
ETS's to record such data associated directly with the InfoFrame. The InfoFrame contains an Operator Information
Table (OlT), to identify and describe all Endo-Dynamic Operators. The InfoFrame contains one or more EDO program
files, each containing the executable code for one or more operators. The InfoFrame contains a Parameter ETS, to
5 describe all parameters for all EDOs. The InfoFrame contains a Bond Information Table to describe all bonds. The
InfoFrame contains a Default Command List (DCL), to provide a ''default dynamic program'' which EDP always (and
possibly continuously) executes.
I NFOBASE
1O (PICTURE)
[OO91] FIG. 1 4 illustrates the structure of an Information Base (lnfoBase), which is a conglomeration of one or more
information modules. An InfoBase Definition Record (l BDR) is used to provide image and processing options for the
InfoBase. An l BDR file exists for each InfoBase for import/export purposes. All regularly used l BDRs are stored on an
InfoFrame basis.
15 [OO92] As shown in FIG. 25, the l BDR is composed of_. a FLAGS field to provide processing switches, a self-UEl field
to uniquely identify the InfoBase, and an image-UEl field to provide a key into the InfoBase assigning an image for the
InfoBase. The Flags field is identical to the one in the l FCR.
[OO93] A Module Definition List (MDL) is used to provide a list of included modules in the InfoBase. Each element of
the MDL is an MDR as described under module section.
2O [OO94] A Default Module List (DML) is used for the InfoBase structured exactly as the DML stored at the InfoFrame
Ievel.
[OO95] The following modules identified by the InfoBase DML are loaded and activated upon InfoBase activation.
The Data and Image ETS's are used to record such data associated directly with the InfoBase.
[OO96] Modules can be included in an InfoBases in two ways_. shared, and exclusive. A shared module physically
25 occurs once across all lnfoBases in the current lnfoFrame, but may be included in all lnfoBases. ln a BOSS-applied
environment where concurrent processing is possible, the usual precautions and preprocessing must be applied before
access is granted. An exclusive module is what all modules are by default, one that is exclusive to a particular InfoBase.
An exclusive module only appears in the InfoBase it is exclusive to. While other InfoBases can access an exclusive
module, any such access is regulated by the owner InfoBase.
3O [OO97] An InfoBase can store a large amount of data and processing. In general, an InfoBase will have one or more
modules containing data in one or more data organizations, and one or more modules containing programs which
process that data. The modules containing programs which process that data are optional, in that the programs that
process the BOSS data need not be written as BOSS programs; they could be any binary program.
35 (PICTURE)MODULES
[OO98] FIG. 1 4 illustrates the structure of an Information Module (l M), which is a collection of EDl Ns and ETS's to
record the associated images and physical data. The minimum set of required ETS's is used as described in the
previous section. These ETS's store all images and data for the module as well as for all EDl Ns in the CNL. When
4O saved EDS's are present, images associated with saved EDS's are also stored in these ETS's.
[OO99] A Collective Node List (CNL) stores all EDl Ns, in arbitray order, which together make up all the EDS's which
can be generated from that module. The CNL is always loaded upon module activation. Most EDS generation operators
require the specification of one or more modules to use as a source of generation; in such cases, all associated CNLs
must be loaded (in turn) and used as a source for generation.
45 [O1 OO] A Set Definition List (SDL) maintains a list of ''saved EDS's''. Each element in the SDL is a Set Definition
Record (SDR). As shown in FIG. 26, each SDR contains a self- identifier UEl field identifying the EDS, a GENERATlON-
PROCESS UEl field, a Flags field, a LAST-GENERATlON field, an EDS size field, and a memoy address. The LAST-
GENERATlON and memory address fields are only used at runtime, after the EDP has loaded a particular module,
and provide the current location and size of an EDS in memoy. The GENERATlON-PROCESS UEl identifies a process
5O which will generate the EDS_, this can be either an SDE, or another process. The LAST-GENERATlON field is also only
used at runtime; it is a date and time stamp of the last generation. This field provides a measure of how valid or up to
date the EDINs pointed to by EDS address fields are. This field is compared to (current time - oldest valid eds), and if
older, the associated EDS is deemed to be invalid and in need of regeneration. The SDR flags field is used to record
which EDS's are temporary and which are not. Further, it identifies whether the EDS generation process is an SDE,
55 or other process. All newly generated EDS's are by default temporary. Using EDOs, a newly generated EDS can be
made permanent, or a generation process can be made to result in a permanent EDS.
[O1 O1] When an EDS is saved to a module, only unique EDl Ns are added, or old EDl Ns updated in the CNL; EDl Ns
are never duplicated in the CNL. Next, the EDINs which make up the equation (SDE), used to generate the EDS, are
14
EP O 797 8O6 B1
also added to/updated in the CNL. Finally, the UEl for the SDE is added to/updated in the SDL. Now, upon subsequent
module loading, a client can first re-generate the SDE, then execute the SDE to regenerate a (new version of a)
previously saved EDS.
[O1 O2] When a new EDS is dynamically generated, a new unique UEl is assigned to it, and a new SDR created in
5 the SDL. The self-identifier field of the new SDR is assigned from the newly created UEl value. All SDR flags are
cleared, the last generation date is set, and the EDS size and address fields assigned from the newly generated EDS
buffer. The SDE is set from the LAST-SDE global variable; this variable is cleared in each EDP cycle, and is set by the
Iast line of any SDE. As a result, it can be used by the EDP processes to determine the associated SDE (or NULL for
none).
1o [O1 O3] As shown in FIG. 27, the Module Definition Record (MDR) provides a UEl for the module image (stored in
the module ETS's), as well as default processing flags for a module. These are the same flags as for the l FCR and
l BDR. The MDR for a module is always stored in a separate file; this file is only used when importing or exporting
modules. The MDR in this file (along with all other modules used by an InfoBase) are duplicated in the Module Definition
List as defined for an InfoBase. So, in reality, the MDL contains the latest version of all MDRs, and when import/export
15 is required, the MDR file is generated and used. This is done to avoid potentially long update periods every time a
module is modified in some way, and poses no problems because the MDR file is not used in regular processing; only
for import/export.
[O1 O4] A Default EDS List (DEL) is used, where each element is a UEl identifying an EDS to generate (i.e., identifying
an SDE/process to execute). All default EDS's are generated upon module loading.
2O [O1 O5] The l M is a self-contained package of information, providing values, images, data organization(s), data as-
sociation(s), and data processing. The l M is always constructed to serve the needs of a client BOSS process. Since
an EDS can always be dynamically generated from a CNL, it is possible to place incongruent or inconsistent information
in the same module; although this is not recommended, it poses no problems to the BOSS environment, and valueS,
organizations, and associations remain unaffected. Some module examples follow_.
25 - A BOSS program, where procedures, data-structure definitions, and data occurrences are recorded, and later
generated as, EDS's, which are processed by eitherthe EDP ora client BOSS program interpreterto run a program.
- A BOSS menu system, where menus are recorded, and later generated as, EDS's, which are processed by the
BOSS menuing client.
3O [O1 O6] In general it is bestto group information common tothe same compound information entity in the same module.
While out of context EDINs in a module do not create problems by themselves, out of context SDEs and EDl Ns would
create potentially fatal processing problems. For example, consider an out-of-context SDE which generates an EDS
for a data structure definition by default, for a module whose purpose is menuing. This would more than likely hang
35 the menuing client. For these reasons, a BOSS client can construct SDEs which ''filter'' all input EDl Ns for consistency.
Such SDEs can check for particular types and allows and disallow the input. So if the module is a menuing system,
data types like ''procedure'' could be optionally disallowed.
4O (PICTURE)
[O1 O7] As mentioned above, EDS's are based on Set Definition Equations (SDEs). An SDE is an expression com-
posed of Endo-Dynamic Operators (EDOs) and operands. An Endo-Dynamic Operator (EDO) can be almost any kind
of operator. FIG. 28 shows an example SDE 28O2 with a C-like format. A new EDS called MY-EDS will be the result
of resolving the right hand side of the equation. The atomic binary SDE units are shown and numbered 1 , 2, and 3
45 from the deepest to the outermost SDE unit. The SUB, SEQ, and ATT mnemonics are EDOs that perform filtering
based on different fields of the EDl N. The l NTERSECT mnemonic is a logical EDO and signifies that the resultant setS
of both operand expressions must be intersected. The expression shown in FIG. 28 dictates that all EDl N's in the ''MY-
EDS'' EDS will have a Subject equal to ''W_.X_.'' and an Attribute equal to ''A_.B_.''. The ''MODULE-N'' module is the module
used here for all operators. except l NTERSECT.
5O [O1 O8] The SDEs are always binary in nature. No matter how complex the equation, it can always be broken down
into binary (and unary) SDE-units. As a result, an SDE is easily implemented as an EDS.
[o1o9] FIG. 29 shows an EDS 29O2 for the SDE depicted in FIG. 28. This shows the Subject and Attribute fields of
the EDIN as UEls. This EDS 29O2 also shows the Bond and sequence field values. As can be seen in FIG. 29, the
SDE is simply an EDCS. In this case, these EDCLs are shown, i.e., one for each EDO showing in FIG. 28.
55 [o11 O] In this way, an EDS 29O2 can be used tostore equations (SDEs) which define howother EDS's are dynamicalIY
generated. The subject fields of all EDl Ns will always contain a unique SDE-UEl associated solely with MY EDS. The
SDE by itself does not result in anything. But when the SDE is applied to an existing EDS or module, a new EDS can
be generated. As a result, a single module, with multiple SDEs, can provide different dynamically generated EDS's.
15
(PICTURE)
EP O 797 8O6 B1
[O111] As mentioned above, Endo-Dynamic Operators (EDOs) are tothe Endo-Dynamic Processor (EDP) as instruc-
tions are to a processor. An EDO is any executable body of code requiring any number and type of parameters. While
5 the code for most EDOs is in the form of a binary executable OS program (or procedure), EDOs expressed as EDCS's
can also be created and used. As should be obvious, an EDO occurrence with all its required parameters forms a
complete EDCL. So it is possible to construct an EDO and EDCL, such that the EDCL activates the EDO (via the EDP),
wherein the EDO is itself an EDCS processed by the EDP. This forces the EDP to be re-entrant, where the EDP must
be capable of correctly processing any number of EDCS's in as many streams of processing as initiated by various
1O processes.
[O112] Unlike conventional ''instructions'', the EDO is not limited in size or complexity. The EDO can be anything from
a one line procedure to a whole system (program). Further, EDOs can freely call each other without interfering with
EDP process leveling or the EDP stack.
[O113] Incorrect process streams which are potentially fatal are terminated, mostly before and sometimes after a
15 fatal process error has occurred. All stack data regarding the process(es) which were involved in a process stream
resulting in the fatal error(s), can be safely and accurately removed from the EDP stack, such that pursuant EDP
processing, and other existing processes can continue.
[O114] For each EDO available for use, there exists an Operator Information Record (OlR). As shown in FIG. 3O,
each Ol R contains_. an OPERATOR UEl field to provide a key in the OlT, a NUMBER OF PARAMETERS field to give
2O the total number of input and output parameters required by the operator (the number of PDRs in the associated list),
an Endo-Dynamic-Libray UEl to identify the library that contains the executable code of the EDO, and a CALLl NG
ADDRESS field to provide a memory address forthe operatorthat is onlyvalid at runtime afterthe operator's executable
code has been loaded into memoy. The OlRs are used at run time to verify calls to, and execute operators. As shown
in FIG. 1 4, all Ol Rs are permanently maintained in the Operator Information Table (OlT), maintained at the InfoFrame
25 level. The OlT is a sorted list, wherein a binay search locates a given OlR. The OlT is updated when EDOs are imported
or modified.
[O115] To record parameter data requirements for EDOs, the PARAMETER-ETS is used. As shown in FIG. 1 4, this
ETS is stored at the InfoFrame level. The ETRs in this ETS have EDO UEls as the keys. The ETBs store ordered lists
of records, where each record is a Parameter Definition Record (PDR). As shown in FIG. 31 , a PDR contains_. a Flags
3O field to identify general l/O type of the parameter, a Data Type field to identify the required data type to internal BOSS
processes, a Data Size field to give the size of the identified data type, a Type Image UEl field that identifies an image
for the data type stored in the InfoFrame l MAGE-ETS and a Default Value UEl field that points to a default value
occurrence for the parameter in the InfoFrame DATA-ETS (if no default value is supplied, this field contains a null UEl).
Both the OlT and the Parameter ETS are used at run by the EDP to perform verified dynamic enty and execution of
35 EDCLs.
(PICTURE)EDO- NFOBASE
[O116] An Endo-Dynamic Library (EDL) is an Information Module which provides a means fortransporting and storing
4O all information regarding a given set of EDOs. All EDOs in an EDL should be related in some general way; this is often
(part of) the name for the library. Note that hereafter and throughout the document and figures, ''Library'' is used inter-
changeably with ''EDL''.
[O117] A strictly logical entity called Endo-Dynamic Group (EDG) is used to organize all EDLs in various ways. Note
that hereafter and throughout the document and figures, ''Group'' is used interchangeably with ''EDG''.
45 [O118] All EDLs are collected by the Endo-Dynamic Operator InfoBase (EDO-lnfoBase). The EDO-lnfoBase is an
InfoBase like any other, but also encompassing any additional program files required by the EDLs. The EDO-lnfoBase
provides a way of accessing all available libraries and libray information. Further, using the InfoBase DML, a certain
base set of libraries are always activated (i.e., loaded and ready to be processed via EDP). The EDO-lnfoBase is
supplied with each EDP program/package, and is necessary for the operation of the EDP.
5O [O119] While the OlT and the parameter ETS provide for quick EDP processing at thetop level, the bulkofthe required
data for the EDO processing is provided by the EDO-lnfoBase. The module components as shown in FIG. 1 4 are used
as follows for a libray. A library module is no different than any other module, except that in some cases additional
program files are also associated with the module.
[O12O] The Module Definition Records (MDR) comprises normal module information, wherein the System flag is
55 enabled.
[O121] The Collective Node List (CNL) stores EDl Ns in no particular order. As well as normal SDE recording and
processing, these EDl Ns are used in two ways.
[O122] First, these EDINs are used to organize and specify EDOs in the libray, the fields need to be set a certain
16
EP O 797 8O6 B1
way. The Subject field should contain a UEl for an EDL,or a UEl for an EDLG. The Attribute field should contain a UEl
for an EDO. The Bond field should contain an ''EDO Occurrence,'' which indicates that there is an occurrence of the
EDO given by the attribute in the libray given by the subject. Finally, the Sequence field is not used.
[O123] In addition, these EDl Ns are used to record EDOs programmed as EDCLs, all fields are set as per an EDCL.
5 All EDl Ns in this CNL can be sorted by the two keys, i.e., subject and attribute, to provide an overall hierarchy of the
operator groups and libraries. In addition, the CNL can be filtered for a particular subject (library or group) to generate
EDS's which can be used as menus, which are then traversed, generated a new menu EDS at each traversal step.
When an EDIN in library menu EDS is selected, any number of further information is available for the EDO identified
by the EDl N's attribute (e.g., PDRs, image, code, etc.). The client process can then perform further processing using
1O the EDO information.
[O124] The Image-ETS stores all images associated with all EDOs (and their parameters) in the library, as well as
the image(s) for the library itself.
[O125] The Data-ETS uses a UEl key. Associated with the library (i.e., using the module UEl), is an ETB containing
a list of OlRs. This provides a list of all EDOs in the libray. Associated with each EDO (i.e., using the EDO UEl), is an
15 ETB containing a list of PDRs, describing the parameters of the EDO.
[O126] The SDL identifies SDEs (stored in the CNL) to generate an EDS. For SDE-1 , EDINs are sorted by the two
keys_. by subject and attribute to provide an overall hierarchy of operator groups and libraries.
[O127] For SDE-2, EDl Ns are filtered for a particular subject (library or group) to generate EDS's which can be used
as menus, which are then traversed, generating a new menu EDS at each traversal step. When an EDl N in libray
2O menu EDS is selected, any number of further information is available for the EDO identified by the EDl N's attribute (e.
g. PDRs, image, code, etc). The client process can then perform further processing using the EDO information.
[O128] For SDE-3, EDINs are filtered for a particular EDO subject, and sorted by the sequence. This SDE generates
an EDCS executable by the EDP.
[O129] For DEL, this has one default EDS_. EDS for the top-level group. This is the same as SDE-2 above, where
25 the source subject is predefined.
[O13O] If the code associated with an EDO is an EDCS, all EDINs required to make up the EDO's code body are
also stored in the CNL. If the code associated with an EDO is not an EDCS (i.e., if the EDO code is some form of OS
executable code body), in addition to all normal module files, an OS program file is also stored. This program file has
a filename derived from the associated EDO UEl values, plus the normal OS executable extension. All such executable
3O EDO program files are stored at the InfoFrame level.
[O131] When any libray information is loaded, imported, or modified, appropriate updates are made at the InfoFrame
Ievel. After any such events, the OlT, parameter ETS, and any EDO program files are updated as required, using the
just saved library data. While updating the system EDO information is a simple procedure of replacing records and
files, the effects of such updates on user data containing references to the updated operators could potentially be a
35 difficult to determine and diagnose.
(PICTURE)LI BRAR ES AND OPERATORS
[O132] The EDP requires a minimum basic set of libraries to operate. These are_.
4O - Set Filtration Libray
- Control Flow Library
- Physical Manipulation Library
45 [O133] The general membership requirement(s) and a minimum set of EDOs are described for each library by the
following sections. In addition to any listed EDOs, any other qualifying EDO can be added to a library. However, all
such dynamically created EDOs are always tagged as ''user'' in the associated Ol R.
[O134] When EDOs are also made into bonds (a matter of creating bond control records, since the process already
exists as the EDO), a viable but limited language is realized for defining and executing BOSS programs embodied by
5O information modules, complete with data definitions as realized by EDS's (each is an EDS in the module) and executable
code as realized by EDCS's (each is an EDS in the module). The more evolved and/or complex EDOs that are intro-
duced, the more robust such a language will become, but it will do so non-linearly. This is because any introduced
EDO can call others in any (meaningful) combination that it sees fit. Each added EDO increases the number of new
possibilities combinatorially.
55 [O135] Further, given sufficient numbers of added EDOs, any number of such dynamic programming languages are
simultaneously possible, where languages can interface invisibly to any of the involved specific language processes.
Any and all such languages are simply an implementation of several BOSS concepts and the specific usage of several
BOSS entities disclosed in this patent. 17
EP O 797 8O6 B1
(PICTURE)SET FI TRATION LI BRARY
[O136] An EDO in this library must process EDl N list(s), based on any kind of input, to produce subsets of that EDl N
list, or new EDIN list(s). The minimum required set of filter EDOs are described below. The EDOs listed below constitute
5 the minimum required set of EDOs in the filtration library_.
_
[O137] This EDO combines two or more input EDS's into a third output EDS.
1O (PICTURE)Intersection
[O138] This EDO examines two or more input EDS's for common EDl Ns and outputs a third EDS containing only the
common EDl Ns.
15 (PICTURE)
[O139] This EDO searches the input EDS for EDl Ns having a match in their subject field with an input subject and
returns those EDl Ns in a new EDS.
2O (PICTURE)Attr'bute-match
[O14O] This EDO searches the input EDS for EDl Ns having a match in their attribute field with an input attribute and
returns those EDl Ns in a new EDS.
25 (PICTURE)Bo d-match
[O141] This EDO searches the input EDS for EDl Ns having a match in their bond field with an input bond and returns
those EDl Ns in a new EDS.
3O (PICTURE)
[O142] This EDO searches the input EDS for EDl Ns having a match in their sequence field with an input sequence
and returns those EDINs in a new EDS.
35 (PICTURE)(PICTURE)
[O143] This EDO sorts the EDINs in the input EDS by their subject field and then assigns sequence numbers to those
EDINs based on their sorted order.
4O (PICTURE)Remove-nodes
[O144] This EDO searches for and then deletes the input EDIN from the input EDS.
45 (PICTURE)Descendants
[O145] This EDO searches for any EDINs in the input EDS that are the descendant of the input EDIN.
Ancestors
5O (PICTURE)
[O146] This EDO searches for any EDINs in the input EDS that are the ancestor of the input EDl N.
_
55 [O147] This EDO searches for any EDINs in the input EDS that are the siblings of the input EDIN.
[O148] All of the above EDOs provide the basis for constructing SDEs to formulate and process anything from a
simple database query, to data structure collection and processing, to evolved, multi-level queries where specific in-
formation is qualified to any degree and extent. Each specific application requiring filtration would introduce SDEs
18
(PICTURE)(PICTURE)(PICTURE)(PICTURE)(PICTURE)(PICTURE)(PICTURE)
EP O 797 8O6 B1
which use the above listed system-EDOs in various combinations with other EDOs to accomplish further specific fil-
trations. Any one such client procedure or program (in a client program module) can be made into a user-EDO, and
incorporated into the currently known InfoFrame. Clients would create all EDOs associated with a general purpose in
the same EDO-library, and add the libray to the EDO-lnfoBase. This makes the client supplied EDO accessible by all
5 BOSS clients in the lnfoFrame.
[O149] In this way, flexible, dynamic, and custom-made information search engines can be built and supplied as
EDOs. Such EDOs would be then used by even bigger BOSS clients such as an expert system, to unify, simplify and
speed up minor information gathering and simple correlation tasks.
1O (PICTURE)CO_T_O_ F_OW _lB_A_y
[O15O] An EDO in this library must be associated with process flow of the EDP, or that of a BOSS client. The following
lists and describes the minimum required EDOs for this libray. Although more complex control flow EDOs are possible,
such EDOs would simply be ''implementations'' of the technology disclosed by this patent.
15 _P h
[O151] This EDO pushes the parameters onto the EDP stack.
2O _P
[O152] This EDO pops a value from the stack into the parameters.
Peek
25 -
[O153] This EDO uses a stack index number to determine a stack enty from the top. and return the value stored
therein into the given parameters.
Poke
3O -
[O154] This EDO uses a stack index number to determine a stack entry from the top. Then the parameters are stored
into the stack enty.
35 (PICTURE)(PICTURE)
[O155] This EDO returns a true or false value dependent on the condition of the stack.
(PICTURE)St ck-fuII
4O [O156] This EDO compares total stack space against currently used space and returns true or false value dependent
on the condition of the stack.
45 [O157] This EDO locates, loads, and executes the binary OS program identified by the input UEl. This EDO waits
for the program to terminate before returning.
5O [O158] This EDO locates, loads, and spawns the binary OS program identified by the input UEl, as a concurrent
process. This EDO does not wait for the program to terminate before returning.
55 [O159] This EDO locates, loads, and executes/spawns the BOSS program identified by the input UEl. This EDO may
or may not wait for the program to terminate before returning, depending on availability of concurrent processing in
the environment. 19
(PICTURE)(PICTURE)(PICTURE)(PICTURE)
EP O 797 8O6 B1
[O16O] This EDO sets the global variables associated with input to the input values, thereby performing an uncondi-
tional jump to another EDCL.
5 (PICTURE)
[O161] This EDO performs a jump as per the jump EDO, but based on a condition. The condition is a BOSS process
(sets of ordered EDCLs), which returns true or false. In most cases, the condition can be automatically generated as
1O a SDE.
(PICTURE)PHYSICAL MANI PULATION LI BRARY
[O162] An EDO in this libray must manipulate EDS's and EDINs at a physical level, where a possible input parameter
15 for a physical EDO is a physical memory address. Some of these physical EDOs are_.
-Sort
[O163] This EDO sorts the EDl Ns in the input EDS.
2O (PICTURE)
[O164] This EDO removes duplicate EDl Ns in the input EDS.
25 _L th
[O165] This EDO determines the length of the input EDS.
Generate-eds
3O (PICTURE)
[O166] This EDO generates an EDS for the input EDl Ns.
(PICTURE)Activ te-moduIe
35 [O167] This EDO activates the module created by the EDl Ns in the input EDS.
(PICTURE)Activ te-InfoBase
[O168] This EDO activates the InfoBase created by the EDl Ns in the input EDS.
4O [O169] The other physical EDOs are listed and described below. Mostly these EDOs are combinations of calls to
other EDOs already described.
45 [O17O] This EDO loads the input file into an allocated memory buffer, performing checksums, and returning the ad-
dress of the allocated buffer.
5O [O171] This EDO will irretrievably purge previously deleted BOSS data by deleting entries in trash files. The input
parameter WHERE is a UEl. If the value is null, the purge will occur for all deleted data in the InfoFrame. If a non-null
value, the UEl either identifies an InfoBase (find an l BDR matching the UEl) or a module (find an MDR matching the
UEl). In these cases, all deleted data in the located InfoBase or module will be purged. The DAYS parameter is optional
and specifies the number of days to keep deleted information.
55 (PICTURE)
[O172] This EDO will retrieve previously deleted, but not purged, information. The input parameter WHERE is a UEl.
2O
(PICTURE)(PICTURE)(PICTURE)
EP O 797 8O6 B1
If the value is null, the restore will consider all deleted data in the InfoFrame. If a non-null value, the UEl either identifies
an InfoBase (find an l BDR matching the UEl) or a module (find an MDR matching the UEl). The DATA-UEl identifies
the deleted data to be restored. If this value is null, all deleted data in the identified location is considered for restoration.
Ifthe DATE parameter is non-null, it is usedtogetherwith the DIRECTlON parameterto restore occurrences of qualifying
5 information deleted on, before, or after a specific date. If the AUTO parameter is non-null, this EDO will make a best
guess for all information restorations when duplicate deleted data is encountered. Otherwise, this EDO will prompt an
operator with a choice of duplicate deleted information with different dates. The best guess is arrived at by grouping
deleted data by date stamp, then restoring the set of data with the most recent date.
1O (PICTURE)
[O173] This EDO retrieves and returns the image (or name) associated with input UEl, from an l MAGE-ETS. The
search starts from current module l MAGE-ETS and expands to parent InfoBase and InfoFrame if not found at the
module level.
15 (PICTURE)
[O174] This EDO retrieves and returns the image (or name) associated with input UEl, from an l MAGE-ETS. The
l MAGE-ETS is located in the same manner as get-image EDO. When located, the associated ETB image contents
2O are replaced with the input l MAGE.
[O175] This EDO creates a new node in the input module's CNL, using the given input parameters to set the node's
25 fields. The sequence field can be supplied as ''null'' when not required. This is how information is added to BOSS at
it's most primitive level. This process can be triggered from any environment, so long as the UEls provided are valid,
or will have meaning.
3O (PICTURE)
[O176] This EDO moves all EDl Ns in the CNL associated with input module, which are binary-equal to the input
EDIN, NODE, to an associated trash CNL.
35 (PICTURE)
[O177] This EDO receives a memory address, POlNTER, to start of a list of EDINs in (some) memoy. This is NOT
an active EDS at this time. Also receives a COUNT to indicate the number of EDl Ns in the list. This operator creates
a new active EDS (not stored) containing the list of EDl Ns, and returns a newly assigned UEl value. This operator is
useful for processes that either automatically or via user input, create EDl Ns from scratch. The new EDS is always
4O added to the CNL associated with an existing module identified by input MOD-UEl.
[O178] This EDO receives a MOD-UEl to identify a CNL to add nodes to, as well as a memory address, POl NTER,
45 to start of a list of EDlNs, and a COUNT of those EDlNs. The given EDlNs are then added to the identified CNL. This
operator will not add binay equal EDl Ns which already exist in the CNL.
5O [O179] This EDO makes a new EDS with the same contents as the EDS given by input EDS-UEl and returns a unique
UEl to the new EDS. The new EDS is created in the module identified by the input MOD-UEl (this must exist) The EDS
image remains the same.
55 (PICTURE)
[O18O] This EDO first generates the input EDS-UEl via generate-eds EDO, if required. Next, it calls the intersect
EDO and the assigns the CNL of the input module to be the resultant ''xor-eds'' (i.e., the EDS containing EDINs in the
CNL but not in the generated EDS). The generated EDS is then added to the associated trash CNL. Finally, the asso-
21
(PICTURE)(PICTURE)(PICTURE)
EP O 797 8O6 B1
ciated SDL and DEL entries matching EDS-UEl are moved to the associated trash files, if they exist.
5 [O181] This EDO is probably the most time and space consumptive EDO. It assumes that an EDS (EDS-UEl) was
previously generated using the generate-eds EDO and then the EDINs in the memoy image were modified by some
client process. At this point, the memory image of the EDS needs to be updated in the module CNL to reflect any
changes made by the client process. For example, consider a module containing several procedures of a program.
Each EDS can then be generated from the program module on a dynamic basis. Once generated, the procedure can
1O be dynamically modified by a programmer. Finally, the procedure is saved again in the program.
[O182] Unlike specifically deleted EDINs and data, replaced EDINs and their associated data cannot be recovered,
unless steps are taken by an Endo-Dynamic Editor.
[O183] In concurrent environments, where multiple processes can access the same the module, it is best to let the
currently used Endo-Dynamic Editor handle all such issues. Being dynamic, the EDE can be called by a BOSS client
15 process to safely load, edit, and/or save EDS's in modules.
[O184] This EDOcreates anewmodule called NAME in the InfoBase given by InfoBase-UEl. This EDOfirst generates
2O a new unique UEl for the new module. Then it creates an associated MDR in the lnfoBase's MDL, with the newly
generated module UEl. Next, all required module files (as shown in FIG. 14) are created (empty except for control).
Now the input module name is inserted in the new module image ETS, by creating another new UEl for the image.
The image UEl is also stored in the new MDR. Finally, the inputs FLAGS are assigned to the new MDR. The module
can now be used as a source of any physical manipulation to add data, and later as a source of filtration to generate
25 new EDS's.
[O185] This EDO first generates a new unique UEl for the new module. Next, all module files for module MOD-UEl
3O are copied to files with the same extensions and the new UEl for filename. Then, a the MDR for MOD-UEl is copied
into the MDL for the input InfoBase (lnfoBase-UEl), and its self identifier set to the newly generated module UEl. The
new module name remains unchanged if the NAME parameter is null. If NAME is a valid image, it will be copied to the
newly copied IMAG-ETC, replacing the existing value. The image UEl value need not change.
35 (PICTURE)
[O186] This EDO first appends the contents of all module files to their appropriate trash files, and then deletes all
module files, as well as associated control records.
4O (PICTURE)(PICTURE)
[O187] This EDO creates a new InfoBase called NAME in the currently known InfoFrame. This EDO first generates
a new unique UEl for the new InfoBase. Then it creates a new IBDR in the IBDL, with the newly generated InfoBase
UEl. Next, all required InfoBase files (as shown in FIG. 11 ) are created (empty except for control). Now the input
45 lnfoBase name is inserted in the new lnfoBase image ETS, by creating another new UEl for the image. The image UEl
is also stored in the new IBDR. Finally, the inputs FLAGS are assigned to the new IBDR. The InfoBase can now be
used as a source of any physical manipulation to add data, and later as a source of filtration to generate new EDS's.
5O (PICTURE)
[O188] This EDOfirst generates anew unique UEl forthe new InfoBase. Next, all InfoBasefilesfor InfoBase InfoBase-
UEl are copied to files with the same extensions and the new UEl for filename; this DOES NOT include module files
for all modules encompassed by the InfoBase. Then, a the IBDR for InfoBase-UEl is copied in the IBDL, where the
self identifier is changed to the newly generated InfoBase UEl. Finally the new InfoBase UEl is returned. If NAME is
55 a valid image, it will be copied to the newly copied lnfoBase lMAGE-ETC, replacing the existing value. The modules
are shared by InfoBases. An InfoBase encompasses modules by including MDRs for modules in its MDL.
22
(PICTURE)
EP O 797 8O6 B1
[O189] This EDO first appends the contents of all InfoBase files to their appropriate trash files, and then deletes all
InfoBase files. finally all associated control records at the InfoFrame level are trashed. If the CONTENTS parameter
5 is non-null, all modules encompassed by the InfoBase are trashed via calls tothe delete-module EDO, priorto all above
steps.
(PICTURE)PHYSICAL TORAGE OF BOSS ENTITIES
1O [O19O] Each of the BOSS entities described above, as well as all those shown in FIG. 1 4, is identified and located
by a unique UEl. The identification methods have been described in the sections above. The location method is irrel-
evant to the BOSS technology, and any method will do, which given a UEl, can locate the physical data associated
with that UEl. The following describes one such method of physical data storage and location.
[O191] Using a conventional containment storage system (e.g. UNIX, DOS, Windows), create an InfoFrame directoy
15 in a storage media attached tothe computer. The location of this directory, in the existing directory hierarchy, is recorded
in the EDP program, such that when EDP is run from anywhere, it will be able to locate the directoy. Further, all files
shown in FIG. 1 4 (at all levels) are stored directly in the InfoFrame directory. This flat and simple model is depicted in
FIG. 32. Two distinct file-sets are distinguishable at InfoFrame level_. system and information files. System files contain
those BOSS data entities which are critical to the correct operation of BOSS processes. Information files are generated
2O as a result of information stored in BOSS format. At the lnfoFrame level, there is exactly one of each file 32O2 shown
in FIG. 32. At the InfoBase and module levels, there are many files. In FIG. 32, the number N represents the total
number of InfoBases known to the InfoFrame, the number M represents the total number of modules in all InfoBases,
and the number E represents the total number of available EDO program files. Each InfoBase, module, or EDOfilename
is a string derived from the UEl value identifying that InfoBase, module, or EDO; this derived string is shown as '''', '''', or '''' in FlG. 32. Since UEls are guaranteed to be unique, there is no possibility of
conflicting filenames in the InfoFrame directoy. Now given a UEl for an entity, all filenames for all files associated with
that entity can be constructed and immediately located in the InfoFrame directory.
[O192] Looking at FIG. 32, it should be clear that the connecting link between an IBDR and the InfoBase files, and
the connecting link between an MDR and the module files, is a UEl. For example, the InfoBase UEl identifier in an
3O l BDR is used to generate the filename string associated with all files for that InfoBase.
(PICTURE)BOSS I N ORMATION DELETION
[O193] When information is deleted in a BOSS environment, it is always via a physical EDO involved in data deletion/
35 restoration. These EDOs define the methods of information deletion in BOSS. The delete-node, and delete-eds EDOs
do remove information such that subsequent generations will not find the ''deleted'' information. However, until ''deleted''
data is automatically or manually purged, it can be restored. Data is purged via the purgeclata EDO, or as part of
automatic BOSS processing (again via purge-data), where a concurrent process is initially started upon EDP startup.
This process would regularly schedule purges, based on initial user input or default values for to-purge durations. To
4O enable this, all associated BOSS files (shown in FIG. 1 4) will have an associated ''trash'' file, where a trash file is
structured as its real counterpart, where in addition toa record, a date/time stamp of deletion is also stored. For example,
while the entries in a real CNL are just EDl Ns, a trash CNL contains records of the following structure_.
- EDIN
45 - Tl ME STAMP
[O194] Entries are duplicated in a trash file until purged. To restore information, the restore-data EDO is used. The
nature of this EDO enables manual as well as automatic data restoration, where all information links and data are also
restored as before.
5O (PICTURE)DEFAU T COMMAND LIST
[O195] As shown in FIG. 1 4, the Default Command List (DCL) is an EDCS. The DCL is executed by the EDP after
InfoFrame initialization is complete. If no DCL is defined, the EDP goes into an idle state, where it waits for input EDCLs.
55 The best usage of the DCL is to implement a procedure containing an infinite loop, where the loop body activates/
reactivates any systems, InfoBases, modules, and/or EDS's required to realize a continues and changing overall proc-
ess. The DCL is dynamic, in that any process activated as a result of an EDCL in the DCL can alter the contents of
the DCL and return. This has the effect of altering the continuous EDP process in arbitrary ways. The DCL enables
23
EP O 797 8O6 B1
the EDP to institute dynamic perpetual processing.
[O196] The InfoBase and module activation processes will insert EDCLs in the DCL, as and when required. As a
result, the DCL is automatically created/modified after InfoFrame initialization is complete.
5 (PICTURE)
[O197] The BOSS environment requires at Endo-Dynamic Editor of some type. An EDE can use combinations of
EDOs to perform the real BOSS data edit. An EDE can also use any kind of graphical user interface (GUl) or other
input/output interface. An EDE includes means to dynamically interact with the EDP. An EDE includes means for dealing
1o with editing EDS's, modules, and InfoBases in a an environment where concurrent or multi- processing is possible. An
EDE includes means to maintain previous versions of modified data, so that data recovery is possible via the EDE. An
EDE includes means to interact with the restore-data and purge-data EDOs, such that a seamless ''UNDO'' can be
implemented as a combination of these EDOs and the data recovery means of the EDE itself. An EDE includes means
for displaying in ''bare mode'', where all EDl Ns are shown and regular EDS processing is not performed, optionally
15 including means to show regularly generated EDS's in separate windows as required. An EDE includes means for
human as well as process interface, so that both a human and a process can operate the EDE.
(PICTURE)BASIC BOSS CLIENTS
2O [O198] These are some basic general usages of BOSS that cover several important corner stones of computing.
Each model embodies a different process-view of an EDS. In each case, the storage formats and some required Bond
values are assumed and given. Also in each case, an SDE is supplied if applicable.
[O199] Each general model presented may be used by any number of different real application programs. The basic
boss client-models are_.
25 - Data-Traversal comprises data entry, storage, retrieval, with logical hierarchy/organization;
- Structure-Definition comprises data structure definition and usage;
- Program-Execution comprises program, procedure, parameter, variable, code, lines, etc., storage and usage (i.
e., execution);
3o - Analyze-Data comprises the function of deriving meaning and output any required actions given assumption data,
and new input.
[O2OO] Note that a DB interface is different from a program execution interface only in how it processes the data. It's
just a matter of perspective, on the same BOSS data (namely EDl Ns in various lists and orders). Even the analyze-
35 data client can express all of its required rules and data as EDl Ns (and ETS data). There is a difference between the
first three above listed clients, and the last. The first three are almost entirely composed of calls to EDOs to accomplish
their real processing. The only processing in such clients requiring additional code (to EDO-calls), is the code required
for a particular interface required by the client. All real processing can be accomplished using EDOs. This means given
an operating EDP and its required initial data, these client models can be constructed almost immediately, especially
4o in a GUl environment wherein interface construction is vastly simplified. The last client listed above requires further
code (preferably BOSS executable procedures) to perform deductive, and possibly heuristic processing. Each are of
these clients are described in ensuing subsections.
45 (PICTURE)
[O2O1] Many kinds of applications fall under this client-model. In fact, this encompasses any process which requires
data storage, retrieval, and maintenance, where data exists in some hierarchy/organization, and where such data is
then presented to a user in some depiction of the data organization. Examples of a Data-Traversal client are_.
5O - a system which maintains hierarchical data in a directory-like organization,
- a system which defines and processes data structure definitions, and
- a dynamic menu (or window) definition, traversal, processing and maintenance system.
[O2O2] Further, many BOSS clients will need to incorporate a Data-Traversal client (as well as othercode) to automate
55 the tasks of data storage, location, retrieval, and maintenance. Examples of this are_. a system which dynamically
processes (interprets) program code, and any kind of database
[O2O3] The tree 33O2 of FIG. 33A is some hierarchy of data, where, A, B, C, and E are logical entities, providing
hierarchy for data entities identified by F, G, H, l, and K. This tree 33O2 could be a directoy tree, or a menu-tree, or
24
(PICTURE)
EP O 797 8O6 B1
any other kind of tree (a tree is hierarchical by nature). Although not shown, the data organization is not limited to trees,
and any kind of graph, or other more compound data organization scheme can be used. In FIG. 33B, the leaf nodes
G, H, l, K of the tree 33O2 do not appear as Subjects in the EDS 33O4. If a process were to filter for EDl Ns with Subject
fields matching these IDs, the process would get an empty EDS for all of them. In fact, just such a process can be
5 used to determine all leaf nodes in a tree-hierarchy.
[O2O4] Bond can be used to establish EDl N-typing, and subject-attribute relations. For example in a database, the
statement_. ''Car55 is Crimson'' can be expressed as a single EDl N, as follows_.
1O [O2O5] By using SDEs, which call EDOs, simple and complex data queries can be constructed that apply to all kinds
of data for any kind of BOSS client. For example, a system which maintains a directory-like data organization, would
15 ConStrUCt SDES WhiCh Will loCate fileS and direCtorieS, While a databaSe ConStrUCtS SDES to loCate data With defined
criterions and constraints.
(PICTURE)DATA STRU TURE DEFINITION AND USAGE
_o [O2O6] When adopting a method for defining data structures, usually there are two basic types_. primitive (e.g. string,
signed 32-bit number, etc), and compound, where a structure's elements are composed of primitives and other com-
pounds. As described above, a BOSS defined record structure can have any kinds of elements whatsoever. This is
mainly because a UEl uniquely identifies an entity anywhere. The other major factor is the already discussed inter-
changeability of the source and target fields in the EDIN.
_5 [O2O7] FIG. 34 shows an example minimal rendition of BOSS oriented data structure definition. At the top of FIG.
34, two compound records, ''A'' 34O2 and ''Z'' 34O4, are shown. Record ''A'' 34O2 contains an element with data type
''Z''. Both compounds contain elements with primitive data types. At the bottom half of FIG. 34, the corresponding EDS's
34O6 and 34O8 for each record is shown. The Bond field is used to define a binary relation as in any BOSS application.
The key is what those Bonds are. In this case, Bonds describe elements of data definitions, primitive/compound data
3o types, and size.
[O2O8] The EDS shown for record ''A'' 34O6 (and record ''Z'' 34O8) would only contain all shown EDINs, if complete
structure traversal is performed. That is, all Attributes of a Subject match are themselves Subject-matched, until empty
sets are reached. At each step, EDl Ns are accumulated. Such a traversal process could be set to terminate at any
Ievel in the data hierarchy. If set to ''maximum'' or ''all levels'', the EDS 34O8 shown for record ''Z'' would be part of the
35 resultant EDS 34O6 for record ''A''.
[O2O9] In the EDS 34O6 shown for record ''A'', the Attributes of four EDl Ns with a Subject of ''A'' represent the four
elements of record ''A'' 34O2. The element-sequence field in these EDINs establishes the order of elements in the data
structure. The rest of the EDl Ns describe the characteristics of each of the elements of record ''A'' 34O2.
[O21 O] Now consider element ''B'' in record ''A'' 34O2. This element generates a total of three EDl Ns_. one with a
4o Subject of ''A'' and Attribute of ''B'', and two with a Subject of ''B''. The first signifies ''B'' as an element of ''A''; the next
two give the data type and size of element ''B''. The Attribute value shown as ''STRING'' would be a UEl value in reality.
Aside from the shown Bonds, any number of other Bond values could be implemented to provide more detailed de-
scriptions of an element (e.g. associated process, input-coordinates, display-attributes, etc).
[O211] Aside from employing a data-traversal BOSS client, the Structure-Def BOSS client uses SDEs to dynamically
45 construct and generate data structure definitions. When an element in a structure is created where the type is the bond
''call'' or ''execute'', it is a simple matter to construct an EDCL from all element EDl Ns of equal subject. The EDCL can
then be executed in the normal manner. Since the EDP is capable of executing EDCLs from anywhere and at any level
(limited by stack size), this enables BOSS defined data structures to contain processes which are executed when the
data definition is accessed, regardless of the calling process, or any other active process.
5O (PICTURE)PROGRAM STORAGE AND EXECUTION
[O212] Using EDINs, the EDP, and EDOs, it is possible to store, maintain, and execute any kind of program. As
described above, under the EDO section, a given set of EDOs can form the instruction set for a programming language,
55 when all such EDOs are also made available as bonds. A BOSS interpreted program can use the following EDl N
implementations_.
- store an EDCS for each procedure, 25
(PICTURE)
EP O 797 8O6 B1
- use a Structure-Def client model to store and process program data structures, or
- use a Data-traversal client model to save, locate and retrieve program code and data.
[O213] Since a client can also create construct and supply its own bonds and EDOs (tagged as ''user''), any missing
5 bonds/EDOs can be implemented by the client and seamlessly integrated into the BOSS environment. The new EDOs
will be processed as per all EDOs, by the EDP. Further, the associated bonds can now be used to insert new code
lines (EDCLs) into the interpreted program.
[O214] BOSS is ideally suited to interpreted programs, although it does support compiled programs as well. At a
minimum, a BOSS oriented program must contain definitions of_. data-types, variables, parameters, procedures, and
1O lines of code. If imperative programs are required, the associated module must be tagged as ''static''. This indicates
to the EDP that no EDS generation should take place and that the CNL should be loaded and taken for the EDS(s) in
question, in some order. While interpretive programs can be directly executed by the EDP, imperative programs require
a ''program execution'' system, program or shell which facilitates the execution of the imperative BOSS program. Such
a shell would construct/establish EDCL groups for the EDP, where the last EDCL in each group returns control back
15 to the shell, until all program processing is complete. Even using a static module, the normal control flow EDOs may
not operate correctly in an imperative program. This depends on whether the operator performs a change of context
or not. For example, the ''edp-pop'' EDO changes the next EDCL to be executed by the EDP, thereby changing the
context of current processing. Such EDOs almost always cause a regeneration upon successful termination, to ensure
updated data. By introducing a lot of controls in such EDOs (and complicating them), it is possible to detect an imperative
2O process, and return the parameters of would-be context change, and it's associated action(s) to the calling process.
This enables the calling process to always be in control of process flow (except for fatal errors and the like).
[O215] The program called CCOPY, shown in FIG. 35 as 35O2, performs a Conditional Copy. It has two parameters,
and two variables. It also has one procedure which is not shown; only called. The parameters of CCOPY are two UEls
to two distinct files_. Source File (SFl LE) and Target File (TFl LE). First, the program 35O2 gets the current date of each
25 input file and stores the dates in SDATE and TDATE. This is accomplished by calls to the GET-DATE program proce-
dure. This procedure is not shown, but it should be easy enough to picture it as an OS call. Finally, the program 35O2
compares the two dates and if the source file date is greater than that of the target file, it copies the source file, over-
writing the target file. Both the ''if'' and ''copy'' are accomplished by OS or shell calls (i.e., native to BOSS interface).
[O216] The EDS 36O2 shown on FIG. 36 depicts the required EDINs 36O4 to define and be able to execute, the
3O CCOPY program. The sequence field establishes an order, where a set of EDCLs are realized. To further define a
parameter or variable, the same methodology as for a Structure-Def client is used. For example, to define the SFl LE
parameter, the following two EDl Ns 36O4 could be added to the program module CNL_.
35 [O217] The SDEs can be used to dynamically generate components of the program, from the CNL. As a result, all
4o program components remain dynamic. So if a data structure changes, the processes using that structure, or data in
that structure, will immediately experience the effects ofthe change. As with anydynamic interpreted program, sufficient
safeguards must be taken to enure only changes without destructive effects take place.
(PICTURE)CONCLUSION
45 [O218] This concludes the description of the preferred embodiment of the invention. In summary,
[O219] The foregoing description of the preferred embodiment of the invention has been presented for the purposes
of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed.
Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the
5o invention be limited not by this detailed description, but rather by the claims appended hereto.
Claims
55 1 . A method for dynamically organizing and processing data in a computer having a memoy and a data storage
device coupled thereto, the method characterized by the steps of_.
(a) generating an information structure and relationship in the memory of the computer as one or more Endo-
26
EP O 797 8O6 B1
Dynamic Sets (EDS), the EDS comprising a list of one or more Endo-Dynamic Information Nodes (EDINs),
the EDl Ns each representing an atomic component of data, and the atomic component of data comprising a
subject identifier identifying a topic, an attribute identifier identifying information pertaining to the topic, and a
bond identifier defining a relationship between the subject and attribute identifiers;
5 (b) associating each bond