WO2007037710A2

WO2007037710A2 - A computational device for the management of sets

Info

Publication number: WO2007037710A2
Application number: PCT/NZ2006/000255
Authority: WO
Inventors: Suzanne Joy SULLIVAN; David Gray HUGHES; Adrian Laurence MEEKINGS; Michael James BLYTH
Original assignee: Manabars Ip Limited
Priority date: 2005-09-30
Filing date: 2006-10-02
Publication date: 2007-04-05
Also published as: WO2007037710A3; WO2007037709A1

Abstract

A data storage system or structure is provided representing a number of sets of data storage locations. Each set has a parent set identifier and contains a linked list of child storage locations. When used as a memory store with a computationally complete environment the invention provides protection against attacks from unauthorised users.

Description

A COMPUTATIONAL DEVICE FOR THE MANAGEMENT OF

SETS

FIELD OF THE INVENTION

This invention relates to Computer Science and has applications in Information and Communication Technology (ICT). The invention is particularly suited for systems that require storage and retrieval of set structures founded on Set Theory. Sets can be applied in diverse applications such as XML, filing systems, databases and mathematical constructs evaluated with computational systems.

BACKGROUND

Set Theory was developed by Gregory Cantor almost 300 years ago. It forms a foundation of mathematics and is a useful mechanism for modelling information systems. There are many versions of Set Theory, each with varying axioms that create subtly different universes with different properties. The present invention uses a unique set of axioms that are optimised for the manipulation of sets from a computational perspective. The invention allows for the storage of sets as well as managing instructions to manipulate their contents.

OBJECT OF THE INVENTION

It is an object of the invention to provide a computational device or data structure or method of manipulating data that provides advantages over known apparatus or techniques. Alternatively it is an object of the invention to provide a useful alternative to known apparatus or techniques.

SUMMARY OF THE INVENTION

In one aspect the invention provides a computational device including a data manipulation and/or storage structure representing a plurality of sets of data storage locations, each set having a parent set identifier and containing a linked list of one or more child storage locations wherein each parent set identifier references a child storage locations in the set, and wherein each child storage location can reference its parent storage location.

Preferably, each parent set identifier references a plurality of markers that each reference a single child storage location. In a preferred embodiment an interface is provided that can manipulate data storage locations by means of a marker.

Each parent set identifier may be capable of attaching primitive data structures or files.

The data manipulation may trigger events.

In another aspect the invention provides a data structure representing a plurality of sets of data storage locations, each set having a parent set identifier and containing a linked list of one or more child storage locations wherein each, parent set identifier references a child storage locations in the set, and wherein each child storage location can reference its parent storage location.

Preferably, each parent set identifier references a plurality of markers that each reference a single child storage location.

The invention can be used in conjunction with other circuits to produce useful computational processes for the manipulation of sets. The invention can be used for constructing compilers for an Interoperable Information Infrastructure model (Ill-model), storage mechanisms, educational and experimental mathematical systems. These systems can be used to deliver products and generate revenue.

INTROSPECTIVE SCOPE OF EXECUTION

The unique mathematics of the invention is derived from Set Theory to provide total protection against attack when used with a computationally complete environment that utilises the invention as its memory store. If the software is required to communicate with other software, it can perform this communication across a single set. The software is then required to take additional steps to prevent this communication from posing any risk. This mechanism is known as a Reference Membrane. Introspective scope of execution prevents software from accessing other software for which it does not contain a reference - a property exhibited from the hardware itself.

The invention has only one instruction to obtain a new reference (known as Get-Child and is described further below), which retrieves a specified Child set from within a Parent set. There is absolutely no instruction to retrieve the reference to a Parent set even though these sets may exist privately and in plurality in the. invention.

The set structure according to a preferred embodiment of the invention is referred to herein as the Manabars-Set. It provides a foundation mathematical structure that can be used as a generic container to hold any kind of information. Furthermore, the Manabars-Set is super- symmetric, meaning that there is no logical limit to the amount of data that it can hold, or the number of relationships that may exist between any sets. The mechanics of the Manabars-Set provides an efficient way of structuring information to help reduce complexity and increase productivity for developers and users of software.

The invention is an abstract design of a circuit that can be implemented in a number of ways in software, CMOS, FPGA or other exotic computational environments such as Spintronics™, Quantum Computing or biological computers.

The invention communicates with other external components via a series of buses known as the Kl-lnterface. Each Kl-lnterface bus allows the sets contained within the invention to be manipulated by an external circuit utilising the bus.

The bus operates by sending a continuous stream of instructions to the invention. Each instruction on the bus may have numerous parameters and returns.

The invention starts up with a single set known as the Powerset. By using the Kl-lnterface repeatedly, an image can be pre-installed. During implementation, the invention can be modified at several points to allow for the fast loading of pre-existing images instead of using the Kl-lnterface.

BRIEF DESCRIPTION OF THE DRAWINGS

An embodiment of the invention will be described by way of example further below with reference to the accompanying drawings, in which:

FIG. 1

FIG. 1 shows the preferred embodiment of the invention also known as the Kernel-Image. The Kernel-Image (2800) is accessed by the Kl-lnterface (2810). In this embodiment, the Kl- lnterface has 6 high priority channels (2870a-f) and 6 low priority channels (2875a-f). It also has a Backplane-Bus (2900) to allow instructions to flow between Isolated-Memory-Segments (2910a-c).

FIG. 2

FIG. 2 shows the Manabars-Set is composed of four basic structures. The Parent-Identification holds the set data, the Cursor-Identification marks the Cursor position, the Child-Identification locates the associated Parent for that Child and the Proxy-Identification is a structure to manage dynamic manipulation of the link lists.

FIG. 3

FIG. 3 shows the Parent-Identification links to the Cursor-Identification and the Child- Identification only. It contains four fields being the Leftmost-Cursor-Handle, the Rightmost- Cursor-Handle, the Leftmost-Child-Handle and the Rightmost-Child-Handle. It also contains the content associated with this Parent. In the preferred embodiment, this content contains primitives such as a 64-bit integer or a 64-bit floating-point number.

FIG. 4

FIG. 4 shows the Child-Identification is a linked list structure of Children sets that maintains ordering.

FIG. 5

FIG. 5 shows the Proxy-Identification links to the Cursor-Identification and the Child- Identification. It is useful for tracking connectivity through such instructions as the deletion of a Child from a Parent that could lead to Cursor-Identifications sharing a single Child.

FIG. 6

FIG. 6 shows the Cursor-Identification that contains the Left-Cursor-Handle and the Right- Cursor Handle that make it form part of a linked list of Cursor-Identifications inside a single Parent. The Parent-Handle-Port is able to locate the Parent-Identification of the Child to which it points. It is also able to locate the appropriate Proxy-Identification so that it can locate other Cursor-Identifications or Child-Identifications. FIG. 7

FIG. 7 shows the Cursor-Identification-Content (4000) that is used to manage the CUI-Monitor- Event (4010). It also shows the Proxy-Identification-Content (4020) that holds the Proxy-Size (4030).

FIG. 8

FIG. 8 shows the Child-ldentification-Content (4200) that holds the CHI-Monitor-Event (4210) and the Left-Index (4220).

FIG. 9

FIG. 9 shows the Parent-Identification-Content (4400) that holds the primitives that are attached to the set as well as additional indexing information.

FIG. 10

FIG. 10 shows an arbitrary Manabars-Set (4800) in a manner that highlights how the handles reference elements of the set.

FIG. 11

FIG. 11 shows a single Manabars-Set (5000) that can have 3 Monitor-Events (5100) attached at the PI-Monitor_^Event (5015), CHI-Monitor-Event (5025) and CUI-Monitor-Event (5035).

FIG. 12

FIG.13 shows a UPT-Monitor-Generator (5400) that is used to capture the state of a single Kl- lnterface method call.

FIG. 13

FIG. 13 shows the MG-Capture-lnstance (5600) that is used to assist the UPT-Monitor- Generator. FIG. 14

FIG. 14 shows a physical deployment of the Kernel-Image that includes the Kl-lnterface to enable access to the Kl-Memory via Cursor-Identifications.

FIG. 15

FIG. 15 shows the structure of a Monitor, used to trigger events.

CONVENTIONS IN FIGURES

REAL VERSUS VIRTUAL ENTITIES

Kernel-Image 320 Powerset 325

The components in the invention that are constituted directly from the host platform are known as real entities and are represented with rectangles with unbroken lines. Real entities can be either simulated in software or constructed directly in hardware as this represents all design behaviour directly attributable to the implementation platform. All rounded rectangles represent Manabars-Sets that operate as virtual entities.

EXPANSION

Some entities require further expansion within a single figure. An equivalent label (Minor 224b) and joining perspective lines are used to highlight the expanded diagram. CURSOR-IDENTIFICATION REFERENCE

A single Cursor-Identification reference can be represented with an arrow that identifies the Child to which the Cursor points.

PARENT-IDENTIFICATION REFERENCE

A single Parent-Identification reference can be represented with multiple arrows that identify all Cursor-Identifications within the Manabars-Set. The dark arrow represents the Cursor-Identification that was used to identify this Parent- Identification, while white arrows represent other Cursor-Identifications present for the shared Parent-Identification. FIELDS AND VALUES

Governance-Layer-Interface 12345

! GLI-lnstance

! 333a

Some Manabars-Sets are used as Fields that hold Values. In some instances, this Value data may not be present and is equivalent to Null in C. Value data is symbolised with a dashed line, which distinguishes it from the context or Set superstructure.

ORDERING

Parent 1 Parent 2

Child # 1 (202) 5810 5820

Child # 1 (202) Child # 2 (203) Child # 2 (202)

Children are represented from left to right or from up to down. The resulting order is the same as the symmetry of the Manabars-Set from Left to Right in the above diagrams, both Parent 1 and Parent 2 are symbolically identical.

MASKED DETAIL

To reduce visual complexity, any item may be left out if it is deemed not to be relevant to the element being represented. The only requirements are that the scope is preserved, but. any number of sets may be ignored. If A contains B and B contains C, then visually Parent A may contain Child C₁ but Parent C cannot contain Child A - not unless C contains something that contains A. In this case, the object explicitly repeats its scope and it is likely to be represented by the Repeated Scope method below.

REPEATED SCOPE

Lines join the Manabars-Sets where the scope has repeated. These are important for understanding security constraints, as the Manabars-Set only allows for introspective access. A Manabars-Set that re-introduces a distant Parent as a Child converts all the Manabars-Sets between the scopes of the 2 identical repeats into a single security access zone. PLURALITY

Node 5880

Partner-Instance 333 333 333a

Any 3 identical repeating Children represent a list of any number (x N) of identical structures.

NAMING

Governance-Layer-Interface 4320

J GLI-lnstance

1 4340

Label names are joined by dashes so that the object name can be clearly identified in a sentence such as Governance-Layer-Interface. Not all labels are objects, some are phrases that start with a Capital letter, contain no full stop and preserve the capitalisation of names. For example - Partner Node - does not use a dash as this is a phrase starting with a capital {Partner), and a capital for a name [Node). When using a name in another name, only the acronym should be used for the referenced name, for example, Governance-Layer-Interface- Instance becomes GLI-lnstance. Names retain their capitalisation through minor word changes imposed by language such as plurals in Child and Children. TYPE IDENTIFICATION

AVMI-VF-State 6270

Type = True

In some views, the Type information is highlighted at the bottom right of the Manabars-Set.

INTERFACE CONNECTIVITY

Fast-ABS Al-Module 3012 lABS-lnterface \ 13015

Communication occurring across an interface is declared with a box with a dashed line where the name ends is 'Interface'. The polarity of the interface is indicated with a (+) and (-) depending on the symmetry required. A reversed polarity means that components implement opposite calls on the interface.

DESCRIPTION OF PREFERRED EMBODIMENT

Although this invention is described by way of example and with reference to possible embodiments thereof, it is to be understood that modifications or improvements may be made thereto without departing from the scope of the invention.

An exemplary embodiment of the invention is when it operates as a memory store of sets founded on Set Theory and is likely to be housed within a more complex machine. The invention provides a dynamic container for a special variety of sets which are referred to herein as Manabars-Sets. The Manabars-Set is a mechanical structure to represent a variant of Set Theory in a computational form that is flexible enough to achieve computational completeness but yet preserve scope as inherited from Set Theory.

The Manabars-Set structure is optimised for implementation through the use of array structures, which are readily available on computing platforms with sequential addressable memory. The Manabars-Set is representative only of the idealistic set structure alone and does not include the mathematical operators such as Union and Intersection. These operators are required to be derived at another level through the use of a program and are outside the scope of the Manabars-Set.

The Manabars-Set deviates from traditional Set Theory as originally outlined by Gregory Cantor. The Manabars-Set can contain any number of Children sets and any Child can be repeated any number of times. Furthermore, Children are arranged sequentially from one pole to the other and are referred from Left to Right."

In order to enable efficient computability of the Manabars-Set, individual Children are identified through the use of an element having the ability to act as a marker or pointer, which we refer to in this document as a Cursor. A single Cursor will point to a single Child that belongs to a single Parent. A preferred embodiment of the Manabars-Set enables a system that has access to Cursor references and is not able to alter the Parents or Children directly. However, a single Parent may have any number of Cursors. The invention utilises the Kl-lnterface (2810 of FIG. 1 ) to allow alteration to the structure using the Cursor references alone. This interface will allow for the manipulation of the Manabars-Set through method calls such as shifting a Cursor to the Leftmost position (see Appendix A). A preferred embodiment of the invention would implement these method calls and alter the array structures that represent the Manabars-Set directly.

THE MANABARS-SET

The Manabars-Set (3000 of FIG. 2) is the fundamental and only data type used by the invention (2800 of FIG. 1) to store and represent all information. A unique handle identifies each Manabars-Set. Although a Manabars-Set can be thought of abstractly as a unique entity, it is actually related to other Manabars-Sets in the invention in complex ways. The structure of the Manabars-Set is made up of 4 individual structures which each have their own values and links. These structures are the Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6), the Parent- Identification (3040 of FIG. 2 and 3200 of FIG. 3), the Child-Identification (3020 Of FIG. 2 and 3400 of FIG. 4) and the Proxy-Identification (3010 of FIG. 2 and 3600 of FIG. 5). In calling methods in the Kl-lnterface (2810 of FIG. 1), all references to data must be via a unique handle (identification number) that points to a single Cursor-Identification (3030 of FIG. 2), which in turn translates to a single Manabars-Set (3000 of FIG. 2). There can be one or more Cursor- Identifications for each Manabars-Set. The references for these Cursor-Identifications are kept up to date with the use of the Proxy-Identification (3010 of FIG. 2) structure. The Manabars-Set is able to retain information for any Child-Identifications (3020 of FIG. 2) that are held inside it. There may be 0, 1 or more Children inside each Manabars-Set. Information about the overall Manabars-Set is held and referenced utilising the Parent-Identification (3040 of FIG. 2). The arrows in FIG. 2 represent what each structure is able to hold information about and how the structures link with each other.

CURSOR-IDENTIFICATION

The Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) structure is the only frame of reference that Emulator-Components can use to modify the invention (2800 of FIG. 1) through the Kl-lnterface (2810 of FIG. 1). The remaining structures of the Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3), the Proxy-Identification (3010 of FIG. 2 and 3600 of FIG. 5) and the Child-Identification (3020 of FIG. 2 and 3400 of FIG. 4) are hidden from direct access and so are perceived as a simpler entity. FIG. 10 shows 2 exemplary Manabars-Sets (4800 & 4920) that have been referenced with a Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) handle. The Cursor-Identification handle renders a simplistic view of a Manabars-Set Parent (4800 of FIG. 10) that contains any number of other Manabars-Sets that form its Children (4810 - 4860 of FIG. 10) in a chain. Only one of these Children, the Selected-Child (4840 of FIG. 10) must hold the unique position in the Manabars-Set that is pointed to by the Cursor (4890 of FIG. 10). If there are no Children, then the Cursor (4860 of FIG. 10) points to an identifier called No- Child (4930 of FIG. 10) that represents an empty set. Figure 6 shows all the fields that make up the structure of the Cursor-Identification and how they link to the other structures. These include the following:

CURSOR-PROXY-HANDLE

The Cursor-Proxy-Handle (3810 of FIG. 6 field references the Proxy-Identification (3870 of FIG. 6 and 3010 of FIG. 2) to which this Cursor-Identification belongs. PARENT-HANDLE-PORT

The Parent-Handle-Port (3820 of FIG. 6) field points to the Parent-Identification (3860 of FIG. 6 and 3040 of FIG. 2) to which this Cursor-Identification belongs. This is a mechanism for any Cursor-Identification to find the Parent-Identification that it may share with many other Cursor- Identifications. In the example in FlG. 10, it points to the Parent (4800 of FIG. 10).

LEFT-CURSOR-HANDLE AND RIGHT-CURSOR-HANDLE

The Left-Cursor-Handle (3830 of FIG. 6) and Right-Cursor-Handle (3840 of FIG. 6) fields point to adjacent Cursor-Identifications (3800 of FIG. 6 and 3030 of FIG. 2) within the shared Parent- Identification (3860 of FIG. 6 and 3040 of FIG. 2). The actual Cursor-Identification is determined by a linked list of Cursor-Identifications built by chaining from the Left-Cursor- Handle (3830 of FIG. 6) to the Right-Cursor-Handle (3840 of FIG. 6). This is used to locate the Left-Cursor (4840 of FIG. 10) and Right-Cursor (4900 FIG. 10). The chains are terminated at either end of the chain with a unique identifier called Cursor-Terminator (4950 and 4970 of FIG. 10), which differentiates it from a genuine reference to another Cursor-Identification.

CURSOR-IDENTIFICATION-CONTENT

The Cursor-Identification-Content (3890 of FIG. 6 and 4000 of FIG. 7) contains a single field - the CUI-Monitor-Event (4010 of FIG. 7).

CUI-MONITOR-EVENT

The CUI-Monitor-Event (4010 of FIG. 7 and 5035 of FIG. 11) field provides a handle to a Monitor-Event (5100 of FIG. 11) that contains Monitors (5110a - 511On of FIG. 11). These Monitors are required to be triggered with activity relating to the Cursor-Identification (3030 of FIG. 2) during the implementation of Kl-lnterface instructions.

PARENT-IDENTIFICATION

The Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) structure is a hidden frame of reference and is used internally by the Kernel-Image (2800 of FIG. 1) as a superstructure to hold references to Cursor-Identification (3030 of FIG. 2 and 3260 of FIG. 3) and Child- Identification (3020 of FlG. 2 and 3250 of FIG. 3) structures. The Parent-Identification acts as a common Parent for all Cursor-Identifications (3260 of FIG. 3 and 3030 of FIG. 2) that it holds, so it contains the shared information that represents a single Manabars-Set. The Cursor- Identification has a reference to the Parent-Identification called the Parent-Handle-Port (3270 of FIG. 3 and 3820 of FIG. 6). Figure 3 shows all the fields that make up the structure of the Parent-Identification and how they link to the other structures. These include the following:

LEFTWIOST-CURSOR-HANDLE AND RIGHTMOST-CURSOR-HANDLE

The Leftmost-Cursor-Handle (3210 of FIG. 3) and Rightmost-Cursor-Handle (3220 of FIG. 3) locates the Leftmost-Cursor-Identification (4870 of FIG. 10) and Rightmost-Cursor-Identification (4910 of FIG. 10) for this Parent-Identification (3200 of FIG. 3 and 3040 of FIG. 2). In the boundary case, where a Manabars-Set (3000 of FIG. 2) contains no Children, there is only 1 Cursor for the Parent-Identification, so the Leftmost-Cursor-Handle and the Rightmost-Cursor- Handle both use the same Cursor-Identification (4890 of FIG. 10) - even though this Cursor- Identification itself has a Child-Handle that points to No-Child instead of a genuine Child- Identification (3020 of FIG. 2).

LEFTWIOST-CHILD-HANDLE AND RIGHTWIOST-CHILD-HANDLE

The Leftmost-Child-Handle (3230 of FIG. 3) and Rightmost-Child-Handle (3240 of FIG. 3) contains the Leftmost-Child-Identification (4810 of FIG. 10) and Rightmost-Child-ldentification (4860 of FIG. 10) of a Manabars-Set (3000 of FIG. 2). In the boundary case where there are no Children in the Manabars-Set (4920 of FIG. 10), then both the Leftmost-Child-Handle and Rightmost-Child-Handle fields point to the No-Child identifier (4930 of FIG. 10) that differentiates them from their normal context where the handle would otherwise point to a genuine Child- Identification (3250 of FIG. 3 and 3020 of FIG. 2).

PARENT-IDENTIFICATION-CONTENT

The Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9) contains 15 fields listed below:

NUWIBER-OF-CHILDREN

The Number-Of-Children (4410 of FIG. 9) contains the number of unique Child-Identifications (3020 in FIG. 2) for this Parent-Identification (3040 of FIG. 2). The Child-Identifications are chained together as other Manabars-Sets in a linked list. In the example in FIG. 10, the Number-Of-Children is the total number of Children (4810 - 4860 of FIG. 10) in the arbitrary Manabars-Set (4800 of FIG. 10).

INDEX-INTEGRITY

The Index-Integrity (4430 of FIG. 9) is a boolean field holding True or False. A value of True indicates the Left-Index (4220 of FIG. 8) is correct. If the value is False, then the index should be recalculated before the result for the Get-Index is called.

RESET-INDEX

Reset-Index (4500 of FlG. 9) is a boolean field holding True or False. A value of False indicates that no change has occurred in the Parent-Identification (3040 of FIG. 2) since the last Kl-Get- Index method call. The Kernel-Image (2800 of FIG. 1) holds a reference to the last Child- Identification (3020 in FIG. 2) that had its Left-Index (4220 of FIG. 8) updated. A value of True indicates that the KI-Get-lndex call has to start again from the Leftmost-Child-ldentification held in the Leftmost-Child-Handle (3230 of FIG. 3).

NUMBER-OF-CURSORS

Number-Of-Cursors (4420 of FIG. 9) contains the number of unique Cursor-Identifications (3030 of FIG. 2) for the shared Parent-Identification (3040 of FIG. 2). Each Child may have any number of Cursors, each represented by a unique Cursor-Identification. Each Cursor- Identification may be separated by any number of Children.

PI-MONITOR-EVENT

Pi-Monitor-Event (4490 of FIG. 9 and 5015 of FlG. 11) provides a handle to a Monitor-Event (5100 of FIG. 11) that contains Monitors (5110a - 511On of FIG. 11). These Monitors are required to be triggered with activity relating to the Parent-Identification (3040 of FIG. 2) during the implementation of Kl-lnterface instructions.

WHOLE

The Whole (4440 of FIG. 9) contains a 64 Bit numerical value that does not have a decimal point. FLOAT

The Float (4450 of FIG. 9) contains a 64 Bit numerical value that includes a floating decimal point.

FAST-ABS-HANDLE

The Fast-ABS-Handle (4460 of FIG. 9) contains a unique key that is used to locate a Bit- Sequence in the Fast-ABS.

SLOW-ABS-HANDLE

The Slow-ABS-Handle (4470 of FIG. 9) contains a unique key that is used to locate a Bit- Sequence in the Slow-ABS.

TYPE

The Type (4480 of FIG. 9) contains a Whole number that identifies the Type of the Manabars- Set.

NUMBER-OF-INSERTS

The Number-Of-lnserts (4510 of FIG. 9) contains a Whole number that identifies how many times this Parent-Identification is inserted as a Child inside another Manabars-Set (3000 of FIG. 2).

WHOLE-HASHKEY

The Whole-Hashkey (4520 of FIG. 9) contains a Whole number that is used as a unique identifier based on the Whole values of all the Children of the Manabars-Set (3000 of FIG. 2). Any one of many algorithms may be used for determining the Whole-Hashkey.

FLOAT-HASHKEY

The Float-Hashkey (4520 of FIG. 9) contains a Whole number that is used as a unique identifier based on the Float values of all the Children of the Manabars-Set (3000 of FIG. 2). Any one of many algorithms may be used for determining the Float-Hashkey. FAST-ABS-HASHKEY

The Fast-ABS-Hashkey (4520 of FIG. 9) contains a Whole number that is used as a unique identifier based on the Fast-ABS-Handles of all the Children of the Manabars-Set (3000 of FIG. 2). Any one of many algorithms may be used for determining the Fast-ABS-Hashkey.

SLOW-ABS-HASHKEY

The Slow-ABS-Hashkey (4520 of FIG. 9) contains a Whole number that is used as a unique identifier based on the Slow-ABS-Handles of all the Children of the Manabars-Set (3000 of FIG. 2). Any one of many algorithms may be used for determining the Slow-ABS-Hashkey.

CHILD-IDENTIFICATION

The Child-Identification (3020 Of FIG. 2 and 3400 of FIG. 4) structure forms a linked list of Manabars-Sets (3000 of FIG. 2) that are all Children of a common Parent-Identification (3450 of FIG. 4 and 3040 of FIG. 2). The linked list is terminated on either end when the Left-Child- Handle (3410 of FIG. 4) and the Right-Child-Handle (3420 of FIG. 4) equals the No-Child identifier.

LEFT-CHILD-HANDLE AND RIGHT-CHILD-HANDLE

The Left-Child-Handle (3410 of FIG. 4) and Right-Child-Handle (3420 of FIG. 4) provides references to the adjacent Child-Identifications (3400 of FIG. 4 and 3020 of FIG. 2) that are the Left-Child-ldentification (4830 of FIG. 10) and Right-Child-ldentification (4850 of FIG. 10) that create a linked list of Children Manabars-Sets (3000 of FIG. 2) for this Parent-Identification (3450 of FIG. 4 and 3040 of FIG. 2).

CHILD-PROXY-HANDLE

The Child-Proxy-Handle (3430 of FIG. 4) provides a handle to a Proxy-Identification (3480 of FIG. 4 and 3010 of FIG. 2) that contains all the Cursor-Identifications (3490 of FIG. 4 and 3030 of FIG. 2) that are currently pointing to the Child-Identification (3400 of FIG. 4). If there are no Cursor-Identifications currently pointing to the Child-Identification then the Child-Proxy-Handle will point to a No-Proxy identifier that differentiates it from a genuine reference to another Proxy- Identification. PARENT-HANDLE-STARBOARD

The Parent-Handle-Starboard (3440 of FIG. 4) provides a handle to the Cursor-Identification (3490 of FIG. 4 and 3030 of FIG. 2) to which this Child-Identification (3400 of FIG. 4) refers.

CHILD-IDENTIFICATION-CONTENT

The Child-Identification-Content (3445 of FIG. 4 and 4200 of FIG. 8) contains 2 fields listed beiow:

CHI-MONITOR-EVENT

The CHI-Monitor-Event (4210 of FIG. 8 and 5025 of FIG. 11) provides a handle to a Monitor- Event (5100 of FIG. 11) that contains Monitors (5110a - 5110n of FIG. 11). These Monitors are required to be triggered with activity relating to the Child-Identification (3020 of FIG. 2) during the implementation of Kl-lnterface instructions.

LEFT-INDEX

The Left-Index (4220 of FIG. 8) field holds the last known index that the Cursor occupies from the Leftmost Manabars-Set (3000 of FIG. 2). The Right-Index is the last known index that the Cursor occupies from the Rightmost Manabars-Set and is calculated through subtracting the Left-Index from the Number-of-Children (4410 of FlG. 9). The integrity of these indexes should be checked with the Index-Integrity field (4430 of FIG. 9). If False, the indexes should be recalculated before use with the Get-Index method.

PROXY-IDENTIFICATION

The Proxy-Identification (3010 of FIG. 2 and 3600 of FIG. 5) structure forms a linked list of Cursor-Identifications (3650 of FIG. 5 and 3030 of FIG. 2) that are currently pointing to a Child- Identification (3670 of FIG. 5 and 3020 of FIG. 2). There are 2 types of Proxy-Identification - a Main and a Sublevel Proxy-Identification. This is because there may be more than one Proxy- Identification referencing a Child-Identification but the Child-Identification can only reference one Proxy-Identification. The Main and the Sublevel Proxy-Identifications (3600 of FIG. 5) are distinguished through the Proxy-Handle (3620 of FIG. 5). A Main Proxy-Identification holds an identifier of No-Proxy in the Proxy-Handle. If the Proxy-Handle holds a reference to another Proxy-Identification then it is considered to be a Sublevel Proxy-Identification. The Main Proxy- Identification fields are kept up to date after each Kl-lnterface method call, while the Sublevel Proxy-Identification fields are not always reliable with the exception of the Proxy-Handle (3620 of FIG. 5). In an optimised configuration a background process may synchronise the Main and Sublevel-Proxy-ldentifications on a regular basis.

PROXY-CHILD-HANDLE

The Proxy-Child-Handie (3610 of FIG. 5) field holds the handle to the Child-Identification (3670 of FIG. 5 and 3020 of FIG. 2) that is pointed to by all of the Cursor-Identifications (3650 of FIG. 5) inside the Proxy and represents the Selected-Child (4840 of FIG. 10). If the Manabars-Set is empty, the Proxy-Child-Handle should hold the state of No-Child, differentiating it from an actual handle to a genuine Child-Identification.

PROXY- HANDLE

The Proxy-Handle (3620 of FIG. 5) field is utilised when there is more than one Proxy currently referencing the same Child-Identification (3670 of FIG. 5 and 3020 of FIG. 2). This would happen in the event of Delete-Child Kl-lnterface method call, or an Insert-Child Kl-lnterface method call in the situation of a number of Cursor-Identifications (3650 of FIG. 5 and 3030 of FIG. 2) shifting over to reference another Child-Identification (3670 of FIG. 5) at the same time. In this situation the Main Proxy-Identification (3600 of FIG. 5) currently pointing to the new Child-Identification has its Proxy-Handle (3620 of FIG. 5) updated to reference the Proxy- Identification that is being moved, thereby becoming a Sublevel Proxy-Identification, and the Proxy-Identification that is being moved will become the Main Proxy-Identification referenced by the new Child-Identification.

PROXY-LEFTMOST-CURSOR-HANDLE AND PROXY-RIGHTMOST-CURSOR-HANDLE

The Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) and Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) locates the first and last Cursor-Identifications (3660 of FIG. 5 and 3030 of FIG. 2) that are inside the Proxy. All Cursors in between the first and last Cursors can be found using the Left-Cursor-Handle (3830 of FIG. 6) and Right-Cursor-Handle (3840 of FIG. 6) of the Cursor-Identification. Any Sublevel Proxy-Identifications (3600 of FIG. 5) are considered to be part of the Main Proxy-Identification, in which case the Proxy-Leftmost-Cursor-Handle or the Proxy-Rightmost-Cursor-Handle of the Main Proxy-Identification may be referencing a Cursor- Identification that is residing in a Sublevel Proxy-Identification. PROXY-IDENTIFICATION-CONTENT -

The Proxy-Identification-Content (3615 of FIG. 5) contains a single field - the Proxy-Size.

PROXY-SIZE

The Proxy-Size (4030 of FIG. 7) holds the amount of Cursor-Identifications (3660 of FIG. 5 and 3030 of FIG. 2) currently referencing the same Proxy-Identification (3600 of FIG. 5). Any Sublevel Proxy-Identifications are considered to be part of the Main Proxy-Identification, which means that the Proxy-Size of the Main Proxy-Identification includes all the sizes of any Sublevel Proxy-Identifications. If a Cursor-Identification (3660 of FIG. 5) is shifted into, or out of the Main Proxy-Identification or any of its Sublevel Proxy-Identifications then only the size of the Main Proxy-Identification is updated.

KERNEL-IMAGE

The invention in the embodiment described is implemented in a module known as the Kernel- lmage(2800 of FIG. 1), hence the term "Kernel-Image" is also used in this document to refer generally to the invention. The invention may act as a central repository for information by other devices. Every Manabars-Set (3000 of FIG. 2) is stored within the invention. The outermost Manabars-Set is known as the Powerset. Manabars-Sets can only be accessed through the Kl- lnterface (2810 of FIG. 1), so other Emulator-Components can't access the KI-Memory (2610 of FIG. 14) directly. All handles to manipulate Manabars-Sets are of the type Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6), whilst handles to the Parent-Identification (3040 of FIG. 2 and 3200 of FlG. 3), Proxy-Identification (3010 Of FIG. 2 and 3600 of FIG. 5) and Child- Identification (3020 Of FIG. 2 and 3400 of FIG. 4) are protected behind the Kl-lnterface.

KI-MEMORY

The KI-Memory (2610 of FIG. 14) is used to store every Manabars-Set (3000 of FIG. 2) within the Kernel-Image (2800 of FIG. 1). It is likely that the implementers of the invention may use arrays to represent every field in the Parent-Identification (3040 of FIG. 2), the Cursor- Identification (3030 of FIG. 2), the Child-Identification (3020 of FIG. 2) and the Proxy- Identification (3010 of FIG. 2). The KI-Memory is the primary memory system in the Emulator. KI-INTERFACE

The Kl-lnterface (2810 of FIG. 1) is the only conduit through which Emulator-Components can access the KI-Memory (2610 of FIG. 14). The Kl-lnterface should allow any number of methods to be called in parallel, provided that they do not utilise any identical Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) handles and they don't share a common Parent. For each parallel access that may be required for a specific implementation of the Emulator, a separate Channel (2870a - 287Of and 2875a - 2875f of FIG. 1) is required. There are two types of Channels (1) High-Priority-Channels (2870a - 287Of of FIG. 1) and (2) Low-Priority-Channels (2875a - 2875f of FIG. 1). Requests entering a Low-Priority-Channel must wait until there are no more requests entering any High-Priority-Channel. It is beyond the scope of this patent to define the configuration of Channels during the implementation, as there are many valid configurations that are likely to be determined by the relative power rating of the other Emulator-Components. Figure 16 shows a minimal implementation where a single High-Priority-Channel (2625a of FIG. 14) is used to service all the requests. FIG. 1 shows the Kl-lnterface configuration that is optimised for silicon, having 6 High-Priority-Channels and 6 Low-Priority-Channels. Each Channel acts as a parallel interface to the KI-Memory (2610 of FIG. 14) that conforms to the Kl- lnterface and each will be blocked by the Request-Blocker (2890a - 289Of & 2895a - 2895f of FIG. 1) if it is already busy with a request. If multiple requests are made, the Request-Blocker should queue these. Each Channel may have its own Implementation-Logic (2880a - 288Of and 2885a - 2885f of FIG. 1), so that requests may be processed in parallel. The minimal implementation is a single Implementation-Logic unit (2627 of FIG. 14) that services High- Priority-Channel requests before Low-Priority-Channel requests.

In some implementations, the KI-Memory (2610 of FIG. 14) may not allow absolute parallel access for all the Implementation-Logic (2627 of FIG. 14) components. In this case, these Request-Blockers (2626a of FIG. 14) for the High-Priority-Channels (2625a of FIG. 14) should each rotate in their own round robins. Since a Channel may constantly be utilised, failure to service all Channels in a statistically equivalent manner could lead to the disruption of the devices the invention supports. Specifically, in the optimised configuration of FIG. 1 this could be avoided through the following rotation sequence: 2890a - 2890b - 2890c - 289Od - 289Oe - 289Of - 2890a. However, any statistically equivalent distribution is acceptable.

The Implementation-Logic translates methods directly into implementation specific low-level memory requests by using Implementation-Level-Access (2680 of FIG. 14). The Implementation-Logic therefore has direct access to arrays to build the set structures, which are efficient and readily available on the von Neumann architecture. The Arrays and Counters are beyond the scope of the patent because the behavioural specification of the Manabars-Set (3000 of FIG. 2) is already defined and the implementation may vary.

IMPLEMENTATION-LOGIC

FIG. 14 shows the invention (2600 of FIG. 14) acting as a centralised memory model. Emulator-Components do not have direct access to the Kl-Memory (2610 of FIG. 14), but manipulate data with handles and methods via the Kl-lnterface (2685 of FIG. 14 and 2810 of FIG. 1).

The Kl-lnterface seamlessly passes method calls to the Implementation-Logic (2880a - 288Of & 2885a - 2885f of FlG. 1). In a typical Object Orientated deployment, the Implementation-Logic is likely to be a series of methods calls within a single Kl-lnterface object. In a software implementation, there is little need to repeat the Implementation-Logic as memory is shared between processes and repeating code does not speed up execution because more threads have to compete for a fixed computational resource in a conventional von Neumann hardware deployment.

The Implementation-Logic is required to check for any attached to Manabars-Sets (3000 of FIG. 2) that are affected directly and indirectly by any Kl-lnterface (2620 of FIG. 14) method calls. A compulsory parameter for each method call identifies the stack that will contain the UPT- Monitor-Generator (5400 of FIG. 12). This stack is to contain instructions that provide a computationally complete platform and is provided by devices that utilise this invention. If this parameter is set to the value No-Stack then all Monitors attached to the Manabars-Set are ignored. See the Monitors section for a complete explanation of how Monitors are triggered. Also refer to Appendix A for a full list of Kl-lnterface methods and the Monitors that may be triggered through each Kl-lnterface method call.

DEFRAGMENTER

The Defragmenter (2640 of FIG. 14) is an implementation specific component and so is beyond the scope of this patent. For example, the implementers may choose to maintain a list of every available Cursor-Identification (3030 of FlG. 2), Child-Identification (3020 of FIG. 2) and Parent- Identification (3040 of FIG. 2) so that the entire defragmentation process is irrelevant. Alternatively, the implementers may choose to confine all the utilised memory structures within tracked zones of indexes. Defragmentation would then be used to shrink these zones when elements inside them were deleted. The Defragmenter may receive events from the Kl-Memory (2610 of FIG. 14) that may assist in the defragmentation process. ..

The Defragmenter has Implementation-Level-Access (2680 of FIG. 14), so it modifies the Kl- Memory structures directly.

ASYNCHRONOUS-GARBAGE-COLLECTOR

The Asynchronous-Garbage-Collector (2630 of FIG. 14) is an implementation specific component. It is responsible for freeing up unused memory that occurs during a Delete-Child Kl-lnterface method call or Insert-Child Kl-lnterface method call with an Action-Polarity set to Type-Neutral. These Kl-lnterface calls are guaranteed to free up memory associated with Child-Identifications, however, the memory associated with the Cursor-Identification and its shared Parent-Identification can only be deleted if there are exactly zero references utilising it. This Emulator-Component is tightly related to the Defragmenter and it is expected that they may work together to manage the Kl-Memory (2610 of FIG. 13).

MONITORS

Monitors (Refer Appendices B and C) provide a mechanism whereby software executing in the Kernel-Image (2800 of FIG. 1) can be made aware of changes to other Children. There are three different main Types of Monitor:

CUI-Monitors: These Monitors are concerned with any changes to the Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) such as the Cursor shifting to a different Child. These Monitors are stored in the CUI-Monitor-Event (4010 of FIG. 7 and 5035 of FIG. 11) of the Cursor-Identification-Content (3890 of FIG. 6 and 4000 of FIG. 7).

Pi-Monitors: These Monitors are concerned with any changes to the Parent-Identification (3040 of FIG. 2 and 3600 of FIG. 5) such as a Child being inserted or deleted, or the Whole (4440 of FIG. 9) or Float (4450 of FIG. 9) being altered. These Monitors are stored in the Pl-Monitor- Event (4490 of FIG. 9 and 5015 of FIG. 11) of the Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9).

CHI-Monitors: These Monitors are concerned with any changes to the Child-Identification (3020 of FIG. 2 and 3400 of FlG. 4) such as a Child being inserted to the Left or Right of the Child being monitored. These Monitors are stored in the CHI-Monitor-Event (4210 of FIG. 8 and 5025 of FIG. 11) of the-Child-ldentification-Content (3445 of FIG. 4 and 4200 of FIG. 8).

For a full list of Monitors, their Types and their Parameters see Appendix B. Monitors (5110a - 511On of FIG. 11 and FIG. 15) are added to a Monitor-Event (5100 of FIG. 11) through the Kl- Add-Monitor method (refer Appendix A). The parameters for this method call are the Monitor that is to be added and the Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) used to locate the Monitor-Event, Each Monitor has a unique Type (4480 of FIG. 9) that is used to identify whether the Monitor belongs in a Pi-Monitor-Event (4490 of FIG. 9 and 5015 of FIG. 11), CUI-Monitor-Event (4010 of FIG. 7 and 5035 of FIG. 11) or a CHI-Monitor-Event (4210 of FIG. 8 and 5025 of FIG. 11). A Monitor-Event (5100 of FIG. 11) is a Child with no specific Type, which is essentially a list of Monitors (5110a - 511On of FIG. 11 and FIG. 15) that identify specific events that require triggering. Events are triggered from within the Implementation-Logic (2880a - 288Of and 2885a - 2885f of FIG. 1) that processes instructions for the Kl-lnterface (2810 of FIG. 1). A single instruction processed by the Implementation-Logic may trigger a number of Monitors. See appendix A for all Monitors triggered through each Kl-lnterface method call. The CUI-Monitor-Event (4010 of FIG. 7 and 5035 of FIG. 1 1), Pi-Monitor-Event (4490 of FIG. 9 and 5015 of FIG. 11) and CHI-Monitor-Event (4210 of FIG. 8 and 5025 of FIG. 11) must be searched to locate the Monitors (5110a - 5110n of FIG. 11 and FIG. 15) that are to be triggered. This may take an unknown amount of time and therefore cannot be processed through the Implementation-Logic. Therefore during the processing of each instruction, the Implementation-Logic creates (see below for further explanation) an UPT-Monitor-Generator (5400 of FIG. 12), which holds all the relevant parameters for each event that has occurred that may trigger a Monitor. These parameters are known as MG-Capture-lnstances (5445 of FIG. 12 and 5600 of FIG. 13). All Monitor-Events that may hold Monitors that require triggering are also included in the UPT-Monitor-Generator. These Monitor-Events are:

The CUI-Monitor-Event (4010 of FIG. 7 and 5505 of FIG. 12) of the Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) used in the Kl-lnterface call. This Monitor-Event is inserted into the Cursor-Monitor-Field (5500 of FIG. 12).

The Pi-Monitor-Event (4490 of FIG. 9 and 5455 of FIG. 12) of the Parent-Identification (3040 of FIG. 2 and 3600 of FIG. 5) connected to the Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6). This Monitor-Event is inserted into the Parent-Monitor-Field (5450 of FIG. 12). The CHI-Monitor-Event (4210 of FIG. 8 and 5465 of FIG. 12) of the Child that the Cursor- Identification (3030 of FIG. 2 and 3800 of FIG. 6) is currently pointing to. This Monitor-Event is inserted into the Current-Child-Monitor-Field (5460 of FIG. 12). The CHI-Monitor-Event (4210 of FIG. 8 and 5475 of FIG. 12) of the Child to the Left of the Child that the Cursor-Identification (3030 of FIG. 2 and 3800. of FIG. 6) is currently pointing to. This Monitor-Event is inserted into the Left-Child-Monitor-Field (5470 of FIG. 12). The CHI-Monitor-Event (4210 of FIG. 8 and 5485 of FIG. 12) of the Child to the Right of the Child that the Cursor-ldentifipation (3030 of FIG. 2 and 3800 of FIG. 6) is currently pointing to. This Monitor-Event is inserted into the Right-Child-Monitor-Field (5480 of FIG. 12). The CHI-Monitor-Event (4210 of FIG. 8 and 5495 of FIG. 12) of the new Child that the Cursor- Identification (3030 of FIG. 2 and 3800 of FIG. 6) is pointing to. This Monitor-Event is inserted into the New-Child-Monitor-Fieid (5490 of FIG. 12).

In deploying the invention, a computationally complete environment is required to process instructions from a stack, all comprised of Manabars-Sets. The UPT-Monitor-Generator (5400 of FIG. 12) is then inserted into the Leftmost position of the Stack provided as a compulsory call parameter for every Kl-lnterface method - providing that the Stack itself is non-null. Monitor behaviour should be ignored for the Kl-lnterface call, if the Stack is null. The UPT-Monitor- Generator is subsequently executed repeatedly inside the appropriate Stack until all the relevant Monitors have been processed. However the full details of how the UPT-Monitor-Generator is executed and how the Monitor is subsequently processed is beyond the scope of this document.

The Kl-Add-Monitor method call returns a key that is used to locate the specific Monitor (5110a -511On of FIG. 11) within the Monitor-Event (5100 of FIG. 11). This key is subsequently used to remove the Monitor from the Monitor-Event through the Kl-Remove-Monitor method call. All Monitors are transient and therefore all Monitor-Events are removed from the Manabars-Set on Shutdown of the invention.

Where in the foregoing description reference has been made to specific components or integers of the invention having known equivalents then such equivalents are herein incorporated as if individually set forth.

APPENDIX A

Kl -interface Methods

Each Kl-lnterface methods is defined in a single table with the following fields.

-4

APPENDIX A

Kl-Add-Monitor

Case 1

Occurrence There is no Monitor-Event attached to the CHI-Monitor-Event, Pi-Monitor-Event or CUI-Monitor-Event.

Deviated Behaviour Create new Monitor-Event and update the CHI-Monitor-Event, Pi-Monitor-Event or CUI-Monitor-Event (depending on the Type of the Monitor) to reference the newly created Monitor-Event.

Fields Altered CHI-Monitor-Event of the Current-Child-Identification, Pi-Monitor-Event of the Parent-Identification or CUI-Monitor-

APPENDIX A

Event of the Cursor-Identification (input (1)) - depending on the Type of the Monitor.

Monitors None

Kl -Broadcast

Kl-Create-Manabars-Set

APPENDIXA

2

Kl-Delete-Child

APPENDIX A

Next-Proxy: (Able to be No-Proxy) The main Proxy-Identification (3010 of FIG. 2 and 3870 of FIG. 6) found through the Child-Proxy-Handle (3430 of FIG. 4) of the Next-Child.

Left-Child: (Able to be No-Child) The Child to the Left of the Child to be deleted (Current-Child) found through the Left-Child-Handle (3410 of FIG. 4) of the Current-Child.

Right-Child: (Able to be No-Child) The Child to the Right of the Child to be deleted (Current-Child) found through the Right-Child-Handle (3420 of FIG. 4) of the Current-Child.

Parent-Identification: Found through the Parent-Handle-Port (3820 of FIG. 6) of the Cursor-Identification (input 1).

Generic Behaviour This method functionally deletes the Child currently pointed to by the Cursor in input (1).

Step 1: The Left-Child-Handle (3410 of FIG. 4) of the Right-Child and the Right-Child-Handle (3420 of FIG. 4) of Left-Child are updated to reference each other. Check for the following monitors: CHI-Monitor-Child-Deletes-Left for the Right-Child, CHI-Monitor-Child-DeletesrRight forthe Left-Child.

Step 2: Update the Proxy-Handle (3620 of FIG. 5) of the Next-Proxy to reference the Current-Proxy. Depending w on the Action-Polarity (input (2)) update the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) or the Proxy- Rightmost-Cursor-Handle (3640 of FIG. 5) of the Current Proxy to equal the Proxy-Leftmost-Cursor-Handle or the Proxy-Rightmost-Cursor-Handle of the Next-Proxy. Add the Proxy-Size (4030 of FIG. 7) found in the Proxy- Identification-Content (3615 of FIG. 5 and 4020 of FIG. 7) of the Next-Proxy to the Proxy-Size of the Current-Proxy. Update the Proxy-Child-Handle (3610 of FIG. 5) of the Next-Proxy to reference No-Child.

Step 3: Update the Proxy-Child-Handle (3610 of FIG. 5) of the Current-Proxy to reference the Next-Child. Update the Child-Proxy-Handle (3430 of FIG. 4) of the Next-Child to reference the Current-Proxy. Update the Child-Proxy- Handle of the Current-Child to reference No-Proxy.

Step 4: If the Index-Integrity (4430 of FIG. 9) found in the Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9) of the Parent-Identification is currently set to True then set it to False, and check for the Pl-Monitor-Bad- Index for the Parent-Identification. Calculate and update the new values for the Whole-Hashkey (4520 of FIG. 9), Float-Hashkey (4530 of FIG. 9), Fast-ABS-Hashkey (4540 of FIG. 9) and Slow-ABS-Hashkey (4550 of FIG. 9) of the Parent-identification-Content.

Step 5: The Asynchronόus-Garbage-Collector (2630 of FIG. 13) is informed of the released Child-Identification (3020 of FIG. 2 and 3400 of FIG. 4) and the Number-Of-Children (4410 of FIG. 9) found in the Parent-ldentification-

APPENDIXA

K

Case 2

Occurrence In the boundary case where the Child being deleted is on the Left or Right boundary

Deviated Behaviour Step 1 - Child on Left Boundary: The Left-Child-Handle (3410 of FIG. 4) of the Right-Child is updated to reference No-Child. The Leftmost-Child-Handle (3460 of FIG. 4 and 3230 of FIG. 3) of the Parent-Identification is updated to reference the Right-Child. Check for the following monitors: CHI-Monitor-Child-Deletes-Left and CHI- Monitor-Child-Terminate-Left for the Right-Child and Pl-Monitor-Leftmost for the Parent-Identification.

Step 1: - Child on Right Boundary: The Right-Child-Handle (3420 of FIG. 4) of the Left-Child is updated to reference No-Child. The Rightmost-Child-Handle (3470 of FIG. 4 and 3240 of FIG. 3) of the Parent-Identification is

APPENDIXA

APPENDIXA

KI-Get-Adjacent-Cursor-ldentification

APPENDIXA

Fields Altered None

Monitors CUI-Monitor-Cursor-Retrieved (for the Left-Cursor or Right-Cursor (dependent on Action-Polarity (input (2)))

Case 1

Occurrence If the Left-Cursor when input (2) is Left or the Right-Cursor when input (2) is Right is set to Cursor-Terminator

Deviated Behaviour Step 1:The method returns the Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) equal to input (1) because there are no more Cursor-Identifications in the direction specified. Check for the CUI-Monitor-Cursor- Retrieved.

Fields Altered None

Monitors CUI-Monitor-Cursor-Retrieved (for the Left-Cursor or Right-Cursor (dependent on Polarity (input (2)) of input (1))

KI-Get-Boundary-Cursor-ldentification

Ul

APPENDIX A

Kl-Get-Child

KI-Get-Fast-ABS-Handle

APPENDIXA

KI-Get-Fast-ABS-Hashkey

-4

APPENDIXA

Kl-Get-Float-Hashkey

APPENDIX A

KI-Get-lndex

S

Case 1

Occurrence The Index-Integrity of the Parent-Handle-Port of input (1) is set to false

Deviated Behaviour Step 1 : Locate the Leftmost-Child-Handle (3230 of FIG. 3) of the Parent-Identification and set its Left-Index (4220 of FIG. 8) found in the Child-Identification-Content (3445 of FIG. 4 and 4200 of FIG. 8) of the Child-Identification to 1.

Step 2: Find the next Child through the Right-Child-Handle (3420 of FIG. 4) of the last Child; increase the number of the Left-Index (4220 of FIG. 8) and set the next Child's Left-Index. Repeat Step 2 until all Children have been updated.

APPENDIXA

Kl-Get-Number-Children

Inputs (1) A Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) that locates the shared Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) for which the number of Children is requested

Outputs The number of Children for the identified Parent-Identification.

References set up at Parent-Identification: Found through the Parent-Handle-Port (3820 of FIG. 6) of the Cursor-Identification of input the start in

Generic Behaviour This method returns the number of Children that all share the same Parent as input (1).

Step 1 : Check for and trigger the Pi-Monitor-Number-Children-Queried. Return the Number-Of-Children (4410 of S FIG. 9) found within the Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9) of the Parent- Identification.

Fields Altered None

Monitors Pl-Monitor-Number-Children-Queried

Kl-Get-Number-Cursors

Inputs (1) A Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) that locates the shared Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) for which the number of Cursor-Identifications is requested.

Outputs The number of Cursors for the identified Parent-Identification.

References set up at Parent-Identification: Found through the Parent-Handle-Port (3820 of FIG. 6) of the Cursor-Identification of input the start

Generic Behaviour m This method returns the number of Cursors each represented by a unique Cursor-Identification that all share the same Parent as input (1).

APPENDIXA

KI-Get-Number-Sharing-Cursor-ldentifications

KI-Get-Parent-ldentification

APPENDIXA

Step i : Locate and return the Parent-Handle-Port (3270 of FIG. 3 and 3820 of FIG. 6) of input (1).

Fields Altered None

Monitors None

Kl-Get-Powerset

KI-Get-Slow-ABS-Handle

APPENDIXA

KI-Get-Siow-ABS-Hashkey

W

APPENDIXA

Kl-Get-Whole

APPENDIX A

KI-lnsert-And-Spawn

Kl-lnsert-Child

APPENDIX A

Action-Trilarity is Neutral or Left then the Left-Child is found through the Left-Child-Handle (3410 of FIG. 4) of the Current-Child. Otherwise if the Action-Trilarity is Right then the Left-Child is the same as the Child identified by the Cursor.

Right-Child: (Able to be No-Child) The Child that will be to the right of the Child to be inserted (New-Child) if the Action-Trilarity is neutral or right then the Right-Child is found through the Right-Child-Handle (3420 of FIG. 4) of the Current-Child. Otherwise if the Action-Trilarity is Left then the Right-Child is the same as the Child identified by the Cursor.

Old-Left-Cursor: (Able to be Cursor-Terminator) Found through the Left-Cursor-Handle (3830 of FIG. 6) of the Cursor-Identification (input (1)).

Old-Right-Cursor: (Able to be Cursor-Terminator) Found through the Right-Cursor-Handle (3840 of FIG. 6) of the Cursor-Identification (input (1)).

Generic Behaviour This method functionally inserts the source Child into the destination location without modifying the source Cursor- Identification so that the method replicates a reference. c

\

Step 1: Create a new Child-Identification (3020 of FIG. 2 and 3400 of FIG. 4) and set the Parent-Handle-Starboard (3440 of FIG. 4) to reference the Cursor-Identification (3030 of FIG. 2 and 3800 of FlG. 6) of input (2). The CHI- Monitor-Event (4210 of FIG. 8), found in the Child-Identification-Content (3445 of FIG. 4 and 4200 of FIG. 8) of the New-Child, will be set to No-Monitor-Event.

Step 2: The Left-Index (4220 of FlG. 8) found in the Child-ldentification-Content (3445 of FIG. 4 and 4200 of FIG. 8) of the New-Child will be set to 0. If the Index-Integrity (4430 of FIG. 9) found in the Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9) of the Parent-Identification is true then set it to false and check for the Pl- Monitor-Bad-Index for the Parent-Identification.

Step 3: Update the Right-Child-Handle (3420 of FIG. 4) of the New-Child to reference the Right-Child, and the Left- Child-Handle (3410 of FIG. 4) of the New-Child to reference the Left-Child. Update the Left-Child-Handle of the Right-Child and the Right-Child-Handle of the Left-Child to reference the New-Child. Increase the Number-Of- Children (4410 of FIG. 9) found in the Parent-Identification-Content (3225 of FIG. 3 and 4400 of FIG. 9) of the Parent-Identification. Check for the CHI-Monitor-Child-lnserts-Left for the Right-Child, CHI-Monitor-Child-lnserts- Rightfor the Left-Child, and Pi-Monitor-Inserts-Child for the Parent-Identification.

APPENDIXA

Step 4: Update the Left-Cursor-Handle (3830 of FIG. 6) of the Old-Right-Cursor and the Right-Cursor-Handle (3840 of FIG. 6) of the Old-Left-Cursor to reference each other.

Step 5a: If the Action-Trilarity (input (3)) is Left: Locate the New-Right-Cursor found through the Proxy-Leftmost- Cursor-Handle (3630 of FIG. 5) of the Current-Proxy. Locate the New-Left-Cursor through the Left-Cursor-Handle (3830 of FIG. 6) of the New-Right-Cursor.

Step 5b: If the Action-Trilarity (input (3)) is Right: Locate the New-Left-Cursor found through the Proxy-Rightmost- Cursor-Handle (3640 of FIG. 5) of the Current-Proxy. Locate the New-Right-Cursor through the Right-Cursor- Handle (3840 of FIG. 6) of the New-Left-Cursor.

Step 5: Update the Right-Cursor-Handle and the Left-Cursor-Handle of the Cursor-Identification (input (1)) to reference the New-Left-Cursor and the New-Right-Cursor. Update the Right-Cursor-Handle (3840 of FIG. 6) of the New-Left-Cursor and the Left-Cursor-Handle (3830 of FIG. 6) of the New-Right-Cursor to reference the Cursor- Identification (input (1)).

Step 6: Create a new Proxy-Identification (3010 of FIG. 2 and 3600 of FIG. 5) and update the Cursor-Proxy-Handle 4- -4 (3810 of FIG. 6) of the Cursor-Identification (input (1)) and the Child-Proxy-Handle (3430 of FIG. 4) of the New- Child to reference the new Proxy-Identification. Update the Proxy-Child-Handle (3500 of FIG. 4 and 3610 of FIG. 5) of the new Proxy-Identification to reference the New-Child. Update the Proxy-Handle (3620 of FIG. 5) of the new Proxy-Identification to reference no-Proxy. Update the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) and the Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) of the new Proxy-Identification to reference the Cursor- Identification (input (1)). Update the Proxy-Size (4030 of FIG. 7) found in the Proxy-Identification-Content (3615 of FIG. 5 and 4020 of FIG. 7) of the new Proxy-Identification to equal 1. Check for the CHI-Monitor-Cursor- Identification-Shifted-Off-Child for the Current-Child.

Step 7: Calculate and update the new values for the Whole-Hashkey (4520 of FIG. 9), Float-Hashkey (4530 of FIG. 9), Fast-ABS-Hashkey (4540 of FIG. 9) and Slow-ABS-Hashkey (4550 of FIG. 9) of the Parent-Identification- Content.

Fields Altered Parent-Handle-Starboard (of the New-Child), Left-Index (of the New-Child), Index-Integrity (of the Parent- Identification), Right-Child-Handle and the Left-Child-Handle (of the New-Child), Left-Child-Handle (of the Right- Child) and the Right-Child-Handle of the (Left-Child), Number-Of-Children (of the Parent-Identification), Left- Cursor-Handle (of the Old-Right-Cursor), Right-Cursor-Handle (of the Old-Left-Cursor), Right-Cursor-Handle and the Left-Cursor-Handle (of the Cursor-Identification (input (1))), Right-Cursor-Handle (of the New-Left-Cursor), Left- Cursor-Handle (of the New-Right-Cursor), Cursor-Proxy-Handle (of the Cursor-Identification (input (1))), Child-

APPENDIX A

Proxy-Handle (of the New-Child), Proxy-Child-Handle (of the new Proxy-Identification), Proxy-Handle (of the new Proxy-Identification), Proxy-Leftrnost-Cursor-Handle and the Proxy-Rightmost-Cursor-Handle (of the new Proxy- Identification), Proxy-Size (of the new Proxy-Identification).

Monitors PI-Monitor-Bad-lndex (for the Parent-Identification), CHI-Monitor-Child-lnserts-Left (for the Right-Child), CHI- Monitor-Child-lnserts-Right (for the Left-Child), Pi-Monitor-Inserts-Child (for the Parent-Identification), CHI-Monitor- Cursor-ldentification-Shifted-Qff-Child (for the Current-Child),

4-

00

Case 2

APPENDIXA

VO

APPENDIX A

Current-Proxy)].

Monitors Pi-Monitor-Bad-Index (for the Parent-Identification), CHI-Monitor-Child-lnserts-Left (for the Right-Child), CHI- Monitor-Child-lnserts-Right (for the Left-Child), Pi-Monitor-Inserts-Child (for the Parent-Identification), CHI-Monitor- Cursor-ldentification-Shifted-Off-Child (for the Current-Child), CHI-Monitor-No-Cursor-Identification (for the Current- Child).

Case 4

Occurrence The Lock-Mode (input (4)) is false and the Cursor is moving to or from the boundary of the Parent

Deviated Behaviour Steps 1 - 3: Are the same as in the Generic Behaviour. Step 4: If the Cursor is moving from the boundary:

Step 4a: If the Action-Trilarity (input (3)) is Left: Update the Left-Cursor-Handle (3830 of FIG. 6) of the Old-Right- Cursor to reference No-Child. Update the Leftmost-Cursor-Handle (3210 of FIG. 3) to reference the Old-Right- Cursor and check for Pi-Monitor-Cursor-Leftmost for the Parent-Identification.

Step 4b: If the Action-Trilarity (input (3)) is Right: Update the Right-Cursor-Handle (3840 of FIG. 6) of the Old-Left- O Cursor to reference Cursor-Terminator. Update the Rightmost-Cursor-Handle (3220 of FIG. 3) to reference the Old-Left-Cursor and check for Pi-Monitor-Cursor-Rightmost for the Parent-Identification.

Step 5: If the Cursor is moving to the boundary:

Step 5a: If the Action-Trilarity (input (3)) is Left: Locate the New-Right-Cursor found through the Proxy-Leftmost- Cursor-Handle (3630 of FIG. 5) of the Current-Proxy. Update the Left-Cursor-Handle (3830 of FIG. 6) of the New- Right-Cursor and the Right-Cursor-Handle (3840 of FIG. 6) of the Cursor-Identification (input (1)) to reference each other. Update the Left-Cursor-Handle of the Cursor-Identification (input (1)) to reference Cursor-Terminator. Update the Leftmost-Cursor-Handle (3220 of FIG. 3) of the Parent-Identification to reference the Cursor- Identification (input (1)) and check for Pi-Monitor-Cursor-Leftmost for the Parent-Identification.

Step 5b: If the Action-Trilarity (input (3)) is Right: Locate the New-Left-Cursor found through the Proxy-Rightmost- Cursor-Handle (3640 of FIG. 5) of the Current-Proxy. Update the Right-Cursor-Handle (3840 of FIG. 6) of the New-Left-Cursor and the Left-Cursor-Handle (3830 of FIG. 6) of the Cursor-Identification (input (1)) to reference each other. Update the Right-Cursor-Handle of the Cursor-Identification (input (1)) to reference Cursor-Terminator. Update the Rightmost-Cursor-Handle (3220 of FIG. 3) of the Parent-Identification to reference the Cursor- ldentification (input (1)) and check for Pi-Monitor-Cursor-Rightmost for the Parent-Identification.

APPENDIX A

Case 5

Occurrence The Action-Trilarity (input (3)) is Neutral

Deviated Behaviour Step 1 : Is the same as in the Generic Behaviour.

Step 2: Copy the Left-Index (4220 of FIG. 8) found in the Child-ldentification-Content (3445 of FIG. 4 and 4200 of FIG. 8) of the Child identified by the Cursor to the Left-Index of the New-Child.

Step 3: Is the same as in the Generic Behaviour. Steps 4 + 5: Do not happen.

Step 6: Update the Child-Proxy-Handle (3430 of FIG. 4) of the New-Child to reference the Current-Proxy and the Child-Proxy-Handle of the Current-Child to reference No-Child. Update the Proxy-Child-Handle (3610 of FIG. 5) of the Current-Proxy to reference the New-Child. Check for the CHI-Monitor-Cursor-ldentification-Shifted-Off-Child and CHI-Monitor-No-Cursor-Identification for the Current-Child. Check for the Pl-Monitor-Deletes-Child for the Parent-Identification.

Step 7: Is the same as in the Generic Behaviour.

Fields Altered Parent-Handle-Starboard (of the New-Child), Left-Index (of the New-Child, Right-Child-Handle and the Left-Child-

APPENDIX A

Handle (of the New-Child), Left-Child-Handle (of the Right-Child) and the Right-Child-Handle of the (Left-Child), Number-Of-Children (of the Parent-Identification), Child-Proxy-Handle (of the New-Child), Child-Proxy-Handle (of the Current-Child), Proxy-Child-Handle (Current-Proxy)

Monitors CHI-Monitor-Child-Inserts-Left (for the Right-Child), CHI-Monitor-Child-lnserts-Right (for the Left-Child), Pl-Monitor- Inserts-Child and Pl-Monitor-Deletes-Child (for the Parent-Identification), CHI-Monitor-Cursor-ldentification-Shifted- Off-Child (for the Current-Child), CHI-Monitor-No-Cursor-Identification (for the Current-Child).

K)

APPENDIX A the new Proxy-Identification).

Monitors Pi-Monitor-Bad-Index (for the Parent-Identification), [CHI-Monitor-Child-lnserts-Left and CHI-Monitor-Child-Links- Left (for the Right-Child), Pl-Monitor-Child-Leftmost for the Parent-Identification)] or fCHI-Monitor-Child-lnserts- Right and CHI-Monitor-Child-Links-Right (for the Left-Child), Pl-Monitor-Child-Rightmost for the Parent- Identification)], Pi-Monitor-Inserts-Child (for the Parent-Identification), CHI-Monitor-Cursor-ldentification-Shifted-Off- Child (for the Current-Child).

Kl-New-Child

APPENDIXA

Step 4: Update the following fields for the new Proxy-Identification (3600 of FIG. 5): Proxy-Child-Handle (3610 of FIG. 5) to reference No-Child, Proxy-Handle (3620 of FIG. 5) to reference No-Proxy, Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) and Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) to reference new Cursor-Identification (3800 of FIG. 6), Proxy-Size (4030 of FIG. 7) found in the Proxy-Identification-Content (3615 of FIG. 5 and 4020 of FIG. 7) to equal 1.

Step 5: Do everything exactly the same as insert (including allowing for all cases) using the newly created Cursor- Identification (3800 of FIG. 6) as the Source-Child to be inserted into input (1).

If the Action-Trilarity (input (2)) is Neutral, then the newly created Manabars-Set (3000 of FIG. 2) replaces the Manabars-Set pointed to by the Cursor of the destination location from parameter (1).

Fields Altered Parent-Identification (New): Number-Of-Children, Number-Of-Cursors, Index-Integrity, Pi-Monitor-Event, Leftmost- Cursor-Handle, Rightmost-Cursor-Handle, Leftmost-Child-Handle, Rightmost-Child-Handle, Whole, Float, Fast-ABS- Handle, Slow-ABS-Handle, and Type.

Cursor-Identification (New): Cursor-Proxy-Handle, Parent-Handle-Port, Left-Cursor-Handle, Right-Cursor-Handle, CUI- Monitor-Event, and Child-Handle.

Proxy-Identification (New): Proxy-Child-Handle, Proxy-Handle, Proxy-Leftmost-Cursor-Handle, Proxy-Rig htmost- Cursor-Handle, and Proxy-Size.

Monitors All monitors that are in the insert method

Kl-Remove-Monitor

APPENDIX A

Kl-Reset

Inputs None

Outputs None

References set up at None the start

Generic Behaviour Resets the Kernel-Image (480 of FIG. 3, 2600 of FIG. 13) to an empty state where there is only one Manabars-Set of Type Type-Powerset accessible via Get-Powerset Kl-lnterface method.

Fields Altered None

Monitors None

KI-Set-Fast-ABS-Handle

Ul

Kl-Set-Float

Inputs (1) Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) that identifies the Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) to undergo the Float (4450 of FIG. 9) replacement.

(2) Value to be set.

APPENDIX A

KI-Set-Governance-Layer

KI-Set-Slow-ABS-Handle

Inputs (1) Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) that identifies the Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) to undergo the Slow-ABS-Handle (4470 of FIG. 9) replacement. (2) Slow-ABS-Handle. •

Outputs None

References set up at Parent-Identification: Found through the Parent-Handle-Port (3820 of FIG. 6) of the Cursor-Identification (input 1). the start

Generic Behaviour This method sets the Slow-ABS-Handle found within the Parent-Identification-Content of input (1).

Step 1: Locate and set the Slow-ABS-Handle (4470 of FIG. 9), found within the Parent-Identification-Content (3040 of FIG. 2 and 3200 of FIG. 3) of the Parent-Identification, to equal input (2). Check for the PI-Monitor-Slow-ABS-Changed

APPENDIX A

Kl-Set-Type

-4

Kl-Set-Whole

Inputs (1) Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) that identifies the Parent-Identification (3040 of FIG. 2 and 3200 of FIG. 3) to undergo the Whole (4440 of FIG. 9) replacement.

(2) A 64-Bit-Whole-Number that represents the Whole.

Outputs None

Generic Behaviour This method sets the Whole found within the Parent-Identification-Content of input (1).

Step 1: Locate and set the Whole (4440 of FIG. 9), found within the Parent-Identification-Content (3040 of FIG. 2 and 3200 of FIG. 3) of the Parent-Identification, to equal input (2). Check for the Pl-Monitor-Whole-Changed for the Parent- Identification.

APPENDIX A

Fields Altered Whole (of the Parent-Identification)

Monitors Pl-Monitor-Whole-Changed (for the Parent-Identification)

Kl-Shift-Cursor

OO

APPENDIX A

Cursor-Handle (3630 of FIG. 5) of the Current-Proxy. Locate the New-Left-Cursor through the Left-Cursor-Handle (3830 of FIG. 6) of the New-Right-Cursor.

Step 2b: If the Action-Trilarity (input (3)) is Right: Locate the New-Left-Cursor found through the Proxy-Rightmost- Cursor-Handle (3640 of FIG. 5) of the Current-Proxy. Locate the New-Right-Cursor through the Right-Cursor- Handle (3840 of FIG. 6) of the New-Left-Cursor.

Step 2: Update the Right-Cursor-Handle (3840 of FIG. 6) and the Left-Cursor-Handle (3830 of FIG. 6) of the Cursor-Identification (input (1)) to reference the New-Left-Cursor and the New-Right-Cursor. Update the Right- Cursor-Handle (3840 of FIG. 6) of the New-Left-Cursor and the Left-Cursor-Handle (3830 of FIG. 6) of the New- Right-Cursor to reference the Cursor-Identification (input (1)).

Step 3a: If there is no Next-Proxy create a new Proxy-Identification (3010 of FIG. 2 and 3600 of FIG. 5) as the Next-Proxy. Update the Proxy-Child-Handle (3610 of FIG. 5) of the Next-Proxy to reference the Next-Child. Update the Proxy-Handle (3620 of FIG. 5) to point to No-Proxy and the Proxy-Size (4030 of FIG. 7), found in the Proxy-Identification-Content (3615 of FIG. 5 and 4020 of FIG. 7) of the Next-Proxy, to equal 0. If the Action- Polarity (input (2)) is Left then update the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) of the Next-Proxy to reference input (1), otherwise update the Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) of the Next-Proxy to reference input (1). Update the Child-Proxy-Handle (3430 of FIG. 4) of the Next-Child to reference the Next-Proxy.

Step 3: Update the Cursor-Proxy-Handle (3810 of FIG. 6) of the Cursor-Identification (input (1)) to reference the Next-Proxy. Update the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) (if the Action-Polarity (input (2)) is Right) or the Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) (if the Action-Polarity (input (2)) is Left) of the Next-Proxy to reference the Cursor-Identification (input (1)). If either the Proxy-Leftmost-Cursor-Handle or the Proxy-Rightmost- Cursor-Handle of the Next-Proxy is referencing Cursor-Terminator then also update them to reference the Cursor- Identification (input (1)). Increase the Proxy-Size (4030 of FIG. 7) found in the Proxy-Identification-Content (3615 of FIG. 5 and 4020 of FIG. 7) of the Next-Proxy, by 1. Decrease the Proxy-Size found in the Proxy-Identification- Content of the Current-Proxy by 1.

Step 3b: If the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) of the Current-Proxy references the Cursor- Identification (input (1)) and the Action-Polarity is Right then update the Proxy-Leftmost-Cursor-Handle of the Current-Proxy to reference the Old-Right-Cursor.

Step 3c: If the Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) of the Current-Proxy references the Cursor- Identification (input (1)) and the Action-Polarity is Left then update the Proxy-Rightmost-Cursor-Handle of the Current-Proxy to reference the Old-Left-Cursor.

APPENDIXA

o

APPENDIXA

c

\

APPENDIXA

APPENDIX A the Cursor-Identification (input (1))), Proxy-Leftmost-Cursor-Handle (if the Action-Polarity (input (2)) is Right) or the Proxy-Rightmost-Cursor-Handle (if the Action-Polarity (input (2)) is Left) (of the Next-Proxy), Proxy-Size (of the Next-Proxy), Proxy-Size (of the Current-Proxy), Proxy-Leftmost-Cursor-Handle or Proxy-Rightmost-Cursor-Handle (of the Current-Proxy).

Monitors CHI-Monitor-Cursor-ldentification-Shifted-Off-Child (for the Current-Child), CHI-Monitor-Cursor-ldentification- Shifted-Onto-Child (for the Next-Child), CUI-Monitor-Cursor-At-Boundary (for input (1)), CUl-Monitor-Cursor-At- Leftmost or CUl-Monitor-Cursor-At-Rightmost (for input (1)), Pl-Monitor-Cursor-Leftmost or Pl-Monitor-Cursor- Rightmost (for the Parent-Identification).

Kl-Shift-Cursor-To-Boundary

inputs (1) The Cursor-Identification (3030 of FlG. 2 and 3800 of FIG. 6) for this shift (2) Action-Polarity

Outputs None

Current-Proxy: The main Proxy-Identification (3010 of FlG. 2 and 3870 of FlG. 6) found through the Cursor-Proxy- Handle (3810 of FIG. 6) of input (1).

Current-Child: The Child that the Cursor-Identification (input (1)) is currently pointing to -found through the Proxy- Child-Handle (3610 of FlG. 5) of the Current-Proxy.

New-Child: The Child-Identification (3020 of FIG. 2 and 3400 of FIG. 4) that the Cursor-Identification will be shifted to. Found through the Leftmost-Child-Handle (3230 of FlG. 3) or the Rightmost-Child-Handle (3240 of FlG. 3) of the Parent-Identification depending on the Action-Polarity (input (2)).

New-Proxy: (Able to be No-Proxy) The Proxy-Identification that the New-Child references. Found through the Child-Proxy-Handle (3430 of FIG. 4) of the New-Child.

Old-Left-Cursor: (Able to be Cursor-Terminator) Found through the Left-Cursor-Handle (3830 of FlG. 6) of the Cursor-Identification (input (1)).

Old-Right-Cursor: (Able to be Cursor-Terminator) Found through the Right-Cursor-Handle (3840 of FlG. 6) of the Cursor-Identification (input (1)).

Leftmost-Child: Found through the Leftmost-Child-Handle (3230 of FlG. 3) of the Parent-Identification. ;

APPENDIXA

Rightmost-Child: Found through the Rightmost-Child-Handle (3240 of FlG. 3) of the Parent-Identification.

Generic Behaviour Functionally, this method moves the Cursor to the Leftmost or Rightmost location as indicated by the Action- Polarity.

Step 1 : Locate the Left-Cursor-Handle (3830 of FIG. 6) of the Old-Right-Cursor and the Right-Cursor-Handle (3840 of FIG. 6) of the Old-Left-Cursor and update them to reference each other.

Step 2a: Update the Left-Cursor-Handle (3830 of FiG. 6) of the Leftmost-Cursor-Handle (3210 of FIG. 3) of the Parent-Identification and the Right-Cursor-Handle (3840 of FIG. 6) of the Cursor-Identification (input (1)) to reference each other. Update the Left-Cursor-Handle of the Cursor-Identification (input (1)) to reference Cursor- Terminator. Update Leftmost-Cursor-Handle of the Parent-Identification to reference Cursor-Identification (input (1)). Check for the Pi-Monitor-Cursor-Leftmost for the Parent-Identification.

Step 2b: Update the Right-Cursor-Handie (3840 of FIG. 6) of the Rightmost-Cursor-Handle (3220 of FIG. 3) of the Parent-Identification and the Left-Cursor-Handle (3830 of FIG. 6) of the Cursor-Identification (input (1)) to reference each other. Update the Right-Cursor-Handle of the Cursor-Identification (input (1)) to reference Cursor-Terminator. Update Rightmost-Cursor-Handle of the Parent-Identification to reference Cursor-Identification (input (1)). Check for the Pl-Monitor-Cursor-Rightmost for the Parent-Identification.

Step 3a: If there is no New-Proxy create a new Proxy-Identification (3010 of FIG. 2 and 3600 of FIG. 5) as the New-Proxy. Update the Proxy-Child-Handle (3610 of FIG. 5) of the New-Proxy to reference the New-Child. Update the Proxy-Handle (3620 of FIG. 5) to point to No-Proxy and the Proxy-Size (4030 of FIG. 7), found in the Proxy-Identification-Content (3615 of FIG. 5 and 4020 of FIG. T) of the New-Proxy, to equal 0. If the Action-Polarity (input (2)) is Left then update the Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) of the New-Proxy to reference input (1), otherwise update the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) of the New-Proxy to reference input (1). Update the Child-Proxy-Handle (3430 of FIG. 4) of the New-Child to reference the New-Proxy.

Step 3: Increase the Proxy-Size (4030 of FIG. 7), found within the Proxy-Identification-Content (3615 of FIG. 5 and 4020 of FIG. 7) of the New-Proxy, by 1 and decrease the Proxy-Size, found within the Proxy-Identification-Content of the Current-Proxy, by 1. Update the Cursor-Proxy-Handle (3810 of FIG. 6) of the Cursor-Identification (input (1)) to reference the New-Proxy. Update the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) (if the Action-Polarity (input (2)) is Left) or the Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) (if the Action-Polarity (input (2)) is Right) of the New-Proxy to reference the Cursor-Identification (input (1)). If either the Proxy-Leftmost-Cursor-Handle or the Proxy-Rightmost-Cursor-Handle of the Next-Proxy is referencing Cursor-Terminator then also update them to reference the Cursor-Identification (input (1)). If the Proxy-Rightmost-Cursor-Handle (3640 of FIG. 5) of the

APPENDIX A

Ul

Case 2

Occurrence The Cursor is the boundary Cursor in the direction of the Action-Polarity (input (1)

Deviated Behaviour Steps 1 + 2: Do not occur

Steps 3 + 4: Are the same as in Generic Behaviour.

Fields Altered Proxy-Child-Handle (of the New-Proxy), Child-Proxy-Handle (of the Leftmost-Child or the Rightmost-Proxy -

APPENDIX A depending on Action-polarity (input (2))), Proxy-Size (of the New-Proxy), Proxy-Size (of the Current-Proxy), Cursor- Proxy-Handle (of the Cursor-Identification (input (1))),

Proxy-Leftmost-Cursor-Handle or Proxy-Rightmost-Cursor-Handle (of the New-Proxy), Proxy-Leftmost-Cursor- Handle or Proxy-Rightmost-Cursor-Handle (of the Current-Proxy).

Monitors CHI-Monitor-Cursor-ldentification-Shifted-Off-Child for the Current-Child, CHI-Monitor-Cursor-ldentification-Shifted- Onto-Child for the New-Child, CUI-Monitor-Cursor-At-Boundary, CUI-Monitor-Cursor-At-Leftmost or CUl-Monitor- Cursor-At-Rightmost for input (1 ).

APPENDIX A

Monitors Pi-Monitor-Cursor-Leftmost or Pi-Monitor-Cursor-Rightmost (for the Parent-Identification), CHI-Monitor-No-Cursor- Identification (for the Current-Child), CHI-Monitor-Cursor-ldentification-Shifted-Off-Child for the Current-Child, CHI- Monitor-Cursor-ldentification-Shifted-Onto-Child for the New-Child, CUI-Monitor-Cursor-At-Boundary, CUI-Monitor- Cursor-At-Leftmost or CUI-Monitor-Cursor-At-Rightmost for input (1).

Kl-Spawn-Cursor-ldentification

-4

APPENDIXA

oe

APPENDIX B

Monitors

The parameters of the Monitor reflect the changes made to the Manabars-Set involved. The parameters include such things as:

A Parent, which is a spawned Cursor of the original Cursor-Identification. Some parameters include a Parent before and a Parent after. Both of these Parents are spawned Cursor- Identifications which reflect the state of the original Cursor-Identification before and after the event occurred.

A Child, which is the Cursor-Identification of the Child involved in the Kl-lnterface call. This Child may be the Child that the original Cursor-Identification is pointing to or the Child to the Right or the Left of the Child that the original Cursor-Identification is pointing to. The Child may also be the Child that was inserted or deleted from the Parent. A Cursor-Identification, which is the original Cursor-Identification.

The original Cursor-Identification is the Cursor-Identification that was involved in the Kl-lnterface method call that triggered the Monitor.

These parameters are found through the MG-Capture-lnstance of the UPT-Monitor-Generator.

APPENDIX B Child-Identification-Monitors

-4

O

¹ Use Type Type-No-Child if Manabars-Set previously empty.

² Same as above.

APPENDIX B

³ Same as above

⁴ Same as above

APPENDIX B

Parent-Identification-Monitors

-4 K)

' Use Type Type-No-Child if Maπabars-Set previously empty.

APPENDIX B

-4

Use Type Type-No-Child if Manabars-Set previously empty.

APPENDIX B Cursor-Identification-Monitors

Appendix C

Claims

1. A computational device including a data manipulation and/or storage structure representing a plurality of sets of data storage locations, each set having a parent set identifier and containing a linked list of one or more child storage locations wherein each parent set identifier references a child storage locations in the set, and wherein each child storage location can reference its parent storage location.

2. A computational device as claimed in claim 1 wherein each parent set identifier references a plurality of markers that each reference a single child storage location.

3. A computational device as claimed in claim 1 or claim 2 including an interface that can manipulate data storage locations by means of a marker.

4. A computational device as claimed in claim 1 where each parent set identifier is capable of attaching primitive data structures or files.

5. A computational device as claimed in claim 2 where each parent set identifier is capable of attaching primitive data structures or files.

6. A computational device as claimed in claim 3 where each parent set identifier is capable of attaching primitive data structures or files.

7. A computational device as claimed in claim 3 wherein the data manipulation can trigger events.

8. A data structure representing a plurality of sets of data storage locations, each set having a parent set identifier and containing a linked list of one or more child storage locations wherein each parent set identifier references a child storage locations in the set, and wherein each child storage location can reference its parent storage location.

9. A data structure as claimed in claim 8 wherein each parent set identifier references a plurality of markers that each reference a single child storage location.

10. A computational device substantially as herein described with reference to any embodiment.

11. A computational device substantially as herein described with reference to any embodiment illustrated in the drawings.

12. A data structure substantially as herein described with reference to any embodiment.

13. A data structure substantially as herein described with reference to any embodiment shown in the drawings.