WO2007037709A1

WO2007037709A1 - An abstract platform to facilitate the interoperability of information

Info

Publication number: WO2007037709A1
Application number: PCT/NZ2006/000254
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; WO2007037710A2

Abstract

A universal virtual computer allows a homogeneous grid environment to be provided from a set of heterogenous hosts. This is achieved by providing a common execution format through cross-compilation.

Description

AN ABSTRACT PLATFORM TO FACILITATE THE INTEROPERABILITY

OF INFORMATION

FIELD OF THE INVENTION

This invention relates to grid computing and¹ information technology. The invention has particular relevance to homogeneous environments for mobile agents that can lead to a distributed Operating System.

BACKGROUND

Distributed computing has been deployed mostly in academic and scientific environments since the 1980s, however, it is only now with the massive connectivity of the Internet and the requirements for large processing that distributed computing has now matured into the grid. The concept of the grid is similar to that of an electricity provider, where users simply draw the amount of computational power they require from an effectively endless supply. There are many popular implementations of the grid such as the Globus Toolkit™.

As the number of computing systems and platforms has become more diverse, there has become a demand for a Universal Virtual Computer (UVC) that can support both computational content and a business platform. This need is driven primarily by a Universal Machine's incapacity for change. Therefore, a holistic approach that incorporates all generic functionality is desirable.

Historically, there has been an attempt to provide intermediate platforms or formats that can facilitate interoperability, including the HTML, which lacks computational completeness - but none of these goes far as the Universal Virtual Computer (UVC).

Adobe Acrobat™ by Adobe is an example of such a platform that aims to act as an intermediate format standard, through which other formats can be converted. Users can construct content on specialised software and then distribute content through the Acrobat format. XML and its popular HTML sϋb-standards are another example of an intermediate format that can be used to deliver content independently of the format on which it was constructed. Both these platforms, however, are not computationally complete, so they cannot emulate other processes or platforms. Specifically, these formats limit the type of content that can be represented. The

Java Virtual Machine is an example of a platform that is computationally complete. The Java

Virtual Machine can indeed act as an intermediate format via its property of computational completeness and not directly through any specific design characteristic that facilitates interoperability.

OBJECT OF THE INVENTION

It is an object of the invention to provide a Universal Virtual Machine that overcomes or at least ameliorates disadvantages of existing machines, systems or methods. Alternatively, it is an object of the invention to provide a useful alternative to known machines, systems or methods.

SUMMARY OF THE INVENTION

In one aspect the invention provides a Universal Virtual Computer (UVC) having means to produce a homogeneous grid environment from a set of heterogeneous hosts by enabling computational completeness via a common execution format.

In a preferred embodiment the common execution format can be simulated on any machine in the grid environment through cross-compilation.

The UVC may include means to support an Operating System that serves mobile agents that are able to transcode from hosts on a peer-to-peer network.

In another aspect the invention provides a Universal Virtual Computer comprising a memory store of Sets, a central processor that enables computational completeness and means to transmit instructions to a multitude of components to be completed asynchronously.

In yet another aspect the invention provides a UVC in a grid network including means to prevent undesirable hosts from joining the grid network, as directed by the Operating System.

The UVC is preferably capable of computational completeness and fully operational without extension.

The UVC may be extended such that some components allow for the compilation and execution of binaries designed for von Neumann processors.

The compilation and execution of binaries is preferably derived from an abstract set of machine instructions that can be reproduced on various von Neumann processors. In a further aspec the invention provides a UVC where a first component processes instructions either synchronously or asynchronously so that synchronous instructions are completed immediately and asynchronous instructions are forwarded to one or more additional components to be completed in parallel while the first component completes further instructions.

In a still further aspec the invention provides a UVC that supports a plurality of mobile agents and assigns an account to each mobile agent, and means to add and/or deduct resources to or from the account upon purchase of resources.

Preferably the mobile agent is destroyed when the account has a null balance.

Multiple components that each provide a resource may be made available via a market orientated mechanism including but not limited to bandwidth, computation and memory.

A Realtime-Marketplace may be provided that allows mobile agents to purchase the resource for a specific time period and up to a limited level that is negotiated by the mobile agent prior to resource usage enabling the resource to be drawn on demand.

A Prepaid-Marketplace may be provided that allows mobile agents to reserve the resource at a required level for a specific time period, for which a price is determined prior to purchasing the resource.

The purchase can preferably be represented by the Universal Virtual Computer as an identifier to be sold in an open digital marketplace, later to be reclaimed by any mobile agent that presents the same identifier.

Alternatively or additionally the purchase can be represented by the Universal Virtual Computer as an identifier to be sold in an open digital marketplace, later to be reclaimed by any mobile agent that presents the same identifier.

The purchase can alternatively be represented by the Universal Virtual Computer as an identifier to be sold in an open digital marketplace, later to be reclaimed by any mobile agent that presents the same identifier.

Preferably, the capacity of the resource can be recharged at the discretion of the host environment. The resource may be made available at a cost effective rate using a standby model where resource availability is erratic and distributed as the remainder after the Realtime-Marketplace has been satisfied.

Alternatively or additionally the resource can be made available at a cost effective rate using a standby model where resource availability is erratic and distributed as the remainder after the Prepaid-Marketplace has been satisfied.

Preferably, the resource can be made available at a more cost effective rate using an idle model where resource availability is not only erratic but can experience major lulls and distributed as the remainder after the Realtime-Marketplace and the Prepaid-Marketplace have been satisfied.

Preferably, the resource can be made available at the most cost effective rate for one or more marketplaces for the resource using a background model where resource availability is totally unreliable and is distributed as a remainder after all other marketplaces have been satisfied.

The purchase transaction may include a reimbursement price for which the mobile agent is willing to accept in exchange for the unexpected cancellation of either the purchase transaction as a realtime contract or as a prepaid contract.

Other aspects of the invention will be apparent from the following description.

The invention takes grid computing further by supporting heterogeneous environments and total security to enable an open grid that allows anyone to join - providing they can find a Node partner already on the network that will allow them to enter. The invention goes further than a traditional grid because it is not constrained by legacy components that expose vulnerabilities that result in a non-zero attack surface area. Instead, the invention offers a hardware platform

(the Ill-Emulator at 551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) capable of supporting a distributed Operating System.

The Interoperable Infrastructure (III) Model (refer to 12000 of FIG. 44 and 12200 of FIG. 45) was originally proposed by Dr Kay Fielden in a paper - Fielden, K. (2004). An Interoperable

Information Infrastructure Model (Ill-Model). In J. Cooper & P. Swatman (Eds.), Proceedings of the 12th CoIIECTeR Workshop on eCommerce (CD-Rom ed.). Adelaide, Australia. Paper presented at the 12th CoIIECTeR Workshop on eCommerce, 7-8 May, Adelaide, Australia

(hereinafter the Fielden paper). In order to facilitate interoperability, the invention operates as a Universal Virtual Computer (UVC) - an essentially future proof platform that does not need to be altered and can represent any kind of information. (See "The UVC: a Method for Preserving Digital Documents - Proof of Concept" ISBN: 90-6259-157-4 by Ir. Raymond Lorie, December 2002, Copyright: IBM/Koninklijke Bibliotheek).

The Ill-Emulator is different to the Java Virtual Machine in that the Ill-Emulator aims to provide a homogenous Operating System where Java only provides a homogeneous platform. The homogeneous Operating System offers high-level governance functions to enforce compliancy of intellectual property rights. It offers the capacity to trace illegal money transactions and prevent the dissemination of stolen information. To enable the homogeneous Operating System, a mechanism to induce super-conductive transcoding (described further below) coupled with a method to enable software to operate with zero dependencies enables mobile agents to transcode seamlessly from Node to Node. The Ill-Emulator does not attempt to provide interoperability at a semantic level in the way that the XML Data Type Definition does, but rather at the level at which the data is encoded.

A homogeneous Operating System is a foundation requirement for the Interoperable Information Infrastructure (III) as it enables a coherent policy to be enforced across a distributed network. The III is a natural extension of the Global Information Infrastructure (GII), which is the framework that results from the need for information to be exchanged in an agreed and acceptable manner. It includes a collection of platforms, protocols and interfaces including the Internet, telephone and banking systems.

The GII has a number of problems including susceptibility to malicious attack, interoperability problems and sheer complexity for users. The invention can be applied to the GII to prevent these problems and migrate the GII to the Interoperable Information Infrastructure (III).

Thus the invention allows the very high level objectives proposed by Dr Fielden to be implemented in an actual Ill-Model (12000 of FIG. 44 and 12200 of FIG. 45). In reconfiguring the entire hardware architecture, Operating System and high level applications that manage grid activity, the opportunity has been taken to maximise the value when starting from a clean slate design. This issue is compounded by the fact that a Universal Virtual Computer (UVC) may not alter its design after its release. Although there is no direct compatibility (other than via emulation) with existing systems, this architecture is free to implement any mechanism that may produce value, not limited by the need for backward compatibility. The invention enables a plurality of heterogeneous environments to support mobile agents that can seamlessly transcode from one environment to another without undergoing unconstrained alteration of form. It is this homogeneous environment that maximises value through the form. The invention creates a homogeneous environment that maximises value through the simplification of digital economic activity.

The Ill-Model Candidate described herein is useful because it can be applied as a commercial trading environment capable of migrating the old economy into its digital future including the capacity to enforce licence fees for certain rights (for example patent rights) in the old economy. Any high level governance is directed by the homogeneous Operating System. Individuals can utilise this grid to generate revenue from both hardware and intellectual property. Governments can tax all transactions and can issue directives from tracing money to banning undesirable content.

The invention allows seamless transcoding of mobile agents on a homogeneous Operating System. All functionality is fixed eternally and results in a Universal Virtual Computer (UVC). The invention is structured as two parts, one being absolutely defined and known as the Ill- Model (12000 of FIG. 44 and 12200 of FIG. 45) and the other being abstract and specifically undefined and is known as a 3IP (see 3IP-lnterface at 17000 of FIG. 57). Since the 3IP is undefined it allows for various implementations to operate in parallel that results in an open grid platform with heterogeneous hosts, yet appears as an homogeneous environment for Digital Businesses (mobile agents). The invention is described functionally at a high level with sufficient detail to provide an absolute implementation, however, its deliberate avoidance of specificity enables its actual implementation can embody any form, provided that it adheres to the invention's requirements. The invention's combination of abstraction and functional description means that the implementation can take any physical form including quantum computing, magneto logic, biological computers, Field Programmable Gate Arrays (FPGA), traditional von Neumann architecture or dedicated circuits that are optimised for the implementation of the invention.

MODEL

The invention is embodied as a hardware platform that supports a Node (380, 395 of FIG. 4 and 200a-200e of FIG. 2) on a grid network. The hardware platform is called the Ill-Emulator and can be simulated from other hardware or software platforms. Platforms occur at many points within information and computing systems including hardware, Operating System and applications. Platforms are useful in software because they provide a set of functions that applications can draw on. However, once a platform is established, it suffers from inflexibility because it becomes an interface and by its nature it can't change. Software on the newer version of the platform can't execute on older platforms. In a grid environment, this poses a serious problem as mobile agents are free to move from Node to Node and must be unencumbered in their execution.

Central to the Ill-Model's (12000 of FIG. 44 and 12200 of FIG. 45) ability to support a unified Operating System across a heterogeneous environment is its ability to allow Digital-Businesses

(8800 of FIG. 29) to transcode across multiple platforms, retain its integrity and not grow in size with each transcode event. Digital-Businesses are capable of seamless transcoding because their shape or form is identical on each Node - hence the mandatory requirement that all properties for information on this Universal Virtual Computer (UVC) be fixed for eternity. Once Digital Businesses are free to move to any platform, they can be managed within an abstract

Operating System that may ultimately also undergo transcoding during upgrades.

Without the Ill-Model, transcoding between platforms is a creative process because one platform format is mapped into another. The semantic characteristics of each platform are represented as data structures in each format. A problem arises when the structural symmetry for information context varies dynamically and requires intelligence to approximate a one to one mapping. There is no guarantee that an identical mapping can always be made. The Ill-Model (12000 of FIG. 44 and 12200 of FIG. 45) reduces the transcoding problem to a task of cross- compilation where the target platform utilises a set of machine instructions that can be substituted for combinations of instructions on the source platform in the event that they do not exist on the target platform. This is possible because the abstract 3IP component is required to conform to an idealistic von Neumann architecture by implementing the 3lP-lnterface (17000 of FIG. 57). The implementation of the 3IP can define any number of instructions - provided that the instruction set enables computational completeness. Transcoding occurs at peer connections when Node (12010a, 12010b and 1201On of FIG. 44 and 12210a, 12210b, 1221On of FIG. 45) partners propagate Digital-Businesses between each other. In building the transcoder, each instruction in the source 3IP needs to be translated into one or more instructions in the target 3IP; or one or more instructions in the source 3IP is condensed into a single instruction in the target 3IP. By simply substituting instructions, an exact behavioural replica is fashioned. For example, if the source 3IP uses a floating point instruction that does not exist on the destination 3IP, then a series of instructions that simulate^' the behaviour of the floating point instruction must be produced on the target 3IP. Traditionally, cross compilers are unable to address the issue of seamless transcoding because they contain platform specific dependencies in the form of library calls. The Ill-Emulator has zero dependencies, so it can guarantee software behavioural integrity.

The invention is an abstract specification because it requires additional architecture that is not specified within this document in order to be actually implemented. The abstract specification allows different platforms to appear as if they are part of the homogenous grid, because the same behaviour can be modelled in a variety of ways.

FIG. 3 shows how a Digital-Business can cycle in a loop and not undergo continuous change of 5 form as it moves through Nodes X, Y and Z.

In order for a platform to be part of the Ill-Model, the platform needs to structure itself to process information within a specific format, which is referred to in this document as a 3IP. The 3IP is non-restrictive because it allows the platform to be implemented physically in almost any way 10 while logically enables it to describe any information in an identical way as all 3IPs do. The 3IP is therefore naturally both forwards and backwardly compatible because its format is fixed by the definition of the Ill-Model (12000 of FIG. 44 and 12200 of FIG. 45).

In. order to implement the invention, a number of Nodes (380, 395 of FIG. 4 and 200a - 20Oe of

1.5 FIG. 2) are required - each of them connected ad hoc in a peer-to-peer fashion. Each Node consists of an Interoperability Layer (101a of FIG. 1 and 202a of FIG. 2) and a Governance

Layer (101b of FIG. 1 and 202b of FIG. 2) with the Digital-Businesses (8800 of FIG. 29) operating from the Information Layer (202c of FIG. 2). Digital-Businesses are able to propagate from Node to Node along these partnership connections. The Governance Layer is the

20 foundation of the homogenous Operating System.

The Ill-Model refers to the holistic system that emerges when a multitude of Interoperability Layers are configured with a suitable Governance Layer to operate as a grid network.

25 DR FIELDEN'S 4 LAYERED MODEL

The invention adheres to Dr Fielden's 4 layered model, as shown in Figure 1. Layer 1 is the Host Platform Layer (101z of FIG. 1 , 202z of FIG. 2) is the host on which the Layer 2 or the Interoperability Layer (101a of FIG. 1 and 202a of FIG. 2) executes. This can be hardware 30 and/or software, the only requirement being that Layer 1 can execute or implement software and is therefore computationally complete. From a traditional ISO perspective Layer 1 can be thought of as consisting of the physical, data link, network and transport layers.

Layer 2 (Interoperability Layer) is implemented by the 3IP Model Candidate itself (the invention)

35 and includes the 3IP and software required to transcode each 3IP it supports. The remaining architecture in Layer 3 that is the Governance Layer (101 b of FIG. 1 , 202b of FIG. 2 and 6475 of FIG. 18) and Layer 4 that is the Information Layer (101c of FIG. 1 and FIG. 2) is virtual and is constructed entirely from within Layer 2 (Interoperability Layer) that represents the Ill-Model Candidate.

Layer 3 (Governance Layer) is infrastructure and is concerned with governance both legally and mechanically and has a function similar to that of an Operating System.

Layer 4 (Information Layer) is any information in the form of a Digital-Business (8800 of FIG. 29). All information that exists as a Digital-Business must communicate with the underlying infrastructure through the Governance Layer that enables the action to be meaningful in a legislated environment.

FUNCTIONALITY OF THE INVENTION

The Ill-Model (12200 of FIG. 45 and 12000 of FIG. 44) deployment reduces complexity and increases productivity through the use of a Ill-Model Candidate as described herein. Since all

3IPs (see 3IP-lnterface at 17000 of FIG. 57) are bound to the architecture of the Ill-Model

Candidate, it must provide adequate functionality to enable all information to be represented on the platform. It is desirable that core functionality is not stored in the 3IP since this cannot be transcoded to other platforms - where this functionality does not reside. The role of the 3IP is to provide computation by engaging the Host Platform (6840 of FIG. 20 and 7200 of FIG. 22). For example, a 3IP could be used to build a quantum computer, but this implementation would still represent information in a manner that is consistent with the Ill-Model Candidate.

In a preferred embodiment, the core mechanisms and emergent behaviour, when coupled with additional systems external to those referred to in this document are delivered by this Ill-Model Candidate as follows:-

INTROSPECTIVE SCOPE

All software is forced to execute at a level of scope as defined by Set Theory. This means that software is unable to affect other software for which it does not contain a reference. Mechanisms (such as the Reference Membrane as conceived by Dr Fielden) to enable software to communicate safely are beyond the scope of this document and are the function of the Governance Layer (see Appendix G for an explanation on the Kernel-Image that is derived from this patent). ABSTRACT HUMAN COMMUNICATION

The Ill-Model Candidate may not change over time as it is a Universal Virtual Computer (UVC). Therefore communication with people is structured in a form that is both forwardly and backwardly compatible. Communication with people is delivered to an abstract human body as a sensory experience. Returning information is encoded as a sensory perception, generated from an abstract human body. New sensory data can be added over time without effecting old Interoperability Layer devices and sensory resolution can be increased at any point.

CAPACITY FOR TRADE

The Digital-Businesses (8800 of FIG. 29) are able to engage in trade with one another. The Interoperability Layer (101a of FIG. 1 , 202a of FIG. 2) enables a monetary platform backed on computational credits to enable Digital-Business to Digital-Business trading.

GOVERNANCE-LAYER SUPERSTRUCTURE

Each Interoperability Layer device utilises an identical superstructure for the Governance Layer (101b of FIG. 1, 202b of FIG. 2 and 6475 of FIG. 18), therefore, the homogenous Operating System can operate on any 3IP (see 3IP-lnterface at 17000 of FIG. 57) by utilising this universal structure.

INFORMATION OBTAINS AUTONOMY ACROSS A GRID

Information located at the Information Layer (101c of FIG. 1 and 202c of FIG. 2) is structured so that it takes the form of a Digital-Business and is free to migrate from Node to Node (200a-200e of FIG. 2, 380 and 395 of FIG. 4). It may duplicate itself any number of times and is able to easily communicate with any instance that it has created. Applications can therefore execute in parallel, but they need to be written to take advantage of this unique environment. Unlike conventional grids that are job orientated and take inputs to generate an output, the Ill-Model (12000 of FIG. 44 and 12200 of FIG. 45) grid endows each Digital-Business with a natural autonomy and persistence so that it may achieve immortality, providing that the Digital-Business has sufficient funds to pay for the resources it consumes.

Transcoding is illustrated in Figure 2b. Referring to that Figure, the invention enables a Digital- Business to transcode from heterogeneous Nodes X (320 of FIG. 3), Y (320 of FIG. 3) and Z (325 of FIG. 3) to take equivalent forms Digital-Business-Q1 (335 of FIG. 3), Digital-Businesses (340 of FIG. 3) and Digitai-Business-Q3 (345 of FIG. 3) respectively. The Operating System itself can be transcoded in an identical way to produce a single abstract homogeneous Operating System.

INTROSPECTIVE SCOPE OF EXECUTION

The unique mathematics on which the invention operates is derived from Set Theory to provide total protection against attack. If the software is required to communicate with other software, it can utilise a mechanism defined by Dr Fielden known as a Reference-Membrane that takes place within the Governance Layer (101b of FIG. 1 , 202b of FIG. 2 and 6475 of FIG. 18) and is beyond the scope of this document. Introspective scope of execution prevents software from accessing other software for which it does not contain a reference and is similar to traditional object orientation, except this property is exhibited by the hardware itself.

The Kernel-Image (see Appendix G for an explanation on the Kernel-Image that is derived from this patent) has only one instruction to obtain a new reference - known as Get-Child, 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 Kernel-Image.

GENERATES REVENUE FROM HARDWARE

This Ill-Model Candidate forces all Digital-Businesses (8800 of FIG. 29) to pay for the resource they consume. This drives software into an economic framework where it is financially accountable for its behaviour. There are numerous resources on the Ill-Emulator, some of which include:-

Mass storage, such as a hard disk

Fast storage, such as memory ,

Computational process for which there are multiple forms that may be handled by different dedicated circuits

Bandwidth connectivity with adjacent Nodes (200a-200e of FIG. 2, 380, 395 of FIG. 4). Electrical power trading with adjacent Nodes.

Referring to Figure 2d, it can be seen that the majority of resources are stored on the Node, but power transmission and bandwidth are shared between Node partners (12010a, 12010b, 1201On of FIG. 44 and 12210a, 12210b, 1221On of FIG. 45). FORWARD AND BACKWARDLY COMPATIBLE

This Ill-Model Candidate enables forward and backward compatibility by preventing the Interoperability Layer (101a of FIG. 1 and 202a of FIG. 2) from changing throughout its life and by providing sufficient functionality to manage any mandatory changes at a platform level. Forward and backward compatibility is achieved because the functional architecture of the invention is fixed so new software can execute on old Ill-Emulators and old software can execute on new Ill-Emulators.

DEVICE INDEPENDENCE

The Interoperability Layer (101a of FIG. 1 , 202a of FIG. 2) can be compiled for any Host Platform (6840 of FIG. 20 and 7200 of FIG. 22) with sufficient resource and can run software. Digital-Businesses (8800 of FIG. 29) operate in mechanically identical ways on an identical Interoperability Layer no matter what the underlying Host Platform is, in a similar way that Java and .Net do through machine emulation.

AVOIDS THE VON NEUMANN BOTTLENECK

The architecture is optimised for a hardware implementation where processes can execute in parallel on multiple components in the Ill-Emulator.

REAL-TIME PLATFORM

Digital-Businesses are able to reserve resource in order to obtain guaranteed availability. They can also reserve real-time resource capacity to manage unpredictable demand.

ARCHITECTURE

The invention is an abstract specification designed to provide an optimised implementation in hardware, specifically to avoid the von Neumann Bottleneck but also to provide sufficient degrees of freedom to implement with a wide range of hardware solutions. However, the invention is only a small part of the full deployment. The invention contains multiple independent circuits that can execute in parallel and are known as Emulator-Components. The components and data flows are shown in further detail in Figures 3-8.

In the preferred embodiment there are 12 Emulator-Components:- KERNEL-IMAGE

The Kernel-Image (see Appendix G for an explanation on the Kernel-Image that is derived from this patent) is responsible for storing the state information for everything on the Node including the Governance Layer (101b of FIG. 1 , 202b of FIG. 2 and 6475 of FIG. 18) and every Digital- Business (8800 of FIG. 29). It acts as a storage of Sets and does not include network connectivity, disk storage or memory storage of binary files.

UPT-CYCLER

The UPT-Cycler (1470 of FlG. 10 and 1600 of FIG. 9) is a component responsible for the Primary-Dataflow and computational completeness. The UPT-Cycler engages the other Emulator-Components to achieve parallel execution in hardware. The UPT-Cycler processes each instruction immediately and in parallel with other instructions. If an instruction is unable to be completed in a single iteration known as a Digital-Business-Cycle (DBC), then it is considered asynchronous and is handed over to another dedicated Emulator-Component.

FAST-ABS

The Fast-ABS (6000 of FIG. 16) manages the storage and retrieval of binary data at a high speed and presumably high cost through cache or memory. Binary data can be transferred to the Slow-ABS (5800 of FIG. 15) by the ABS-Bus (6200 of FIG. 17). The Fast-ABS communicates with the 3IP-AVM (17200 of FIG. 58), 3IP-AVMF-Verifier (17025 of FlG. 57 and 23000 of FIG. 74), Human-Communication-Manager (700 of FIG. 6 and 900 of FIG. 5), the Plugin-Manager (7600 of FIG. 24) and the ABS-Bus (6200 of FIG. 17).

SLOW-ABS

The Slow-ABS is identical to the Fast-ABS except it manages slow binary data either across disk or network storage. The Slow-ABS communicates with the Environment-Manager (710 of FIG. 4), the Partner-Channel-Manager (13000 of FIG. 49), the Plugin-Manager and the ABS- Bus.

ABS-BUS

The ABS-Bus allows binary data to the transferred between the Slow-ABS and the Fast-ABS. PARTNER-CHANNEL-WIANAGER

The Partner-Channel-Manager manages communication between adjacent Nodes on the grid network. Digital-Businesses (8800 of FIG. 29) can migrate to Peer Nodes using this component and are reconstructed within the Kernel-Image (see Appendix G) of the adjacent Node.

HUMAN-COMMUNICATION-MANAGER

The Human-Communication-Manager (see Appendix F) interfaces with people through display equipment on Nodes. The Human-Communication-Manager delivers a logical format known as a Mesh-Blueprint that delivers a sensory experience and receives a sensory perception to and from the user.

ENVIRONMENT-MANAGER

The Environment-Manager (710 of FIG. 4) probes the underlying host platform (6840 of FIG. 20 and 7200 of FIG. 22) to provide - amongst many things:

Critical performance data to the Governance Layer (101b of FIG. 1 , 202b of FIG. 2 and 6475 of FiG. 18) so that the real-time properties of the Interoperability Layer (101a of FIG. 1 and 202a of FIG, 2) may be maintained. Timing signals from the system clock.

ASYNCHRONOUS-DUPLICATOR

The Asynchronous-Duplicator (440 of FIG. 3) manages the duplication of Sets so as not to overload the UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9).

PLUGIN-MANAGER

The Plugin-Manager (7600 of FIG. 24) provides an opportunity for 3IP (see 3IP-lnterface at 17000 of FIG. 57) developers to integrate specialised hardware into the invention and still maintain absolute security by preventing references from being exchanged with components that are not trusted that are developed by third parties. ASYNCHRONOUS-VIRTUAL-MACHINE-QUEUER

The Asynchronous-Virtual-Machine-Queuer (410 of FIG. 3) acts as a store for precompiled jobs that are ready to execute in the 3IP-AVM (17200 of FIG. 58) of the 3IP-lnterface (17000 of FIG. 57).

AVMF-VERIFY-QUEUER

The AVMF-Verify-Queuer (490 of FIG. 3) acts as a store for unverified executable jobs that are ready to be verified in the 3IP-AVMF-Verifier (17025 of FIG. 57 and 23000 of FIG. 74) of the 3IP-lnterface (17000 of FIG. 57).

3IP-AVM

The 3IP-AVM (17200 of FIG. 58) provides an opportunity for efficient execution utilising the von Neumann architecture under a closed scope to guarantee security.

3IP-AVMF-VERIFIER

The 3IP-AVMF-Verifier (17025 of FIG. 57 and 23000 of FIG. 74) ensures that jobs destined for the 3I P-AVM are of the correct form and adhere to the Asynchronous-Virtual-Machine-Format or AVMF (see Appendix E).

BRIEF DESCRIPTION OF THE DRAWINGS

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

FIG. 1

FIG. 1 shows the invention - the Interoperability Layer (101a) - an abstract platform in the context of an exemplary deployment as sandwiched between the Governance Layer (101b) and the Host Platform Layer (101z). However, the Host Platform Layer (101z and 202z of FIG. 2) can be avoided if the invention is implemented directly in hardware. The stack is shown as an isolated unit as it conforms to the 4-layered model proposed by Dr Fielden with the function of each layer summarised. This stack is unengaged to the peer-to-peer network. FIG. 2

FIG. 2 shows the invention - the Interoperability Layer - (202a) as an exemplary deployment across a peer-to-peer network. The invention is configured by running on a Host Platform Layer (202z) - such as the Java Virtual Machine - and supports a Governance Layer (202b) and Information Layer (202c). Collectively, this stack forms a Node (200a) when coupled with partnership connections with other Nodes (200b, 200c, 20Od and 20Oe).

FIG. 3

FIG. 3 shows a Digital-Business (8800 of FIG. 29) as it moves in a loop where it exists in states Digital-Business-Q1 (335), Digital-Business-Q2 (340) and Digital-Business-Q3 (345). The Ill- Model Candidate ensures that the Digital-Business can transcode in form from one Node (310, 320 and 325) to another endlessly in a super-conductive fashion without increasing in size with each loop or degrading the integrity of its logical behaviour.

FIG. 4

FIG. 4 shows the high level behaviour of a Node (380) and its connectivity to other Node Partners (395). Nodes can transmit bandwidth (385) and electricity (390) to each other - via the Partner-Channel-Manager (13000 of FIG. 49). Other resources - Plugin-Customised- Transmission (396) - can also be transmitted via the Plugin-Manager (7600 of FIG. 24) involving continuous delivery such as oil or water or quantum delivery such as rail.

FIG. 5

FIG. 5 shows the Primary-Dataflow of the invention as the UPT-Cycler (470) passes instructions to the Asynchronous-Duplicator (440), Asynchronous-Virtual-Machine-Queuer (410), ABS-Bus (420) and AVMF-Verify-Queuer (490). Each Emulator-Component is able to process tasks asynchronously. The UPT-Cycler attempts to process all instructions from a Digital-Business (8800 of FIG. 29) stack immediately, but some - such as a recursive copy - have an unknown processing requirement and must be performed asynchronously. These asynchronous tasks that are generated by the UPT-Cycler (1600 of FIG. 11 and 1470 of FIG. 8) are sent to the appropriate Emulator-Components (FIGs. 3-8) across a bus known as the UPT-Execution- Interface (475 of FIG. 5 and FIG. 67). FIG. 6

FIG. 6 shows the Kl-Dataflow that operates buses to a number of Emulator-Components that are connected to the Kernel-Image (680). Each bus presents the Kl-lnterface (685 of FIG. 6 and FIG. 77) these Emulator-Components include the ABS-Bus (620), Partner-Channel- Manager (630), Asynchronous-Duplicator (640), 3IP-AVM (760), Fast-ABS (650), Human- Communication-Manager (700), Environment-Manager (710), UPT-Cycler (670) and Plugin- Manager (720). The Kl-lnterface (see FIG. 77 and Appendix C) enables access to the collection of sets inside the Kernel-Image (see Appendix G), while ensuring that scope protection is preserved at a hardware level. This means that sets are unable to locate their Parents, but can modify any of their Children. Although each Emulator-Component with Kl- lnterface access is treated at the same level of trust as the Kernel-Image itself, the protection offered is absolute and circumvents accidental coding or engineering errors. This scope protection propagates up the stack and can be relied upon by Digital-Businesses (8800 of FIG. 29) that prevents any form of malware.

FIG. 7

FIG. 7 shows the ABS-Dataflow that enables 64-bit blocks of data of logically unlimited length to be transferred across multiple buses to various Emulator-Components (FIGs. 3-8). The ABS- Dataflow contains both a high speed and a low speed type of bus. The high speed bus transmits 64-bit blocks between the Fast-ABS (6000 of FIG. 16) and the 3IP-AVM (960), ABS- Bus (820), 3IP-AVMF-Verifier (970), Human-Communication-Manager (900) and Plugin- Manager (920). The low speed bus transmits 64-bit blocks between the Slow-ABS and the Partner-Channel-Manager (830), ABS-Bus (820), Environment-Manager (910) and Plugin- Manager (920). Both the high speed and low speed bus use the same logical access mechanism known as the ABS-lnterface (855 and 865).

FIG. 8

FIG. 8 shows the lO-Dataflow that involves information entering and leaving the invention. Each data stream operates physically on its own bus and utilises its own logical communications protocol. The UPT-Cycler (1070) utilises the Permanent-Storage-A (113Of), which is undefined and can represent anything from a hard drive to a network connection. The Partner-Channel-Manager (1030) utilises the PCM-lnterface (1130a) that enables connections to multiple Node Partners (12010a, 12010b, 1201On of FIG. 44 and 12210a, 12210b, 1221On of FIG. 45). The PCM-lnterface (130125 of FIG. 49) has its behaviour defined as an interface definition (see Appendix C), but its actual implementation is abstract and so is undefined - enabling it to be implemented across any transport layer. The Human-Communication-Manager (1100) receives sensory perception data and transmits sensory experience data to the display equipment (see Human-Communication-Manager). The Environment-Manager (1110) receives data from the Host Platform Layer (101z of FIG. 1 and 202z of FlG. 2) in an implementation specific manner and so is undefined. The Plugin-Manager (1120) receives data from the individual Plugins via the Plugin-Farm (7660 of FIG. 24) as well as any power or physically transmitted material involved in the Plugin-Customised-Transmission (396 of FIG. 4)

FIG. 9

FIG. 9 shows the start up sequence for the invention. The UPT-Cycler (1270) assumes the role as the start up co-ordinator and engages the invention in 2 stages. Stage 1 involves priming the Kernel-Image (1280) so that other Emulator-Components (FIGs. 3-8) can utilise it during their start up routines. Stage 2 involves starting all the other Emulator-Components and ends with the UPT-Cycler starting itself so as to provide computation for Digital-Businesses (8800 of FIG. 29).

FIG. 10

FIG. 10 shows the Event-Triggered-Dataflow where events are generated by the Kernel Image (see Appendix G) when they have been previously set up by software executing via the UPT- Cycler (1470 of FIG. 10 and 1600 of FIG. 9). There are 2 types of events. The first simply executes additional software inside the UPT-Cycler and the second transmits the event to a physical Emulator-Component including: Asynchronous-Virtual-Machine-Queuer (1410), Partner-Channel-Manager (1430), Asynchronous-Duplicator (1440), ABS-Bus (1420), AVMF- Verify-Queuer (1490), Human-Communication-Manager (1500), Environment-Manager (1510) and Plugin-Manager (1520).

FIG. 11

FIG. 11 shows the UPT-Cycler (1600), which provides access to computation for Digital- Business (8800 of FIG. 29) residing in the Information Layer (101c of FIG. 1) as well as software executing in the Governance Layer (101 b of FIG. 1 , 202b of FIG. 2 and 6475 of FIG. 18). The UPT-Cycler manages the start up sequence of the invention and continues executing once this is completed. The UPT-Cycler also manages the shutdown sequence. During its operation, the UPT-Cycler will transmit events to various Emulator-Components (FIGs 3-8) or execute additional software that has been triggered by these events. The UPT-Cycler utilises a high priority bus to the Kernel-Image (1690) to optimise its processing. FIG. 12 FIG. 12 shows the Kl-Switcher (1800) that operates as the core processor of the UPT-Cycler to process Digital-Business-Cycles. The Kl-Switcher contains a Digital-Business-Selector (1810) and numerous Item-Processors (1820, 1830 and 1840). The Digital-Business-Selector determines which Digital-Businesses are to be processed in a manner that is consistent with the Resource-Model. The Item-Processors (2480a, 2480b, 248On of FIG. 13) process a single UPT either immediately; or over a number of iterations if the operation cannot be completed in a single Digital-Business-Cycle.

FIG. 13

FIG. 13 shows the Digital-Business-Selector (2400 and 1810 of FIG. 12) that is responsible for determining which Digital-Business to process. The Digital-Business-Selector provides a new Digital-Business Cursor-Identification (2490) each time it receives the Item-Processor- Notification (2470). The Digital-Business-Selector ensures that the marketplaces are satisfied in the following order: Realtime, Prepaid, Standby, Idle and Background as per the Resource- Model. It ensures that each Digital-Business is assigned to the same Item-Processor so as to prevent the need to swap sets from one Isolated-Memory-Segment (9600a, 9600b, 9600c and 960On of FIG. 32) to another in the Kernel-Image (see Appendix G), where each Isolated- Memory-Segment may serve a single Kl-lnterface bus.

FIG. 14

FIG. 14 shows the structure of a Monitor (5200) that is a mechanism whereby software can be made aware of changes to specific Children. Monitors can be set by Emulator-Components (FIGs 3-8), in which case the Type of the ET-lnstance (5220) will be of Type-Emulator- Component (see Appendix A) and the Whole and Float values of the ET-lnstance are used to indicate which event triggered the Monitor. Otherwise the ET-lnstance is the Thread-Instance (10485a, 10485b, 10485n of FIG. 36 and 10600 of FIG. 37), which holds five Stacks on which the UPTs held in the DB-Event (5230) will be processed. Monitors may be processed in parallel therefore each MG-Capture-lnstance (5295) in the Event-Parameters-List (5295) are the Event- Parameters that represent the state of the Parent at the time the Monitor was triggered. See Appendix G for explanation of Monitors. FIG. 15

FIG. 15 shows the Slow-ABS (5800) that operates as an abstract mass storage mechanism, probably utilising a hard disk or network for physical storage during implementation and is known as Permanent-Storage-B (5805). The Slow-ABS has 4 buses that each use the ABS- lnterface (5820) that connect to the ABS-Bus (5830), Partner-Channel-Manager (5840), Environment Manager (5850) and Plugin-Manager (5855).

FIG. 16

FIG. 16 shows the Fast-ABS (6000) that operates as a fast and transient store of data. It differs from the Slow-ABS (5800 of FIG. 15) in that the data store is on board the Fast-ABS, Emulator- Component (FIGs. 3-8) and is known as the Fast-ABS-Store (6011). The Fast-ABS communicates with 4 buses using the ABS-lnterface (6020) to the 3IP-AVM (17200 of FIG. 58), the Human-Communication-Manager (6060), the AVMF-Verifier (6040) and the ABS-Bus (6050).

FIG. 17

FIG. 17 shows the ABS-Bus (6200) as it operates as a fast bus between the Fast-ABS (6000 of FIG. 16) and the Slow-ABS (5800 of FIG. 15). The ABS-Bus enables 64-bit data blocks to be transferred directly from Fast-ABS to Slow-ABS and vice versa.

FIG. 18

FIG. 18 shows the Powerset (6400) in the Kernel-Image (Appendix G), which is the outermost set in the universe and can be accessed with the Kl-lnterface (FIG. 77 and Appendix C) instruction Get-Powerset. The Powerset contains the Governance-Layer-Superstructure (6410) as its immediate Child for security reasons the Governance-Layer-Superstructure operates as the Governance Layer (101b of FIG. 1 , 202b of FIG. 2, 6475 of FIG. 18) in Dr Fielden's 4 Layered Ill-Model.

FIG. 19

FIG. 19 shows the Governance-Boot-Instance (6600a) that is the first executable code to be launched during the boot up of the Ill-Emulator. The Governance-Boot-Instance has access to the Governance-Layer-Superstructure (6615 of FIG. 19 and 6410 of FIG. 18), so as to gain full access to the Governance Layer (101 b of FIG. 1 , 202b of FIG. 2, 6475 of FIG. 18). FIG. 20

FIG. 20 shows the Global-Static-Store (6800) that is a reference used by the Governance Layer to store shared information that it generates for multiple Digital-Businesses. The Global-Static- Store (also 6440 of FIG. 18) is part of the Governance-Layer-Superstructure (6410 of FIG. 18). Data moving through the Kl-lnterface with references in the Global-Static-Store are forced to utilise the Backplane-Bus (see Appendix G - 2900 of FIG. G1) so as to escape the Isolated- Memory-Segment (9600a, 9600b, 9600c and 960On of FIG. 32) associated with each Digital- Business (8800 of FIG. 29). The Global-Static-Store operates as an access point between the Interoperability Layer (101a of FIG. 1 and 202a of FIG. 2) and the Governance Layer (101b of FIG. 1 , 202b of FIG. 2, 6475 of FIG. 18).

FIG. 21

FIG. 21 shows the Transport (7010), which is a Child of the Global-Static-Store. The Transport enables communication between Digital-Businesses on Node partners through the Governance Layer.

FIG. 22

FIG. 22 shows the Host Platform (7200 of FIG. 22 and 6840 of FIG. 20) of the Global-Static- Store (6800 of FIG. 20 and 6440 of FIG. 18) that stores data related to the platform hardware.

FIG. 23

FIG. 23 shows the Plugin-Powerset (7400 of FIG. 23 and 6858 of FIG. 20) as provided by the Plugin-Manager (7600 of FIG. 24) when a new connection is made to a Plugin. The Governance Layer (101 b of FIG. 1 , 202b of FIG. 2 and 6475 of FIG. 18) inserts the ILI-Plugin- lnstance (7410 of FIG. 23 and 6859 of FIG. 20) to enable the authorisation of the Plugin (7665a, 7665b and 7665n of FIG. 24) on behalf of a Digital-Business (8800 of FIG. 29).

FIG. 24

FlG. 24 shows the Plugin-Manager (7600) that enables the Ill-Emulator to accept new Plugin components without compromising the security of the Ill-Emulator. This is useful, because third parties may develop Plugins without risk of undermining the integrity of the Ill-Emulator. It is not necessary to verify Plugin integrity as all references that are utilised inside the Plugin- Powerset (6858 of FIG. 20 and 7400 of FIG. 23) are translated into a closed set of handles for the actual Plugin hardware available in the Plugin-Farm (7660).

FIG. 25

FIG. 25 shows the Digital-Business-Execution-Sequence (8000 of FIG. 25 and 6810 of FIG. 20) that is used by the Digital-Business-Selector (2400 of FIG. 13 and 1810 of FIG. 12) to determine the next Digital-Business (8800 of FIG. 29) to process (see Digital-Business-Selector) by the Item-Processor (1840, 1830 and 1820 of FIG. 12).

FIG. 26

FlG. 26 shows the Realtime-Sequence (8200) that is a Child of the Digital-Business-Execution- Sequence (6810 of FIG. 20 and 8000 of FIG. 25). The Realtime-Sequence allows Digital- Businesses (8800 of FIG. 29) with an RCS-ltem (8235a, 8235b and 8235n of FIG. 26) in the Realtime-Computation-Schedule (8220 of FIG. 26) to receive priority processing ahead of all other Digital-Businesses.

FIG. 27

FIG. 27 shows the Prepaid-Sequence (8400) that is a Child of the Digital-Business-Execution- Sequence (6810 of FIG. 20 and 8000 of FIG. 25). The Prepaid-Sequence allows Digital- Businesses (8800 of FIG. 29) with PCS-ltems (8435a, 8435b, 8435n of FIG. 27) in the Prepaid- Computation-Schedule (8420 of FIG. 27) to receive priority processing ahead of all other Digital- Businesses, once the Digital-Businesses in the Realtime-Sequence (8200 of FIG. 26) have been processed.

FIG. 28

FIG. 28 shows the PCS-ltem (8600a and 8600b) and the RCS-ltem (8700a and 8700b) as used by the UPT-Cycler's (1470 of FIG. 10 and 1600 of FIG. 9) Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) to determine the next Digital-Business (8800 of FIG. 29) to receive computation. The PCS-ltem shows the detail on the Pl-Prepaid-Release (8630a and 8630b) that enables a PCS-ltem to be deleted from its schedule, regardless of where it is located in the schedule. FIG. 29

FIG. 29 shows a Digital Business (8800) that operates as a mobile-agent on a Node (200a-200e of FIG. 2, 380 and 395 of FIG. 4). A Digital-Business is characterised by being an isolated unit of software that is unable to be affected by other Digital-Businesses on the same Node, either directly by reference modification or indirectly through resource fluctuation induced by massive consumption by other Digital-Businesses. A Digital-Business contains an entire copy of the Governance Layer (101b of FIG. 1 , 202b of FIG. 2 and 6475 of FIG. 18) so as to enable parallel execution when implemented in a Field Programmable Gate Array- (FPGA) fabric. Digital- Businesses have their own bank account represented by the Bank-Account-Field (8890 of FIG. 29) and are removed from the Node once they become insolvent. Digital-Businesses are able to propagate from Node to Node.

FIG. 30

FIG. 30 shows the DB-Resource-Release (9200) that is used by the Item-Processor (2480a, 2480b and 248On of FIG. 13) to remove RCS-ltems (8700a and 8700b of FIG. 28) in the Realtime-Computation-Schedule (9240 of FIG. 30 and 8220 of FIG. 26) and Digital-Businesses (9255, 9265 of FIG. 30 and 8800 of FIG. 29) from the Standby-Computation-Schedule (9250 of FIG. 30 and 8040 of FIG. 25) and the Idle-Computation-Schedule (9260 of FIG. 30 and 8050 of FIG. 25) when the Stacks (10610, 10620, 10630, 10640 and 10650 of FIG. 37) are empty. These items are removed from the schedule regardless of their location.

FIG. 31

FIG. 31 shows the DB-Execution (9400) that forms part of the Digital-Business (8800 of FIG.

29) that contains all runtime information for the Digital-Business. The behaviour of the Digital- Business is determined by the Design-Time-Execution (9420) while the Operating System support is provided in the Governance-Execution (9430). The Super-Stacks (9410) are used to process Monitors (5200). The Activity-Status-Field (9440) is used to lock the Digital-Business. The Realtime-Reservation (9450) manages on-demand supplier resource. The Maximum- Volume (9460) specifies the maximum amount of resource this Digital-Business can obtain.

FIG. 32

FIG. 32 shows how an individual Digital-Business (8800 of FIG. 29) is allocated to a single Isolated-Memory-Segment (9600a, 9600b, 9600c, 960On) in the Kernel-Image (see Appendix G). The Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) ensures that the same Item-Processor (1820, 1830, 1840 of FIG. 12) manages a single Digital-Business. Each Item- Processor has access to a single Isolated-Memory-Segment so as to allows execution in parallel.

FIG. 33

FIG. 33 shows the DTE-lnstance (9800a) that manages the behaviour of the Digital-Business (8800 of FIG. 29) and is the result of the design-time compilation of the Digital-Business source code. The DTE-lnstance is likely to have a reference to itself (9800b) so that it can access the DB-Data (9845) that operates as an onboard hard drive or permanent storage. The Governance-Layer-lnterface-Field (9810) contains a reference to the Governance-Layer- Interface (9815) that enables the Digital-Business to communicate with the Governance Layer (101b of FIG. 1, 202b of FIG. 2 and 6475 of FIG. 18). The DTE-Boot-Drop-Field (9820) contains the Boot-Drop-Instance (9825 and see FIG. 35 below) that contains five Children that determine the point of entry for this Digital-Business once it is loaded from Permanent-Storage- A (113Of of FIG. 8 and 1700 of FIG. 9) by the UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9). The Active-Thread (9830) contains the runtime component of the DTE-lnstance and the DB- Boot-Field (9850) contains Object-Orientated support in the Boot-Data-Set (9855) for parameters during propagation across Nodes (200a-200e of FIG. 2, 380 and 395 of FIG. 4).

FIG. 34

FIG. 34 shows the GE-lnstance (10000a) that manages the Operating System that services requests for a single DTE-lnstance (9800a of FIG. 33). The Govemance-Layer-Superstructure- Field (10010) contains a reference to the Governance-Layer-Superstructure (10015) that enables the Operating System to access everything below the Powerset (6400 of FIG. 18) including the entire Governance-Layer (6475 of FIG. 18). The Global-Static-Store-Field (10020) contains a reference to the Global-Static-Store (6440 of FIG. 18, 6800 of FIG. 20 and 10025 of FIG. 34) that stores shared information across all GE-lnstances running on the Node. The Every-Digital-Business-Spawned-Field (10030) contains a reference to the Every-Digital- Business-Spawn (10035) that is a spawned Cursor to this executing Digital-Business inside Every-Digital-Business (6450 of FIG. 18) to enable the GE-lnstance to know which Digital- Business it must service. The GE-Boot-Drop-Field (10040) contains the Boot-Drop-Instance (see FIG. 35 below) that determines the entry points for the Governance Layer (101 b of FIG. 1, 202b of FIG. 2) execution. FIG. 35

FIG. 35 shows the Boot-Drop-Instance (10200) that contains five entry points for either the

DTE-lnstance (9800a and 9800b of FIG. 33) or the GE-lnstance (10000a and 10000b of FIG. 34). Each entry point is a Universal-Process-Type or UPT (see Appendix B) that when placed on the Stack will begin execution. The five stacks represent five marketplaces as conforming to the Resource-Model (see Resource-Model). The BDI-Realtime-Field (10210) contains a UPT for the realtime stack. The BDI-Prepaid-Field (10220) contains a UPT for the prepaid stack.

The BDI-Standby-Field (10230) contains a UPT for the standby stack. The BDI-ldle-Field (10240) contains a UPT for the idle stack. The BDI-Background-Field (10250) contains a UPT for the background stack.

FIG. 36

FIG. 36 shows the Thread-Group (10400) as found in the Active-Thread (10050 of FIG. 34 and 9830 of FlG. 33) of either the GE-lnstance (10000a of FIG. 34) or the DTE-lnstance (9800a of FIG. 33). The Active-Thread determines the execution configuration for either the GE-lnstance or DTE-lnstance structure. By shifting the Cursor in the Active-Thread, a different Thread- Group is selected to receive all the computational power. The Thread-Group itself contains the Active-Stacks (10410) or the Threads (10420). The Threads contains a Thread-List (10480) that lists clusters of threads of execution within the DTE-lnstance or GE-lnstance structure. The Active-Stacks contains spawned references to the threads to enable processing to be distributed quickly according to the Resource-Model (see Resource-Model).

FIG. 37

FIG. 37 shows the Thread-Instance (10600) as 5 threads of execution and is found in either one of the Active-Stacks (10410 of FIG. 36) or as listed in the Thread-List (10480 of FIG. 36). The Thread-Instance contains five stacks as per the Resource-Model (see Resource-Model). Each stack contains a series of UPTs that represents the state of computation and represents a single Thread of execution.

FIG. 38

FlG. 38 shows the UPT-Method (10800 and see Appendix B) that is responsible for the creation of a method frame. Each method frame is able to access software delivered by the Startup- UPT (11336 of FIG. 41) of the Method-Call-ltem (11326 of FIG. 41 and 10830 of FIG. 38). Software is executed from the Pseudo-Stack (10880), which operates as a normal stack. However, when a Value inside a Field contains a type of Type-lnputs-Field, Type-Locals-Field, Type-Outputs-Field, Type-Global-Field or Type-Static-Field (see Appendix A), then the UPT- Method ensures that the actual value for this variable is looked up from within the method frame. This mechanism splits the Data Segment (DS) and Code Segment (CS). .

FIG. 39

FIG. 39 shows the Boot-Data-Set (11000) that is inserted into the DB-Boot-Field (9850 of FIG. 33) during Digital-Business (8800 of FIG. 29) propagation via the Partner-Channel-Manager (13000 of FIG. 49). The Boot-Data-Set contains a list of unlinked Object Orientated classes in the Unlinked-Class-List (11010). It is responsibility of software executing in the Boot-Drop- Instance (9820 of FIG. 33 and 10200 of FIG. 35) to link and execute software contained in the Unlinked-Class-List (11010). The Type-Of-Boot-Field (11035) will indicate if this is a DTE- lnstance (9800a of FIG. 33) or GE-lnstance (10000a of FIG. 34) boot. The Parameter-Field (11045) contains any additional parameters to be used during booting.

FIG. 40

FIG. 40 shows the Variable-Definitions (11200) that are used in the separation of the Code Segment and the Data Segment when creating a method frame for use in Object Orientated support. The Index-Start-Point (11230, 11270 and 11310) are used to store all the values for this variable as used across every method frame. The actual value that is utilised is referenced via an index and performed in situ during UPT execution.

FIG. 41

FIG. 41 shows the Method-Call-Item (11326) that represents the life of a method from the moment it is called to the moment it exits. The Method-Call-ltem is placed on the stack and will automatically generate a UPT-Method (11350 of FIG. 42) that continues execution in the new method frame.

FIG. 42

FIG. 42 shows the UPT-Method (11350) that contains executable software in a method frame and is generated by the Method-Call-ltem (11326 of FIG. 41). The UPT-Method contains a Pseudo-Stack-Field (11351) where execution occurs on the Pseudo-Stack (11352) instead of on the real stack in which the UPT-Method is contained. The UPT-Method exits when the Pseudo-Stack is empty, at which point the UPT-Method is removed from the stack and execution continues normally again on the real stack. The Method-Values-Field (11353), Object-Field (11355) and Static-Variable-List-Field (11357) are used to dynamically look up actual variable values in the Data Segment for the method frame.

FIG. 43

FIG. 43 shows the Object (11800) that represents an instantiation of a class. Classes compile into Unlinked-Class-ϋsts (11010 of FIG. 39). Prior to instantiation, the Unlinked-Class-ϋst needs to be linked so that the UPTs they contain can execute on the stack.

FIG. 44

FIG. 44 shows the Ill-Model (12000) with multiple Nodes (12010a, 12010b and 1201On). Each Node contains a Ill-Emulator (12021 , 12031 and 12041) and a Governance Layer (101 b of FIG. 1 and 202b of FIG. 2). Each Node is connected by a pair of PCM-I nterfaces (12056, 12066 and 12076).

FIG. 45

FIG. 45 shows the Ill-Model (12200) in a different view from that of FIG. 44. FIG. 45 shows the Partner-Channel-Manager (12220, 12230 and 12240) that creates an Nl-Partner (12285b and 12305b) for each partner connected to the Node.

FIG. 46

FIG. 46 shows an Nl-Partner (12400) that is created for each partner Node by the Partner- Channel-Manager (13000 of FIG. 49). The Partner-Online (12420) defines the connection between the 2 Nodes. The Node-Transfers-Field (12430) contains a list of DB-Partners (12436a-12436n of FIG. 46 and 13200 of FIG. 50) that enables bandwidth to be transferred by individual Digital-Businesses (8800 of FIG. 29) between Nodes.

FIG. 47

FIG. 47 shows Bandwidth-Bookings (12600) that stores all the Realtime and Prepaid reservations for bandwidth for every Digital-Business (8800 of FIG. 29) on the Node. FIG. 48

FIG. 48 shows the Nl-Partner (12800) that represents a connection to a partner Node (200a-e of FIG. 2 and 380, 395 of FIG. 4). It contains Private-Information (12810) relating to that Node for the Governance Layer's own internal reference and Public-Information (12820) that is made available to the Digital-Businesses (8800 of FIG. 29) on the Node. The difference is academic since the Governance Layer (101 b of FIG. 1 and 202b of FIG. 2) presents the information to the Digital-Businesses anyway.

FIG. 49

FIG. 49 shows the Partner-Channel-Manager (13000) as connected to multiple Nodes (13090, 13110 and 13130). Each connection utilises a pair of PCM-I nterfaces (130125). The Partner- Channel-Manager contains two main components being the Transmitter (13020) and the Scheduler (13030). The Transmitter is responsible for the transmission of bandwidth and electricity between Node partners by encoding the PCM-lnterface in a platform specific manner. The Scheduler is responsible for implementing the Resource-Model in the context of bandwidth and electricity.

FIG. 50

FlG. 50 shows the DB-Partner (13200) that represents a connection by a single Digital- Business (8800 of FIG. 29) to another Digital-Business on a peer Node. The DB-Partner is utilised by the Partner-Channel-Manager (13000 of FIG. 49) during transmission of bandwidth.

FIG. 51

FIG. 51 shows the PCM-Resource-Release (13400) that is used by the Partner-Channel- Manager (13000 of FIG. 49) to release reservations once they have expired.

FIG. 52

FIG. 52 shows the ID-Set (7500) that is used to store 128-bit number by combining two 64-bit Whole numbers from the Black-ID (7515) and the White-ID (7525). FIG. 53

FIG. 53 shows the Transfers (13600) that are used to transfer Prepaid and Realtime reservations by the Partner-Channel-Manager (13000 of FIG. 49). PCM-Transfer-ltems (13816, 13826, 13836, 13846 and 13856) in the Send (13800) are Manabars-Sets awaiting transfer to the peer Node (200a-e of FlG. 2 and 380, 395 of FIG. 4). The PCM-Transfer-ltems (13916, 13926, 13936, 13946 and 13956) in the Receive (13900) have already arrived from the peer Node.

FIG. 54

FIG. 54 shows the Booking-Schedules (14000) as part of Transport (14150 of FIG. 54 and 7010 of FIG. 21). The Booking-Schedules contain Active-Booking-Schedules (14010) that represent reservations that are being processed. The Frozen-Booking-Schedules (13420) represent schedules that are unable to be satisfied due to the DB-Partner being unable to be serviced due to connection failure.

FIG. 55

FIG. 55 shows the Node communication (14200) as part of the Digital-Business (14250 of FIG. 55 and 8800 of FIG. 29). Maintains a list of all DB-Partners that is used to notify all connections if there is a failure in the PCM-lnterface (130125 of FIG. 49).

FIG. 56

FIG. 56 shows the Realtime-Contract-lnstance (14400) and the Prepaid-Contract-lnstance (14500). The Realtime-Contract-lnstance contains all the data for a realtime reservation while a Prepaid-Contract-lnstance represents a prepaid reservation in accordance with the Resource- Model.

FIG. 57

FIG. 57 shows the 3IP-lnterface Dataflow as data moves between the Ill-Common-Context (17035) and the 3IP-lnterface (17000). This figure captures the lifecycle of executable Asynchronous-Virtual-Machine-Format or AVMF (see Appendix E) software. Software is initially verified with the AVMF-Verify-lnterface (17075). After it is verified, it is executed in the 3IP-AVM (17010). The 3IP-AVM checks if verification is successful via the Authorised-AVMF-lnterface (17080). FIG. 58

FlG. 58 shows the 3IP-AVM (17200) that utilises the von Neumann-Processor-Farm (17205) that is controlled by the AVM-Job-Manager (17230). Each executable unit of AVMF code is transmitted to an AVM-Processor (17210a, 17210b and 1721On of FIG. 58 and 17400 of FIG. 59). Once a AVMF job is executing it can access a series of Fast-ABS (17296) sequences and can create new ones, but it does not have access to the Kernel-Image (17290).

FIG. 59

FIG. 59 shows AVM-Processor (17210a, 17210b and 1721 On of FIG. 58 and 17400 of FIG. 59) that is responsible for executing AVMF code in a simplified von Neumann architecture. Each AVM-Processor contains an AP-CPU (17435) that is connected to the Scoped-FABS-lnterface (17495), the AP-Memory (17420) that is an array of 64-bit blocks and the CPU-Stack-Bus (17465). The AP-CPU is responsible for interpreting and executing each Asynchronous-Virtual- Machine-lnstruction or AVMI (see Appendix E).

FIG. 60

FIG. 60 shows the Resource-Pricing (19000) that contains pricing information for each resource available on the invention.

FIG. 61

FIG. 61 shows a Pricing-Item (20000) that determines the Engagement-Fee (20025) to begin using realtime resource. It contains the Usage-Fee (20035) that determines the cost of ongoing use of realtime resource in the Realtime-Marketplace. The Pricing-Item contains the Reimbursement-Price (20050) that is the price paid by the Governance Layer (101b of FIG. 1 and 202b of FIG. 2) to the Digital-Business (8800 of FIG. 29) in the event that the reserved resource is not utilised. The Contract-Transfer-Fee (20060) is the charge for the Digital- Business in the event that it transfers the contract into a promissory note for trading off the local Node (200a-200e of FIG. 2 and 380, 395 of FIG. 4). This fee is charged when another Digital- Business claims the contract with the promissory note. Finally, the Pricing-Item contains Spot- Prices (20070) for the Standby-Marketplace (20075), Idle-Marketplace (20085) and Background-Marketplace (20095). FIG. 62

FIG. 62 shows the PCM-Connection-Request-lmage (21000) that is inserted into the PCM- Notify (7065 of FIG. 21) to propagate a Digital-Business (8800 of FIG. 29) to a peer Node partner (12010a, 12010b, 1201On of FIG. 44 and 12210a, 12210b, 1221On of FIG. 45). Specifically, the PCM-Connection-Request-lmage forms the Digital-Business by supplying an entire DTE-lnstance (9800a of FIG. 33) image. This generic mechanism can be used to transport Digital-Businesses created by exotic languages or alternative environments that may be developed in the future.

FIG. 63

FIG. 63 shows the PCM-Mapped-Set (21100) that is likely to be used by the Governance Layer (101b of FIG. 1 , 202b of FIG. 2) to track mapped sets between Digital-Businesses (8800 of FIG. 29) on the local Node () and Node partner (12010a, 12010b, 1201On of FIG. 44 and 12210a, 12210b, 1221On of FIG. 45). For example, if a Digital-Business requests a propagation, a reference to the propagation can be structured as a PCM-Mapped-Set which is mapped using the UPT-Map (see Appendix B). After propagating to the peer Node, the PCM-Mapped-Set behaves like an Entangled-Set (13295) so that the DB-Partner-Field (21110), DB-Reference- Field (21130) and the Peer-Node-Field (21150) no longer exist so that the PCM-Mapped-Set contains no Children. At any point if the peer Node reuses this reference and transmits it to the local Node, the PCM-Mapped-Set will be restored. In this manner the PCM-Mapped-Set information can be held private but the peer Node is able to utilise the reference to identify the set without gaining access to its contents. Therefore, the contents of the PCM-Mapped-Set are not transferred in the PCM-lnterface (130125 of FIG. 49).

FIG. 64

FIG. 64 shows the PCM-Connection-Request-Object-Orientatiόn (21200) and performs a similar role to the PCM-Connection-Request-lmage (21000 of FIG. 62) by creating a new Digital- Business (8800 of FIG. 29) on a peer Node (200a-e of FIG. 2 and 380, 395 of FIG. 4). The DTE-lnstance (9800a of FIG. 33) of the target Digital-Business is constructed automatically and the executable software is derived from a cluster of unlinked classes via the Unlinked-Class- List-Field (21270). FIG. 65

FIG. 65 shows the PCM-Connection-Result (21400) that is returned after a propagation request has been made through the PCM-Notify (7065 of FIG. 21). ^"

FIG. 66

FIG. 66 shows PCM-Transfer-ltem (21600) that is used to transmit sets to a specific Digital- Business (8800 of FIG. 29) on a peer Node (200a-e of FIG. 2 and 380, 395 of FIG. 4).

FIG. 67

FIG. 67 shows the UPT-Execution-lnterface (475 of FIG. 3) that is used in the Primary-Dataflow (see FIG. 3) to transmit UPTs (see Appendix B) to Emulator-Components (FIGs 3-8) for asynchronous processing.

FIG. 68

FIG. 68 shows the Scoped-FABS-lnterface (17240 of FIG. 58 and 17495 of FIG. 59) that is used by the FABS-Access-Manager (17230 of FIG. 58) to allow the reading and writing of Fast- ABS (6000 of FIG. 16) sequences by executing AVMF code via the UPT-AVM (see Appendix B).

FIG. 69

FIG. 69 shows UPT-Event-Triggered-lnterface (1475 of FIG. 8) that is utilised in the Event- Triggered-Dataflow () to deliver Monitor events to Emulator-Components via the Kl-Broadcast (see Appendix G) instruction.

FIG. 70

FIG. 70 shows the PCM-Interface (130125 of FIG. 49) that is responsible for the transmission of Digital-Businesses (8800 of FIG. 29) and data across Nodes (200a-e of FIG. 2 and 380, 395 of FIG.2d). Although the behaviour of the PCM-Interface is specified, the implementation is left undefined to maximise deployment opportunities. FIG. 71

FIG. 71 shows the Execution-Interface (17270 of FIG. 58) that is responsible for transmitting AVMF sequences to the next available AVM-Processor (17210a, 17210b, 1721On of FIG. 58 and 17400 of FIG. 59) for execution.

FIG. 72

FIG. 72 shows the AVM-lnterface (17299 of FlG. 58) that transmits the UPT-AVM (see Appendix B) execution job to the Job-Scheduler (17275 of FIG. 58) of the 3IP-AVM (17200 of FIG. 58).

FIG. 73

FlG. 73 shows the AVMF-Verify-lnterface (23050 of FlG. 74) that transmits the UPT-AVMF to the Verification-Job-Manager (23040 of FIG. 74) so that an AVMF sequence can be verified prior to execution.

FIG. 74

FIG. 74 shows the 3IP-AVMF-Verifier (23000) that processes multiple UPT-AVMF (see Appendix B) UPTs continuously. The 3IP-AVMF-Verifier has numerous verification processors inside the AVMF-Verifier-Farm (23015). Once a sequence has been verified it is stored to the Authentication-Database (23030) to enable the 3I P-AVM (see Appendix B) to assure the sequence integrity via the Verified-AVMF-lnterface (23035).

FIG. 75

FIG. 75 shows the Verification-Processor (23200) that is responsible for verifying the execution ^' integrity of a single AVMF sequence. The sequence is transferred via the Verification-Interface (23270) of the Verification-Job-Manager (23265). The Verification-Processor loads the AVMF sequence into the Proposed-AVMF (23215), configures the Boolean-Land-Array (23220) and Boolean- Jump-Array (23225) before verifying this sequence with the Integrity-Checker (23250). The Integrity-Checker performs a number of tests in parallel as the sequence is scanned. FIG. 76

FIG. 76 shows the Verification-Interface (23270 of FlG. 75) that is used by the Verification- Processor (23200 of FIG. 75) to load the next verification job from the Verification-Job-Manager (23265 of FIG. 75).

FIG. 77

FIG. 77 shows the Kl-lnterface (see Appendix G) that is used by every Emulator-Component (FlGs 3-8) in the Kl-Dataflow (see FIG. 4).

FIG. 78

FIG. 78 shows the ILI-Phenotype-Data (23800 of and 6866 of FIG. 20) that delivers a Sensory- Experience and captures a Sensory-Perception directly to and from the user (see Appendix F).

FIG. 79

FIG. 79 shows an exemplary deployment of the Human-Communication-Manager (24000) that contains multiple sensory channels that can each attend an independent display device.

FIG. 80

FIG. 80 shows an exemplary configuration of the Mesh-Blueprint (24200) as used in the Render-Field (23830 of FIG. 78) of the ILI-Phenotype-Data (23800 of FIG. 78). The Mesh- Blueprint contains the Sensory-Experience.

FIG. 81

FIG. 81 shows the Entity (24400) that delivers a Sensory-Experience and captures a Sensory- Perception for a single entity in the virtual universe.

FIG. 82

FIG. 82 shows the MB-Render-lnformation (24600) that allows multiple sensory data components to be overlayed in a single Sensory-Experience. FIG. 83

FIG. 83 shows the Render-Information (24800) for the sound experience.

FIG. 84

FIG. 84 shows the Render-Information (25000) for the visual experience.

FIG. 85

FIG. 85 shows the Appearance (25200) that is used in the visual experience to define textures, materials, lights, colour and transparency of objects.

FIG. 86

FIG. 86 shows a Texture (25400) that is used to provide texture data for the Texture-Field (25210 of FIG. 85).

FIG. 87

FIG. 87 shows the XYZ-Position-Set (25600) and the RGB-Set (25700). The XYZ-Position-Set is used to store a location in the virtual universe. The RGB-Set is used to define a colour.

CONVENTIONS IN FIGURES

REAL VERSUS VIRTUAL ENTITIES

Kernel-Image 320

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

Parent 1234

Child 546

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 i GLl-lnstance i 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

Kernel-Image

321

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 333b 333n 333a

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

NAMING

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

Tvoe = True

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

INTERFACE CONNECTIVITY

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 A PREFERRED EMBODIMENT

FIG. 2 shows an exemplary system deployment in its full operational context. The invention - a Ill-Model Candidate (102a) is only one component of Node, which is itself only one entity in the grid network. The Nodes (200a - 20Oe OF . FIG. 2 and 380, 395 of FlG. 4) operate as a continuum of homogeneous hosts on an interconnected peer-to-peer grid network. Each Node may execute a functionally equivalent Governance Layer (102b of FIG. 1^', 202b of FIG. 2, 6475 of FIG. 18) similar to an Operating System. Data may move between Digital-Businesses (8800 of FIG. 29) operating from peer Nodes or Digital-Businesses operating from the same Node. The invention can be extended in a narrow manner to enable a 3IP (see 3IP-lnterface at 17000 of FIG. 57). A 3IP represents an extension of numerous processors of the von Neumann architecture. Code designed to run on the 3IP processors is derived from a series of Abstract Virtual Machine Instructions (AVMI) through a cross-compilation. An entire executable is comprised of a series of AVMIs to form the Asynchronous-Virtual-Machine-Format (AVMF) that is executed in the 3IP-AVM (17200 of FIG. 58). Interoperability is achieved when Digital- Businesses are converted into the correct mechanical format to operate on the desired 3IP Node platform. It is not in the scope of this patent to define the operation of the Node as the Governance Layer (102b of FIG. 1 , 202b of FIG. 2, 6475 of FIG. 18) may obtain almost any configuration although the Information Layer (101c of FIG. 1 and 202c of FIG. 2) behaviour is managed by the Governance Layer it is effectively infinity open. The Governance Layer software and Digital-Businesses (8800 of FIG. 29) resident in the Information Layer must be driven directly by the computation arising from the invention and cannot be generated by an independent process or thread. Therefore, these two highest layers operate virtually to the Interoperability Layer (101a of FIG. 1 and 202a of FIG. 2) within the universe of Sets that is contained in the Kernel-Image (680 of Fig. 4) - see Appendix G for further information as to how the Kernel-Image is constructed.

Information enters and leaves the invention as:

Sets of data or information units referred to in this document as Manabars-Sets (see Appendix G) when Digital-Businesses (8800 of FIG. 29) on Node (200a-200e of FIG. 2, 380 and 395 of FIG. 4) partners on the peer-to-peer network move data to Digital-Businesses on the local Node . Digital-Businesses on Partner Nodes propagate new Digital-Businesses onto the local

Node.

Digital-Businesses on the local Node that move data to other local Digital-Businesses. From state changes delivered by every Digital-Business to the Realtime-Stack (10610 of FIG. 37), Prepaid-Stack (10620 of FIG. 37), Standby-Stack (10630 of FIG. 37), Idle-Stack (10640 of FIG. 37) or Background-Stack (10650 of FIG. 37) as driven by the UPT-Cycler

(470 of FIG. 3) that includes activity generated by other Emulator-Components (FIGs 3-8). From sources native to the implementation of the invention handled by the Environment- Manager (510 of FIG. 3) - for example, feedback relating to the availability of resources on the implementation platform. From sensory data compiled by the Human-Communication-Manager (500 of FIG. 3) as it interacts with the user. The data is made available to the virtual Governance Layer (101b of FIG. 1 , 202b of FIG. 2 and 6475 of FIG. 18) and the appropriate Digital-Business (8800 of FIG. 29) in the Information Layer (101c of FIG. 1 and 202c in FIG.2). HIGH LEVEL ARCHITECTURE OF THE SYSTEM

Below is a summary of every functional component of a Node (200a-e of FIG. 2, 380 and 395 of FIG. 4) : -

3IP-INTERFACE

An abstract definition that allows for the construction of a 3IP. This Ill-Model Candidate does not include a definition for the components that implement the 3IP-interface (17000 of FIG. 57). Any 3IP must implement the 3IP-lnterface by fully implementing the Ill-Common-Context (400 of FIG. 5 and 17035 of FIG. 57) as well as a valid 3IP-AVM (17200 of FlG. 58) and corresponding 3IP-AVMF-Verifier (17025 of FIG. 57 and 23000 of FIG. 74).

III-EMULATOR

The Ill-Emulator assumes the role of the Interoperability Layer (101a of FIG. 1 , 202a of FIG. 2) and executes as a multi-threaded application on top of the Host Platform Layer (202z of FIG. 2). The components inside the Ill-Emulator are Emulator-Components (FIGs 3-8) and are each able to operate in parallel. The Ill-Emulator is optimised for a physical implementation, such as in Field Programmable Gate Arrays (FPGA) as opposed to a software or logical implementation. However, Ill-Emulators for alternative software environments will operate perfectly, albeit slower.

HOST PLATFORM LAYER

The Host Platform Layer (202z of FIG. 2) is the platform on which the Ill-Emulator executes. This may be hardware or software, the only requirement is that the Host Platform (6840 of FIG. 20 and 7200 of FIG. 22) is capable of computational completeness and has full-time network access to service Node (200a-e of FIG. 2, 380 and 395 of FIG. 4) partners.

KERNEL-IMAGE

The Kernel-Image (see Appendix G) contains a persistent store of information units called Manabars-Sets. The Kernel-Image provides an interface called the Kl-lnterface (see FIG. 77) for the manipulation of information units. POWERSET

The Powerset (6400 of FIG. 18) is the outermost Manabars-Set (see Appendix G) contained within the Kernel-Image and contains every other Manabars-Set.

UPT-CYCLER

The UPT-Cycler (470 of FIG. 3, 1470 of FIG. 10 and 1600 of FIG. 9) uses the Kl-lnterface (see FIG. 77 and Appendix G) to manipulate special Manabars-Sets (see Appendix G) known as Universal-Process-Types or UPTs (see Appendix B) that enable computational completeness. The UPT-Cycler processes each UPT immediately, . either through the Kl-lnterface synchronously, or for more complex UPTs by forwarding them to the Asynchronous-Virtual- Machine-Queuer (410 of FIG. 3), AVMF-Verify-Queuer (490 of FIG. 3), ABS-Bus (420 of FIG. 3) or the Asynchronous-Duplicator (440 of FIG. 3) by using the UPT-Execution-lnterface (475 of FIG. 3, 1635 of FIG. 11 and Appendix C for the Interface-Definition). The UPT-Cycler will determine the actual execution speed or power rating of the Ill-Emulator, which is measured by the number of UPTs executed each second. This rate is also referred to as Digital-Business- Cycles per second (DBC/s). Digital-Businesses (8800 of FIG. 29) may be locked by these asynchronous Emulator-Components (FIGs 3-8) to prevent corruption of data.

ASYNCHRONOUS-VIRTUAL-MACHINE-QUEUER

The Asynchronous-Virtual-Machine-Queuer (410 of FIG. 3) stores a queue of executable jobs awaiting processing by the 3IP-AVM (17200 of FIG. 58).

3IP-AVM

The 3IP-AVM is a virtual computing framework that enables the execution of the Asynchronous- Virtual-Machine-Format or AVMF (see Appendix E) that is optimised for implementation on generic and conventional 64-Bit chipset architectures. During run-time the AVMF uses Abstract-

Virtual-Machine-lnstructions (AVMIs) to transfer information between the 3IP-AVM and the Fast-

ABS and to manipulate information within the 3IP-AVM through the utilisation of a stack and the

PI-CPU. A related component called the AVMF-Verifier () converts special UPTs used for compiling called AVMI-UPTs into instructions native to the Host Platform Layer (202z of FIG. 2 and 101z of FIG. 1) by using the UPT-AVMF-Verify UPT (see Appendix B). AVMF-VERIFY-QUEUER

The AVMF-Verify-Queuer (490 of FIG. 5 and 23010 of FIG. 74) queues jobs that verify the integrity of code that is to execute at some point on the 3IP-AVM (17200 of FIG. 58).

AVMF-VERIFIER

The AVMF-Verifier (23020a, 23020b, 23020c of FIG. 74 and 23200 of FIG. 75) converts Abstract-Virtual-Machine-lnstructions or AVMIs (see Appendix E) into native binaries that are executable in the 3IP-AVM (560 of FIG. 5 and 17200 of FIG. 58). Executable jobs are queued in the Asynchronous-Virtual-Machine-Queuer (410 of FlG. 3) and await processing by the 3IP- AVM. AVMIs are symbols that represent an idealistic virtual computing framework and are analogous to machine instructions. Some implements in software environments may compile the Asynchronous-Virtual-Machine-Format (see Appendix E again) into native binaries as part of the verification process so as to reduce the latency during actual execution.

PARTNER-CHANNEL-MANAGER

The Partner-Channel-Manager (430 of FIG. 5 and 13000 of FIG. 49) creates Digital-Businesses (8800 of FIG. 29) on adjacent Nodes (200a-e of FIG. 2, 380 and 395 of FIG. 4) enables communications between a Parent Digital-Business and its propagated Children. The protocol for this transmission is known as the PCM-lnterface (130125 of FIG. 49), but its full implementation is not part of the specification. The security relating to the PCM-lnterface implementation is managed both at a higher level by Digital-Businesses that are ultimately responsible for their own security and at a lower level by the Node that can obtain higher ratings by Routing-Agents if it secures the communication channel between Node partners. Routing- Agents are high level Digital-Businesses that trade navigational data and make recommendations about Node reliability and security to other Digital-Businesses. Digital- Businesses operating in the Information Layer (101c of FIG. 1 and 202c of FIG. 2) may choose to encrypt its transmission to other Digital-Businesses. Nodes may increase their security by physically securing the Host Platform Layer (101z of FIG. 1 and 202z of FIG. 2) and avoiding insecure layers such as a vulnerable Operating System during a software implementation of the Ill-Emulator.

HUMAN-COMMUNICATION-MANAGER

The Human-Communication-Manager (500 of FIG. 5 and Appendix F) communicates with the user through an abstract human body. Inbound information is received as an abstract sensory experience while information generated by the user is encoded as an abstract sensory perception. The entire communication is machine independent and human specific. By not changing the way information is encoded, software can be both forwards and backwards compatible as the application and software that executes on it never change. There is no logical limit to the number of parallel sensory communications that may be processed by the Human-Communication-Manager.

ENVIRONMENT-MANAGER

The Environment-Manager (510 of FIG. 5 and 710 of FIG. 4) senses and provides feedback for workload of the Permanent-Storage-A (113 of FIG. 8 and 1700 of FIG. 9), Kl-Memory (see Appendix G), network bandwidth for the Partner-Channel-Manager (430 of FIG. 5 and 13000 of FIG. 49) and computational process for each Emulator-Component (FIGs 3-8) that is made available by the Host Platform Layer (101z of FIG. 1 and 202z of FIG. 2).

ASYNCHRONOUS-DUPLICATOR

The Asynchronous-Duplicator (440 of FIG. 3) duplicates an entire Manabars-Set (see Appendix G) by temporarily freezing a Digital-Business (8800 of FIG. 29) so that its contents do not change while the duplication is in progress. Digital-Businesses are frozen by inserting a Child of Type Type-True into the Activity-Status-Field (9440 of FIG. 31) of a Digital-Business. Once the duplication is completed, execution of the Digital-Business is continued as normal.

There are numerous types of duplication:

Copying all Children with UPT-Copy-AII-Children (see Appendix B).

Copying all Children and recursive grandchildren with UPT-Recursive-Copy (see Appendix

B).

Exotic copies with UPT-Entangled-Recursive-Copy, UPT-Denatured-Recursive-Copy and UPT-Entangled-Denatured-Recursive-Copy (see Appendix B).

PERMANENT-STORAGE

The Permanent-Storage-A (113 of FIG. 8 and 1700 of FIG. 9) is used by the UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9) to store a permanent copy of every Digital-Business (8800 of FIG. 29) on the Ill-Emulator. During a system failure, it is this copy of a Digital-Business that will be resumed and not the copy executing in the Kl-Memory (see Appendix G). Furthermore, Digital-Businesses will not all be resumed from the same point at which the failure occurred, but rather from the point at which they were individually saved, a function that is the responsibility of the individual Digital-Business and is likely to be committed by the Governance Layer (101b of FIG. 1, 202b of FIG. 2 and 6475 of FIG. 18) on behalf of the Digital-Business.

NODE PARTNERS

The Node (200a - 200 e of FIG. 2, 380 and 375 of FIG. 4) partners are other instances of the invention or functional equivalent that execute with a Governance Layer (101b of FIG. 1 , 202b of FIG. 2 and 6475 of FIG. 18) and Information Layer (101c of FIG. 1 and 202c of FIG. 2). Collectively, these Node partners form the peer-to-peer network.

DATA FLOW

FIG. 5 shows the flow of information between Emulator-Components (FIGs 3-8) in the III- Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG.. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57).

PRIMARY-DATAFLOW

The Primary-Dataflow (see FIG. 3) is data generated by the UPT-Cycler (470 of FIG. 3, 1470 of FIG. 10 and 1600 of FIG. 9) as it enables computational completeness. The UPT-Cycler splits the information into Asynchronous-UPTs and Synchronous-UPTs. It is the Asynchronous-UPTs that are responsible for the Primary-Dataflow as they are processed in parallel by the asynchronous Emulator-Components. The UPT-Cycler establishes each Asynchronous-UPT process by using the UPT-Execution-lnterface (see Appendix C for the Interface Definition). The Emulator-Components (FIGs 3-8) involved in the Primary-Dataflow are the UPT-Cycler, Asynchronous-Virtual-Machine-Queuer (410 of FIG. 3), AVMF-Verify-Queuer (490 of FIG. 3), ABS-Bus (420 of FIG. 5 and 6200 of FIG. 17) and Asynchronous-Duplicator (440 of FIG. 3).

KI-DATAFLOW

The Kl-Dataflow (see FIG. 4) involves every Emulator-Component and allows each to access the Kernel-Image (680 of FIG. 6 and Appendix G) via the Kl-lnterface. Once an Emulator- Component is processing an Asynchronous-UPT, it utilises a connection to the Kl-lnterface (see Appendix G) to manipulate information in the Kernel-Image (see Appendix G again). A single signal in the Primary-Dataflow will generate multiple calls to the Kl-lnterface by the Emulator- Components (FIGs 3-8). Each Emulator-Component can be configured in a variety of ways, typically each has one or more dedicated connections to the Kl-lnterface most likely of low priority. The UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9) can have numerous (typically six) high priority channels while the remaining connections by other Emulator-Components may be low priority.

ABS-DATAFLOW

The Asynchronous-Bit-Streamer (ABS) dataflow or ABS-Dataflow (see FIG. 5) supports asynchronous data streams generated in parallel by both the Fast-ABS (850 of FIG. 7 and 6000 of FIG. 16) and the Slow-ABS (860 of FIG. 7 and 5800 of FIG. 15). The Slow-ABS involves the transfer of large quantities of data at a slower speed than the Fast-ABS. The Fast-ABS quickly transfers smaller quantities of data to components that are fast data processors including the UPT-Cycler (870 of FIG. 5, 1470 of FIG. 10 and 1600 of FIG. 9), 31 P-AVM (960 of FIG. 7 and 17200 of FIG. 58), 3IP-AVMF-Verifier (970 of FIG. 5, 17025 of FIG. 57 and 23000 of FIG. 74), Plugin-Manager (920 of FlG. 7 and 7600 of FIG. 24), ABS-Bus (820 of FIG. 7 and 6200 of FIG. 17) and the Human-Communication-Manager (900 of FlG. 5). The Slow-ABS is also used as a large-scale depository for data by various Emulator-Components (FIGs 3-8). The Slow-ABS communicates with the Partner-Channel-Manager (830 of FIG. 7 and 13000 of FIG. 49) to manage data exchanges between Partners on the peer-to-peer network, the Environment- Manager (910 of FlG. 7 and 710 of FIG. 4) and the Plugin-Manager (920 of FIG. 7 and 7600 of FIG. 24). Digital-Businesses (8800 of FIG. 29) are able to access these Emulator-Components indirectly by storing data directly to the Fast-ABS or Slow-ABS by attaching files directly to Manabars-Sets (see Appendix G).

10-DATAFLOW

The lO-Dataflow (see FIG. 6) captures all data entering and leaving the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) via the Host Platform Layer (101z of FIG. 1 and 202z of FIG. 2).

The Human-Communication-Manager (1100 of FIG. 6) interfaces with the user via local display and capture equipment to , obtain and transmit Sensory-Render-Data (1130c of FIG. 6). Environmental-Data (113Od of FIG. 6) is received from the Environment-Manager (710 of FIG. 6 and 1110 of FlG. 6). Plugin-Data (113Oe of FlG. 6) data is received from the installed Plugins (7665a, 7665b and 7665n of FIG. 24) of the Plugin-Manager (1120 of FIG. 8 and 7600 of FIG. 24) and includes other forms of input such as mouse and keyboard events. The Ill-Emulator operates in a grid network where there are numerous 3lps (see 3IP-lnterface at 17000 of FIG. 57), each implemented by both building the Ill-Common-Context (400 of FIG. 5 and 17035 of FIG. 57) and extending the 3IP-lnterface (1150 of FIG. 6) that may be of a unique design. The protocol for communicating with partners is undefined and is referred to as the PCM-lnterface (1130a of FIG. 8 and 130125 of FIG. 49). The PCM-lnterface (see Appendix C) is defined only by its behaviour and not its mechanics, so it is abstract. The Partner-Channel-Manager (1030 of FIG. 8 and 13000 of FlG. 49) is responsible for implementing the PCM-lnterface (130125 of FIG. 49). The UPT-Cycier (1070 of FIG. 8 and 1600 of FIG. 9) moves information into the Permanent-Storage-A (113Of of FIG. 8 and 1700 of FIG. 9) whose encoding is arbitrary and beyond the scope of this patent. Permanent-Storage-A operates by serialising the Kernel- Image state so that it can be reproduced at start-up. The UPT-Cycler is able to reproduce the entire Powerset into the Kernel-Image (see Appendix G) from the Permanent-Storage-A. The Kernel-Image is not saved to the Permanent-Storage-A in a single iteration. Instead, each Digital-Business (8800 of FIG. 29) is reconstructed individually when each Digital-Business last saved itself.

STARTING AND SHUTTING DOWN THE INVENTION

START UP

The start-up sequence occurs in 4 stages: -

EMULATOR-PRIMING

All Emulator-Components (FIGs 3-8) remain dormant on powering up except for the UPT-Cycler (470 of FIG. 5 and 1600 of FIG. 9).

UPT-CYCLER-BOOTSTRAP

The UPT-Cycler starts the GL-Bootstrapper (1610 of FIG. 9), which clears (1 of FlG. 7) the Kernel-Image with the Reset Kl-lnterface method (see Appendix C for Interface-Definition). Once the Reset Kl-lnterface method has returned, data arrives in an implementation specific format from the Permanent-Storage-A (113Of of FIG. 8 and 1700 of FIG. 9) to the GL- Bootstrapper. The GL-Bootstrapper then loads the Powerset (6400 of FIG. 18) that contains the Govemance-Layer-Superstructure (6615 of FIG. 19, 10015 of FIG. 34 and 6410 of FIG. 18) into the Kl-Memory (see Appendix G) via the Kl-lnterface (see Appendix C for Interface-Definition). Some implementations may choose to preload the Kernel-Image prior to start-up in order to accelerate the boot up process. The state of the Kl-Memory is now set to a pre-configured Powerset image stored in the Permanent-Storage-A. If there was no pre-configured Powerset image stored in the Permanent-Storage-A then the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of . FIG. 10 and 1700-1 of FIG. 57) is shutdown.

GOVERNANCE-LAYER LOADING

The state of the Governance-Layer-Superstructure (6615 of FIG. 19, 10015 of FIG. 34 and 6410 of FIG. 18) is almost identical to its state when it was last shutdown. The only difference is that the state of each Digital-Business (8800 of FIG. 29) within it is reconstructed using the last known state of each Digital-Business. These states were previously stored to the Permanent- Storage-A (113Of of FIG. 8 and 1700 of FlG. 9) at a time that was convenient for each Digital- Business. The Governance Layer (101b of FIG. 1 , 202b of FIG. 2 and 6475 of FIG. 18) operates from a set structure known as the Governance-Execution (9430 of FIG. 31). The Digital- Business operates from a set structure known as the DTE-lnstance (9800a and 9800b of FIG. 33). The entire Governance-Execution (9430 of FIG. 31) and part of the DTE-lnstance holding the execution stacks known as the Active-Thread (6630 of FIG. 19, 9830 of FIG. 33 and 10050 of FIG. 34) are transient, so all information in these components are lost on system shutdown. Therefore, the last known state of the Digital-Business does not contain anything inside the Governance-Execution, and only contains the saved copy of the Design-Time-Execution (9420 of FIG. 31) up to the Active-Thread. As each Digital-Business is reconstructed it will be mapped to previous references held within the Governance-Layer-Superstructure (6410 of FlG. 18, 6615 of FIG. 19 and 10015 of FIG. 34). Any references inside the Governance-Layer-Superstructure to Digital-Businesses that no longer exist will be deleted.

EMULATOR-STANDBY

Following a successful loading process, the GL-Bootstrapper (1610 of FIG. 9) sends the Initialisation-Signal (1241 of FIG. 9 and 1720 of FIG. 9) to all Emulator-Components (FIGs 3-8). This signal generated via the Kl-lnterface (see Appendix C for Interface-Definition) to transmit the signal with the Kl-Broadcast instruction (see Appendix G). The Emulator-Components require the Kernel-Image (see Appendix G again) to be loaded in order to complete their own initialisation routines. Once each of these Emulator-Components has completed its initialisation routine, they return from the Kl-Broadcast Kl-lnterface method to generate the Initialisation- Complete-Signal (1242 of FIG. 9 and 1730 of FIG. 9). Once there is an Initialisation-Complete- Signal for each Initialisation-Signal issued, the Governance Layer (101b of FIG. 1 , 202b of FIG. 2 and 6475 of FIG. 18) is booted by the UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9). GOVERNANCE-BOOT

Each Governance-Boot-Instance (6498 of FIG. 18, 6600a and 6600b of FIG. 19) contained in

Every-Governance-Boot (6460 of FIG. 18) is executed (see UPT-Cycler) in a series from Left to Right. Prior to normal operation all execution occurs virtually to the Ill-Emulator (551 of FIG. 3,

751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG.

57) within the Kernel-Image (see Appendix G), with a series of foundation instructions known as

Universal-Process-Types (UPTs), covered in Appendix B. A Governance-Boot-Instance is only executed once the Governance-Boot-Instance to the Left of it has completed execution. This occurs once all the Stacks inside the Thread-Instance (10485a, 10485b, 10485n of FIG. 36 and

10600 of FIG. 37) for the Governance-Boot-Instance are empty.

During the Governance-Boot (9640 of FIG. 32) process the Governance-Boot is responsible for:

The cleanup of the Governance-Layer-Superstructure (6410 of FIG. 18, 6615 of FIG. 19 and

10015 of FIG. 34).

Configuring Digital-Businesses (8800 of FIG. 29) contained in Every-Digital-Business (6450 of FIG. 18) - a process that includes resetting the state of the Digital-Business so that it is ready to be processed. This part of the Governance-Boot (9640 of FIG. 32) process is beyond the scope of this patent, however it is included here to assist in clarifying understanding of the Ill-Emulator operation. The Governance-Boot process:

Makes a recursive copy of the Governance-Layer (6475 of FIG. 18) into each Governance-Execution (9430 of FIG. 31). Install a reference to the Global-Static-Store (6440 of FIG. 18, 6800 of FIG. 20 and

10025 of FIG. 34) into the Global-Static-Store-Field (10020 of FlG. 34) inside the copies of the Governance-Layer (6475 of FIG. 18). Create a thread group in the DTE-lnstance (9800a, 9800b of FIG. 33). Providing Object Orientated support through the creation of a Linker and Booter embedded in the GE-lnstance (9435 of FIG. 31,. 9630 of FIG. 32, 10000a of FIG. 34 and 10000b of FIG. 34). Locate the Boot-Drop-Instance (6625 of FIG. 19, 9825 of FIG. 33, 10045 of FIG. 34 and 10200 of FIG. 35) found within the GE-Boot-Drop- Field (10040 of FIG. 34), and the Thread-Instance (10600 of FlG. 37 and 10485a - 10485n of FlG. 36), found in the Thread-Group (6650 of FIG. 19, 9835 of FIG. 33, 10400 of FIG. 36 and 10055 of FIG. 34), of the GE-lnstance (9435 of FIG. 31 , 9630 of FIG. 32, 10000a and 10000b of FlG. 34). Use UPT-Recursive-Copy (see Appendix B). to copy the Child of the BDI-Realtime-Field (10210 of FIG. 35), found in the Boot-Drop-Instance into the Realtime-Stack (10430 of FIG. 36 and 10610 of FIG. 37) of the Thread-Instance. Likewise insert the Child of the BDI-Prepaid-Field (10220 of FIG. 35) into the Prepaid-Stack (10440 of FIG. 36 and 10620 of FIG. 37), the Child of the BDI-Standby-Field (10230 of FIG. 35) into the Standby-Stack (10630 of FIG. 37), the Child of the BDI-ldle-Field (10240 of FIG. 35) into the Idle-Stack (10460 of FIG. 36 and 10640 of FIG. 37) and the Child of the BDI-Background-Field (10250 of

FIG. 35) into the Background-Stack (10470 of FIG. 36 and 10650 of FIG. 37). Repeat the same Recursive-Copy for the Children of the fields of the Boot-Drop- Instance (6625 of FIG. 19, 10045 of FIG. 34 and 9825 of FIG. 33 and 10200 of FIG. 35) found within the DTE-Boot-Drop-Field (9820 of FIG. 33) into the stacks of the newly created Thread-Instance (10485a, 10485b, 10485n of FIG. 36 and 10600 of

FIG. 37) inside the Thread-Group (6650 of FIG. 19, 10055 of FIG. 34, 10400 of FIG. 36 and 9835 of FIG. 33) of the DTE-lnstance (9800a, 9800b of FIG. 33, 6476 of FIG. 18, 9425 of FIG. 31 and 9620 of FIG. 32).

EMULATOR-ENGAGEMENT

The GL-Bootstrapper (1610 of FIG. 9) transmits the On-Signal (1740 of FIG. 9) to the Kl- Switcher (1630 of FIG. 11 and 1800 of FIG. 12). The Kl-Switcher begins processing Digital- Business-Cycles until it is shutdown with the Off-Signal (1750 of FIG. 9) or if the Host Platform Layer (101z of FIG. 1 and 202z of FIG. 2) fails.

SHUTDOWN

Shutdown of the invention can occur through 2 mechanisms.

The Host Platform Layer (101z of FIG. 1 and 202z of FIG. 2) fails to support the invention, typically through hardware failure or loss of power. During the execution of the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FlG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57), the Governance-Layer-Superstructure (6410 of FIG. 18, 6615 of FIG. 19 and 10015 of FIG. 34) and each Digital-Business (8800 of FIG. 29) is periodically saved. How these saves occur is explained further in UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9). These periodic saves means that if the Host Platform Layer fails to support the invention then the startup sequence is able to utilise the last known state of the Governance-Layer-Superstructure (6410 of FIG. 18, 6615 of FIG. 19 and 10015 of FIG. 34) and each Digital-Business (8800 of FlG. 29) when the Ill-Emulator is restarted.

A controlled shutdown is directed from the Governance-Layer-Superstructure (6410 of FIG. 18, 6615 of FIG. 19 and 10015 of FIG. 34) and occurs when the Emulator-Shutdown (7250 of FIG. 22) has its Type set to Type-True. The UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9) should monitor the Emulator-Shutdown for this event and reset the Type to Type-False. At this point the Off-Signal (1750 of FIG. 9) is sent to the Kl-Switcher (1630 of FIG. 11 and 1800 of FIG. 12) and the entire Powerset (6400 of FIG. 18) should be saved, stopping at the Realtime- Computation-Schedule (9240 of FIG. 30), Prepaid-Cornputation-Schedule (8420 of FIG. 27), Standby-Computation-Schedule (8040 of FIG. 25 and 9250 of FIG. 30), Idle-Computation- Schedule (8050 of FIG. 25 and 9260 of FIG. 30) and Every-Digital-Business (6450 of FIG. 18). Each Digital Business (8800 of FIG. 29) held in Every-Digital-Business should also then be systematically saved, stopping at the Governance-Execution (9430 of FIG. 31) and the Active- Thread (9830 of FIG. 33, 6630 of FIG. 19 and 10050 of FIG. 34) of the DTE-lnstance (6476 of

FIG. 18, 9425 of FIG. 31 , 9620 of FIG. 32 and 9800a and 9800b of FIG. 33). This ensures that the next time the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) is started, the last known state of the

Governance Layer (101b of FIG. 1 , 202b of FIG. 2 and 6475 of FIG. 18) and each Digital- Business will be exactly as it was when it was shutdown.

THE MANABARS-SET

The Manabars-Set is a mechanism to represent Set Theory for a computational environment and is described in Appendix G as an additional patent.

UPT-CYCLER

The UPT-Cycler (470 of FIG. 3, 1470 of FlG. 10 and 1600 of FIG. 9) is responsible for managing the structure of the Kernel-Image (see Appendix G) through the Kl-lnterface (see Appendix C for Interface-Definition). The UPT-Cycler maintains the context of the virtual data inside the Kernel-Image, specifically in how the Governance Layer (101b of FIG. 1 , 202b of FIG. 2 and 6410 of FIG. 18) is presented. The UPT-Cycler is key to understanding the usefulness of the Ill-Emulator (551 of FlG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57), as it interacts with Manabars-Sets (see Appendix G) inside the Governance Layer. Primarily, the UPT-Cycler enables computational completeness by processing Universal-Process-Types or UPTs (see Appendix B) as instructions. Secondly, the UPT-Cycler configures the Governance Layer so that it behaves as an abstract Operating System that resides on the Ill-Emulator. The UPT-Cycler operates across the Global-Static- Store (6440 of FIG. 18, 6800 of FIG. 20 and 10025 of FIG. 34) whose superstructure is considered part of the invention, but the definition of Governance-Layer-Interface (9500a and 9500b of FIG. 31 , 9700a, 9700b of FIG. 32 and 9815 of FIG. 33) is not. The Governance Layer is an adjacent layer to the invention (101a of FIG. 1 and 202a of FlG. 2) and its full definition is dynamic and so is beyond the scope of this patent. However, the Kl-Switcher (1630 of FIG. 11 and 1800 of FIG. 12), which defines the UPT-Cycler behaviour after the On-Signal (1740 of FIG. 9) and before the Off-Signal (1750 of FIG. 9) handles its interaction with the adjacent Governance Layer through the Global-Static-Store (6440 of FIG. 18, 6800 of FIG. 20 and 10025 5 of FIG. 34).

The UPT-Cycler constructs the Kernel-Image (see Appendix G) state on start up (see Starting and Shutting down the Invention), which includes the installation of the Governance-Layer (6475 of FIG. 18) as a previously stored image in Permanent-Storage-A (113Of of FlG. 8 and

10 1700 of FIG. 9) through the use of the GL-Bootstrapper (1610 of FiG. 9) during the Emulator- Priming, Emulator-Standby and Governance-Boot (9640 of FIG. 32) stages. Once the initial conditions have been established, the Emulator-Engagement stage begins, during which, the Kl-Switcher (1630 of FIG. 11 and 1800 of FIG. 12) manipulates the Kl-Memory (see Appendix G) in an orderly way, so as to produce computational completeness. The Variable-Pool (1900 of

1.5 FIG. 12 and 1640 of FIG. 9) provides transient state information for the Kl-Switcher and behaves as an optimised fast memory cache (see Variable Pool of FIG. 9).

ASYNCHRONOUS PROCESSING

20 The Kl-Switcher (1630 of FIG. 11 and 1800 of FIG. 12) processes UPTs, splitting the instructions into 2 ^"groups. The first group are synchronous UPTs that can be completed immediately using the Kl-Switcher. The second group are asynchronous UPTs that require additional processing by dedicated Emulator-Components (FIGs 3-8). The asynchronous UPTs are delivered to the appropriate Emulator-Components by using the Primary-Dataflow (FIG. 3)

25 by way of the UPT-Execution-lnterface (475 of FIG. 3, 1635 of FIG. 9, 6255 of FIG. 17 and Appendix C for Interface-Definition). The asynchronous UPTs are transmitted to the Asynchronous-Virtual-Machine-Queuer (410 of FIG. 3), ABS-Bus (420 of FIG. 5 and 6200 of FIG. 17), Asynchronous-Duplicator (440 of FIG. 3) and the AVMF-Verify-Queuer (490 of FIG. 3). Therefore, no matter what the UPT, the Kl-Switcher can be guaranteed of returning immediately

30 and thus preserve the real-time properties of the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57). The UPT- Cycler (1600 of FIG. 11 and 1470 of FIG. 8) makes these asynchronous instructions appear as if they are synchronous by blocking any further execution of the Digital-Business (8800 of FIG. 29) that is utilising a UPT that invokes the asynchronous instruction. The blocking of the Digital-

35 Business is accomplished by inserting a new Child with its Type set to Type-Locked into the Activity-Status-Field (9440 of FIG. 31). SAVING THE DIGITAL-BUSINESSES

Periodically, Digital-Businesses (8800 of FIG. 29) may make requests to preserve their state via the Governance-Layer-Interface (9500a and 9500b of FIG. 3.1 , 9700a, 9700b of FIG. 32 and 9815 of FIG. 33). However, the Governance-Layer (6475 of FIG. 18) is likely to forward these requests to the Global-Static-Store (6440 of. FIG. 18, 6800 of FIG. 20 and 10025 of FIG. 34) and is accessed directly by the UPT-Cycler (1600 of FIG. 11 and 1470 of FIG. 8) through the Kl- lnterface (see Appendix C for Interface-Definition). The Governance-Layer (6475 of FIG. 18) directs the UPT-Cycler to commit the save by inserting a reference to the Digital-Business (8800 of FIG. 29) directly into the DB-Save (7240 of FIG. 22). On detecting this (see Monitors), the UPT-Cycler locks the Digital-Business by inserting a Child with a Type of Type-Locked into the Neutral position of the Activity-Status-Field (9440 of FIG. 31) and then stores the entire state of the Design-Time-Execution (9420 of FIG. 31) to Permanent-Storage-A (113Of of FIG. 8 and 1700 of FIG. 9), in an implementation specific format that is beyond the scope of this patent, by using the Kl-lnterface (see Appendix C for Interface-Definition). The Governance-Execution (9430 of FIG. 31) is transient, so its state is not recorded. If the Activity-Status-Field (9440 of FIG. 31) has a Child already of Type Type-Locked, prior to the scheduled save, then it should be postponed until the status reflects unlocked. If the save did take place, then an additional Child of Type Type-Unlock should be inserted into the Neutral position of the Activity-Status- Field. The UPT-Cycler continues to process other Digital-Businesses during the save. Finally, it removes the Digital-Business reference from the DB-Save.

SAVING THE GOVERNANCE LAYER

Periodically, the Governance-Layer (6475 of FIG. 18) may authorise its own saving by passing a Type-True to the GL-Save (7230 of FIG. 22). On detecting this, the UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9) begins saving the Governance Layer. It does this in the following way.

For the duration of the save, the Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) of the Kl-Switcher (1630 of FIG. 11 and 1880 of FIG. 12) no longer processes

UPTs from the GE-lnstance (9435 of FIG. 31 , 9630 of FIG. 32, 10000a and 10000b of FIG. 34) for any Digital-Business (8800 of FIG. 29) and substitutes these with UPTs (see Appendix B) from the DTE-lnstance (9425 of FIG. 31 , 9800a of FIG. 33) of Digital- Businesses instead. This creates a temporary surge in DTE-lnstance processing, but during this time, the

Governance-Layer (6475 of FIG. 18) is saved. The Governance-Layer may compensate for the surge by clearing all prepaid contracts or reducing the load on the UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9) to reduce the chip temperature in an FPGA fabric implementation. A lower chip temperature allows for a surge of processing to occur once the save has been completed in order to honour prepaid contracts. All references to any Digital-Business are saved but the Children inside the Digital-Business are not as these are replaced with the actual Digital-Business state that has previously been saved independently.

Once saved, as an optional step to improve performance, the Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) of the Kl-Switcher (1630 of FIG. 11 and 1880 of FIG. 12) may statistically substitute DBCs destined for the DTE-lnstance (10000a and 10000b of FIG. 34) and apply them to the GE-lnstance (9800a and 9800b of FIG. 33) instead to make up for lost processing during the first step during the original save. The Type-True is removed from the GL-Save (7230 of FIG. 22).

DIGITAL-BUSINESS SOLVENCY

Occasionally a Digital-Business (8800 of FIG. 29) will become bankrupt. On this occasion the Bankrupter (2420 of FIG. 13 and see further below) will spawn the Cursor of Every-Digital- Business (6450 of FIG. 18) and insert a reference to the spawned Cursor inside the DB-Delete (7260 of FIG. 22). The UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9) should have previously set a Monitor (5200 of FIG. 14) on the DB-Delete (7260 of FIG. 22) to detect this event and

Delete any references to the Digital-Business in the Permanent-Storage-A (113Of of FIG. 8 and 1700 of FIG. 9),

Use the spawned Cursor in DB-Delete to remove the Digital-Business from Every- Digital-Business.

Governance-Layer (6475 of FIG. 18) contracts for the insolvent Digital-Business are removed.

Any image of the insolvent Digital-Business is removed from Permanent-Storage-A.

KI-SWITCHER

Although the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) has numerous Emulator-Components (FIGs 3-8) that operate in parallel with various throughput, the Kl-Switcher (1630 of FIG. 11 and 1800 of FIG. 12) is the core processor of the invention, and as such the specific processor power rating of the deployment can be measured indirectly by the sum of all Digital-Business-Cycles completed per second. DIGITAL-BUSINESS-CYCLE

A Digital-Business-Cycle occurs when an Item-Processor (1820, 1830 and 1840 of FIG. 12 and 2480a, 2480b and 248On of FIG. 13) attempts to process a single UPT (an instruction) from within a Digital-Business stack (10610, 10620, 10630, 10640 and 10650 of FIG. 37). A UPT will take a minimum of one Digital-Business-Cycle (DBC) to process but it may take an unknown number, such as in the case of the Type-UPT-Sequence (see Appendix B). Although the engagement of any one Item-Processor (2480a, 2480b, 248On of FIG. 13 and 1840, 1830 and 1820 of FIG. 12) is considered a DBC, the true latency and response of the software will vary depending on how equally balanced each Emulator-Component (FIG. 3-8) is. The invention is optimised for a Field Programmable Gate Array (FPGA) implementation, where each Emulator- Component can expand its capacity as demand for the resource changes (see Resource-Model further below). For example, if the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) has limited capacity on the Asynchronous-Duplicator (440 of FIG. 3), there may be latency for asynchronous duplication processes, where this resource has not been previously reserved with the Prepaid-Marketplace (see Resource-Model again).

The power rating is measured as: -

_______

Power rating = P

Digital-Business-Cycles = C Time = T

KI-SWITCHER CONFIGURATION

There are numerous ways the Kl-Switcher (1630 of FIG. 11 and 1800 of FIG. 12) can be configured. FIG. 12 shows an exemplary configuration for an optimised implementation in silicon. This configuration is operating asynchronously but no Digital-Business (8800 of FIG. 29) is allowed to operate in parallel with itself. The Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) will choose a Digital-Business in a manner that is consistent with the 5 level Resource-Model of the invention. The Digital-Business is selected from either the Realtime-Computation-Schedule (8220 of FIG. 26), Prepaid-Computation-Schedule (8420 of FIG. 27), Standby-Computation-Scheduie (8040 of FIG. 25 and 9250 of FIG. 30 ), the Idle- Computation-Schedule (8050 of FIG. 25 and 9260 of FIG. 30) or Every-Digital-Business (6450 of FIG. 18) based on a configuration determined by the virtual Governance-Layer (6475 of FIG. 18). Virtual software running in the Governance-Layer sets up the schedule that determines Digital-Business selection based on reservations made by the Digital-Businesses themselves that form part of the Prepaid-Marketplace (see Digital-Busϊness-Selector at 2400 of FIG. 13). These schedules are stored in the Item-Processor-Queue (2450 of FIG. 13).

STACK SELECTION

The Item-Processor (2480a, 2480b, 248On of FIG. 13 and 1840, 1830, 1820 of FIG. 13) will attempt to process a Universal-Process-Type or UPT (see Appendix B) from 1 of at least 15 stacks:

Five belonging to the Super-Stacks (9410 of FIG. 31) of the DTE-lnstance (9425 of FIG. 31 , 9800a and 9800b of FIG. 33) of a Digital-Business (8800 of FIG. 29).

Five belonging to the Super-Stacks of the GE-lnstance (10000a and 10000b of FIG. 34, 9435 of FIG. 31).

There are 5 stacks for every Thread-Instance (10485a, 10485b, 10485n of FIG. 36 and 10600 of FIG. 37) of the GE-lnstance.

There are 5 stacks for every Thread-Instance of the DTE-lnstance.

The Kl-Switcher (1630 of FIG. 11 and 1800 of FIG. 12) must have at least one Item-Processor (2480a, 2480b, 248On of FIG. 13 and 1840, 1830, 1820 of FIG. 13) to process Digital- Businesses, but the design allows for as many as needed. Multiple Item-Processors enables Digital-Businesses to be processed in parallel. For each unique Digital-Business executed in parallel, an entry in the Variable-Pool (1640 of FIG. 11 and 1900 of FIG. 12) should retain the state information throughout its execution. Storing the information anywhere in the invention should be considered functionally equivalent to storing information in the Variable-Pool. The Item-Processor determines the stack to be processed in a certain order (see Item-Processor).

UNIVERSAL-PROCESS-TYPE (UPT)

The Manabars-Set (see Appendix G) has a special field called Type (see Appendix G again), which gives it context amongst the multitude of other possible Manabars-Set structures. Although the 64-bit Type field may contain any integer value, there is a very narrow range of values that is used by the Kl-Switcher (1630 of FIG. 11 and 1800 of FIG. 12) to enable a computationally complete platform. These special Children each respond in different ways when they are executed. The Type Field is the only context provider against a backdrop of identical Manabars-Sets, as each Child is otherwise identical. The arguments for the executing Universal-Process-Type (see Appendix B for a full listing of all UPTs) are themselves Children inside the executing Universal-Process-Type.

RESOURCE-MODEL

Resources in the invention are managed by various Emulator-Components (FIGs 3-8 and see table below). The Resource-Model can be applied to Emulator-Components in a number of ways. This exemplary embodiment contains an implementation for the UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9) and the Partner-Channel-Manager (13000 of FIG. 49) while other Emulator-Components have been left unspecified. In a rigorous implementation, every resource on the Ill-Emulator (551 of FIG: 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) may utilise the Resource-Model. All resources are measurable in both size (Volume Unit) and speed (Rate Unit). Below is a list of these resources and how they are measured. Digital-Businesses (8800 of FIG. 29) can purchase an unlimited number of resource contracts, providing they remain solvent. The Governance Layer (101 b of FIG. 1 and 202b of FIG. 2) is responsible for enabling the sale of contracts on the open network by Digital-Businesses. The Governance Layer converts contracts to a password and key so that they can be traded off the local Node (200a-200e of FIG. 2 and 380, 395 of FIG. 4).

These Resources are processed according to a certain level of priority. There are 5 levels of priority, being: Realtime Prepaid Standby Idle

Background.

For each level of priority there is a matching Marketplace:

Realtime-Marketplace

Prepaid-Marketplace Standby-Marketplace Idle-Marketplace Background-Marketplace.

This cluster of 5 marketplaces exist for each resource in the invention. The marketplaces are dynamic so that the pricing for each resource and for each priority changes over time as determined by supply and demand.

In order to ensure that the resource will be available when required, Digital-Businesses (8800 of FIG. 29) are able to book the resource in advance by utilising either the Prepaid-Marketplace or the Realtime-Marketplace. Each Emulator-Component (FIGs 3-8) will always check the Realtime-Marketplace first.

MARKETPLACE PROPERTIES

Each marketplace exhibits varying characteristics and the availability of resource.

REALTIME-MARKETPLACE

The Realtime-Marketplace guarantees the availability of a resource up to a fixed level of cover for a specific wiηdow of time and doesn't require reservation in advance. However, the cost of the premium to ensure this availability is reasonably high and the throughput fairly low, so generally mobile agents are likely to use it in emergencies only when unexpected utility demand arises and performance is critical - for example, the braking system on a bus. Realtime systems must preserve sufficient realtime resource to guarantee normal function. Standard behaviour should involve not restarting until realtime resource is sufficiently high. Otherwise, once the level of cover has been consumed, the system no longer guarantees resource availability. For example, the bus braking system would remain locked until realtime resource was re-established. At any point, the Goverηaηce Layer (101b of FIG. 1 and 202b of FIG. 2) may choose to re-enable the entire level of cover at a time that is convenient for the Node. The Digital-Business agrees on a reimbursement price for which it is willing to accept the potential revoking of the contract. A Realtime-Marketplace contract can be converted into an ID and password so that it may be traded off site from the local Node (200a-200e of FIG. 2 and 380, 395 of FIG. 4). The Governance Layer can reassign this contract to the Digital-Business that first presents the correct ID and password.

PREPAID-MARKETPLACE

The Prepaid-Marketplace enables mobile agents to reserve resource up to a known level for a specific window of time. A Prepaid Contract can be either of continuous or erratic. The erratic option is likely to be more expensive, but guarantees the delivery of the resource at any point provided it is within the agreed window of time for the contract. The continuous option ensures that resource is delivered constantly, regardless of Node (200a-e of FIG. 2 and 380, 395 of FIG. 4) loading for use in applications such as a phone call. Resource that is not utilised within the prepaid contract lifetime may be reimbursed by the Governance Layer (101b of FIG. 1 and 202b of FIG. 2) at a lower rate - but it is effectively a lost opportunity for the Digital-Business (8800 of FIG. 29). When the Digital-Business purchases a resource contract from the Governance Layer it is likely to require a price at which the Digital-Business is prepared to lose the contract. The lower the cancel price, the better the rate for the resource is likely to be. However, the Governance Layer may cancel the contract and pay the cancel price in order to generate additional resource in order to satisfy realtime contracts. Like the Realtime-Marketplace, the Digital-Business may have its contract revoked at any point and be paid the reimbursement price that it originally set. Furthermore, the prepaid contract can be sold in a digital marketplace with an ID and password like the realtime contract.

STANDBY-MARKETPLACE

Digital-Businesses (8800 of FIG. 29) can utilise resource at any point from the Standby- Marketplace that is similar to spot prices found within electricity marketplaces. Resource availability is erratic, as it comprises of the remainder when prepaid contracts and realtime contracts have been fully satisfied. The Standby-Marketplace posts a spot price for the resource at any point in time. Due to its unreliability, the Standby-Marketplace is more cost effective that the Prepaid-Marketplace and so is only suitable for certain types of jobs such as backup or 3D rendering. IDLE-MARKETPLACE

The Idle-Marketplace is identical to the Standby-Marketplace, except it represents resource that can be utilised when no other marketplace requires it.

BACKGROUND-MARKETPLACE

The Background-Marketplace is the resource available after every marketplace has been satisfied. It is extremely unreliable but the most cost effective but characterised by large lulls in availability.

IMPLEMENTATION OF RESOURCE MODEL

As a developer building mobile agents for the invention, utilising the 5 priorities is easy. Processes simply request the level of priority that they require for a resource. At the implementation level the actual resource utilised may be different to that requested, providing that the resource availability matches or is better than the requested priority so applications can specify their minimum operating requirements.

As an implementer of the invention there are many opportunities to make further optimisations. Further to this, the Governance Layer (101 b of FIG. 1 and 202b of FIG. 2) provides the opportunity to make intelligent decisions at runtime on behalf of the Digital-Business (8800 of FIG. 29). For example, if a realtime resource is required, but the Digital-Business still has unutilised prepaid resource, then it makes sense for the implementation to utilise the prepaid resource first before using the premium realtime resource. The following rules are used as a guide when distributing the 5 priority levels of resource:

REALTIME

If there is demand for a realtime resource then this Emulator-Component (FIGs. 3-8) is given the highest priority in obtaining it. The Emulator-Component will check if there is any background, idle, standby or prepaid resource available (in that order) for the Digital-Business (8800 of FIG. 29) prior to engaging the realtime resource. If there is alternative resource available, then that resource is utilised first. If there is not enough alternative resource to run the realtime process, then the Emulator-Component will use what it can from the alternative resource and take the rest from the realtime resource. If there is no alternative resource available to the Digital-Business then the realtime resource is utilised immediately. \

63 PREPAID

If there is demand for a prepaid resource then the Emulator-Component (FIGs. 3-8) supplies it after realtime demand has been satisfied. If there is no demand for resource in the Realtime- Marketplace, then the Emulator-Component distributes the resource to the Prepaid-

Marketplace, otherwise this resource is used to satisfy realtime demand. . If there is no prepaid demand, then the Emulator-Component either reimburses the Digital-Business (8800 of FIG.

29) at an agreed rate or supplies the idle, standby or background marketplaces if demand exists there and it is more cost effective for the Digital-Business to do so instead of purchasing resource directly from these marketplaces.

STANDBY

If there is demand for standby resource then the Emulator-Component (FIGs. 3-8) will provide it after realtime and prepaid demand has been satisfied.

IDLE

If there is demand for idle resource then the Emulator-Component (FIGs. 3-8) will provide it after realtime, prepaid and standby demand has been satisfied.

BACKGROUND

If there is demand for background resource then the Emulator-Component (FIGs. 3-8) will provide it after realtime, prepaid, standby and idle demand has been satisfied.

DIGITAL-BUSINESS-SELECTOR

The Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) is an independent process in the KI-Switcher (1630 of FIG. 11 and 1800 of FIG. 12) that determines the ordering of Digital- Business (8800 of FIG. 29) processing. The Digital-Business-Selector contains an Item- Processor-Queue (2450 of FIG. 13) for each Item-Processor (1820, 1830 and 1840 of FIG. 12 and 2480a, 2480b, 248On of FIG. 13) in the Kl-Switcher. Each Item-Processor-Queue holds a list of Digital-Businesses that are ready to be processed. Once a Digital-Business has been assigned to an Item-Processor, it is placed into the same Item-Processor-Queue each time it is selected. This is to ensure that each Digital-Business can be assigned to a Kl-lnterface (see Appendix G) that accesses an Isolated-Memory-Segment (9600a - 960On of FIG. 32). This assists in enabling a scalable and parallel implementation in Field Programmable Gate Arrays (FPGA). The Kernel-Image (see Appendix G) has the capacity to access global memory, but the throughput is limited to the Backplane-Bus (see Appendix G again) that limits the loading capacity and is only accessed by the Governance-Layer (6475 of FIG. 18) when it utilised the Global-Static-Store (6440 of FIG. 18, 6800 of FIG. 20 and 10025 of FIG. 34) reference.

Each Item-Processor-Queue (2450 of FIG. 13) contains a Level (2456a -2456n of FIG. 13) and the Digital-Business reference (2455a - 2455n of FIG. 13). The Level represents the number of Digital-Business-Cycles that the Digital-Business (8800 of FIG. 29) has been scheduled to undergo by the Governance Layer (101b of FIG. 1 and 202b of FIG. 2). See Digital-Business- Selection below for further information on how each Item-Processor-Queue is allocated. When the Digital-Business-Selector (1810 of FlG. 12 and 2400 of FIG. 13) receives an Item- Processor-Notification (1935 of FIG. 12 and 2470 of FIG. 13) from an Item-Processor (2480a, 2480b, 248On of FIG. 13 and 1840, 1830, 1820 of FIG. 12) it sends the next available Digital- Business (8800 of FIG. 29) in the form of a Digital-Business Cursor-ID (1930 of FIG. 12 and 2490 of FIG. 13) in the matching Item-Processor-Queue to the Item-Processor. The next Digital-Business (8800 of FIG. 29) to be processed is the first Digital-Business in the Item- Processor-Queue. If the Digital-Business is locked then the Digital-Business-Selector moves to the next Digital-Business in the Item-Processor-Queue. A Digital-Business is considered as locked when the Activity-Status-Field (9440 of FIG. 31) of the Digital-Business holds a Child with a Type of Type-Locked. Any Digital-Business that has a repeated entry in the queue can retain a single entry while increasing the Level by 1 for each repeated entry that is deleted. The Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) continues searching the Item- Processor-Queue in this manner until the next unlocked Digital-Business is located and sent to the Item-Processor. Once a Digital-Business-Cycle has been processed, the Level (2456a - 2456n of FIG. 13) for that Digital-Business in the Item-Processor-Queue, is decreased by one. When any Level in the Item-Processor-Queue reaches zero, the entry for the Digital-Business is removed from the Item-Processor-Queue. The Digital-Business-Selector is running constantly in the background until any Item-Processor-Queue has reached its maximum capacity as determined by the implementation.

DIGITAL-BUSINESS SELECTION

There are a total of six schedules that determine the Digital-Business (8800 of FIG. 29) execution ordering. The Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) cycles through these schedules to locate Digital-Businesses to process. These schedules are selected, in the following order: The Realtime-Computation-Schedule (8200 of FIG. 26). All Digital-Businesses in this Schedule are held inside an RCS-ltem (8235a - 8235n of FIG. 26 and 8700a, 8700b of FIG. 28 and 9245 of FIG. 30).

The Prepaid-Computation-Schedule (8420 of FIG. 27). All Digital-Businesses in this Schedule are held inside a PCS-ltem (8435a - 8435n of FIG. 27 and 8600a and 8600b of FIG. 28). The Standby-Computation-Schedule (8040 of FIG. 25 and 9250 of FIG. 30). The Idle-Computation-Schedule (8050 of FIG. 25 and 9260 of FIG. 30). Every-Digital-Business (6450 of FlG. 18). Every-Sandbox-Digital-Business (6500 of FIG. 18).

The Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) works in one schedule at a time working from Left to Right. If at any time the Cursor reaches the rightmost boundary of any schedule then it is shifted back to the leftmost boundary. The Digital-Business-Selector will always give highest priority to the Realtime-Computation-Schedule (820Q of FIG. 26) and will always check this schedule first. However, in an exemplary configuration, the Digital-Business- Selector (1810 of FIG. 12 and 2400 of FIG. 13) may guarantee processing power to a certain number of Digital-Businesses (8800 of FIG. 29) within one cycle of the schedule. This would allow Digital-Businesses in schedules with lower priority to get more of a chance to be processed. The maximum number of Digital-Businesses selected in one cycle of the schedule would be specified by the Child of the DBCs-Per-Schedule-Cycle-Field (8010 of FIG. 25) and is set by the Governance Layer (101b of FIG. 1 and 202b of FIG. 2). The Digital-Business- Selector tracks how many Digital-Businesses (8800 of FIG. 29) have been selected during the current cycle of the schedule. This is known as the Round-Accumulation. If there are any Digital-Businesses in the Realtime-Computation-Schedule (8220 of FIG. 26 and 9240 of FIG. 30) or the Prepaid-Computation-Schedule (8420 of FlG. 27) that have not been processed when the maximum number of Digital-Businesses per cycle of each schedule has been reached, then these schedules will have incurred a loss of computation known as a loss, in which case the following will occur:

The prepaid loss is retrieved through the Whole of the PLF-lnstance (8415 of FIG. 27) of the Prepaid-Loss-Field (8410 of FIG. 27). The Round-Accumulation is then added to the prepaid loss and a Child is inserted into the Neutral position of the Prepaid-Loss-Field (8410 of FIG. 27) with its Whole set to the new prepaid loss. The realtime loss is retrieved from the Whole of the Child of the Realtime-Loss-Field (8210 of FIG. 26). The Whole of the DPSC-lnstance (8015 of FIG. 25) is deducted from the Round- Accumulation and the remainder is added to the realtime loss. A new Child is inserted into the Neutral position of the Realtime-Loss-Field (8210 of FIG. 26) with its Whole set to the new realtime loss. No matter what the current schedule, the whole selection process will then begin again with the Realtime-Computation-Schedule (8220 of FIG. 26).

If, however, the maximum number of Digital-Businesses (8800 of FIG. 29) per cycle of the schedule has not been reached when the Cursor of the currently selected schedule is shifted back to the leftmost boundary, then the following could occur:

If a loss has been incurred then the loss will be retrieved from either the Realtime-Loss-Field (8210 of FIG. 26) if the currently selected schedule is the Realtime-Computation-Schedule (8220 of FIG. 26), or the Prepaid-Loss-Field (8410 of FlG. 27) if the currently selected schedule is the Prepaid-Computation-Schedule (8400 of FIG. 27). The Round-Accumulation will be deducted from the Whole of the DPSC-lnstance (8015 of FIG. 25) and the remainder will then be deducted from the appropriate loss. A new Child with its Whole set to the new loss will be inserted into the relevant loss Field and the Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) will continue selecting Digital-Businesses (8800 of FlG. 29) from the same schedule.

Otherwise if there is no loss incurred then the Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) will start to select Digital-Businesses (8800 of FIG. 29) from the next schedule in order of priority.

The Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) cycles through the schedules, selecting Digital-Businesses (8800 of FIG. 29) until the Item-Processor-Queue (2450 of FIG. 13) is full. This means that a single Digital-Business can be inserted onto the Item- Processor-Queue more than once. The following steps outline how the Digital-Business- Selector determines execution order of Digital-Businesses and inserts an entry onto the Item- Processor-Queue:

The Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) locates the Cursor of the RCS-List (8230 of FIG. 26 and 8760 of FIG. 28) found in the Realtime-Computation- Schedule (8220 of FIG. 26) and sets the Round-Accumulation to equal zero.

The Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) checks if there are any Children in the schedule. If there are no Children in the schedule then the Digital-Business- Selector locates the Cursor of the next schedule (as described below) and repeats step (2). Otherwise if there are Children in the schedule then the Digital-Business-Selector will continue with step (3). If the schedule currently selected is the Realtime-Computation-Schedule (8220 of FIG. 26), then the next schedule would be the Prepaid-Computation-Schedule (8420 of FIG. 27).

If the schedule currently selected is the Prepaid-Computation-Schedule (8420 of FIG. 27), then the next schedule would be the Standby-Computation-Schedule (8040 of FIG. 25 and 9250 of FIG. 30).

If the schedule currently selected is the Standby-Computation-Schedule (8040 of ..FlG. 25 and 9250 of FIG. 30), then the next schedule would be the Idle- Computation-Schedule (8050 of FIG. 25 and 9260 of FIG. 30). If the schedule currently selected is the Idle-Computation-schedule (8050 of FIG. 25 and 9260 of FIG. 30), then the next schedule would be Every-Digital-Business (6450 of FIG. 18).

If the schedule currently selected is Every-Digital-Business (6450 of FIG. 18), then the next schedule would be the Every-Sandbox-Digital-Business (6500 of FIG. 18). If the schedule currently selected is Every-Sandbox-Digital-Business (6500 of FIG.

18) then the whole selection process would begin again from step (1).

Depending on which schedule is currently selected, the Digital-Business (8800 of FIG. 29) to be selected is identified through either:

The Rl-Digital-Business-Fieid (8710 of FIG. 28) of the RCS-ltem (8700a and 8700b of FIG. 28, 8235a-8235n of FIG. 26 and 9245 of FIG. 30), currently identified by the Cursor of the RCS-List (8230 of FIG. 26 and 8760 of FIG. 28) contained in the Realtime-Computation-Schedule (8220 of FIG. 26). The Pi-Digital-Business-Field (8610 of FIG. 28) of the PCS-ltem (8600a and 8600b of FIG. 28 and 8435a-8435n of FIG. 27), currently identified by the Cursor of the PCS-List (8430 of FIG. 27, 8660a-n of FIG. 28) contained in the Prepaid- Computation-Schedule (8420 of FIG. 27). The Digital-Business (8800 of FIG. 29) currently identified by either the Standby-List (8060 of FIG. 25) contained in the Standby-Computation-Schedule (8040 of FIG. 25 and 9250 of FIG. 30), Idle-List (8070 of FIG. 25) contained in the Idle-Computation- Schedule (8050 of FIG. 25 and 9260 of FIG. 30), Every-Digital-Business-List (6455 of FIG. 18) contained in Every-Digital-Business (6450 of FIG. 18) or Every-Sandbox- Digital-Business-List (6510 of FIG. 18) contained in Every-Sandbox-Digital-Business (6500 of FIG. 18).

The Digital-Business (8800 of FIG. 29) is checked to see if it can be selected. If the Digital Business is unable to be selected then the Cursor of the current Schedule is shifted to the right as outlined above and, unless otherwise specified, selection carries on from step (3). Reasons for a Digital-Business not being able to be selected are as follows:

The Digital-Business has already been declared insolvent. If the current schedule is the Realtime-Computation-Schedule (8220 of FIG. 26) and the Whole of the Child of RI-Realtime-DBC-Remaining-Field_. (8720 of FIG. 28) of the RCS-ltem (8235a - 8235n of FIG. 26, 8700a, 8700b of FIG. 28 and 9245 of FIG. 30) is less than or equal to the Whole of the Child of the Rl-Footprint-Field (8740 of FIG. 28) of the RCS-ltem then the Digital-Business is unable to be selected. The RCS- Item for this Digital-Business is then removed from the RCS-List (9240 of FIG. 30) in the Realtime-Computation-Schedule (8220 of FIG. 26). This is NOT done directly but instead the Child of the Realtime-Release (8750 of FIG. 28 and 9210 of FIG. 30) has its Child - the RCS-ltem (8700b of FIG. 28) - deleted from the RCS-List (8760 of FIG. 28 and 8230 of FIG. 26). However, if there are no Children in the Realtime- Release, then the Governance Layer (101b of FIG. 1 and 202b of FIG. 2) has made an error and the RCS-ltem may be deleted directly from the RCS-List . If the current schedule is the Prepaid-Computation-Schedule (8420 of FIG. 27) and the Whole of the Child of the PI-DBC-Remaining-Field (8620 of FIG. 28) of the PCS- ltem (8600a and 8600b of FIG. 28 and 8435a, 8435b, 8435n of FIG. 27) is less than or equal to the Whole of the Child of the Pl-Footprint-Field (8640 of FIG. 28) of the

PCS-ltem then the Digital-Business (8800 of FIG. 29) is unable to be selected.

If the Digital-Business (8800 of FIG. 29) is selected then the Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) will search the DB-ltem-Processor-Hashtable (2410 of FIG. 13) to see which Item-Processor-Queue (2450 of FIG. 13) the Digital-Business is to be inserted on. If the Digital-Business is being selected for the first time then it is assigned to the Item-Processor (1840, 1830, 1820 of FIG. 12 and 2480a - 248On of FIG. 13) that is least loaded at the time. The least loaded Item-Processor is ascertained through totalling all Levels (2456a -2456n of FIG. 13) in the Item-Processor-Queue. The Digital-Business is inserted into the DB-ltem-Processor-Hashtable (2410 of FIG. 13) with a reference to the chosen Item-Processor-Queue. This ensures that each time the Digital-Business is subsequently selected it will always go to the same Item-Processor in order to avoid the Digital-Business being processed by two or more Item-Processors at the same time.

Once the correct Item-Processor-Queue (1840, 1830, 1820 of FIG. 12 and 2480a - 248On of FIG. 13) has been located then the Digital-Business (8800 of FIG. 29) is inserted into the Item-Processor-Queue in the last position available with the Level (2456a -2456n of FIG. 13) set to either: The Whole of the Child in the Rl-Footprint-Field (8740 of FIG. 28) of an RCS-ltem (8235a-n of FIG. 26, 8700a, 8700b of FIG. 28 and 9245 of FIG. 30) if the Digital- Business (8800 of FIG. 29) resides in the Realtime-Computation-Schedule (8220 of FIG. 26).

The Whole of the Child in the Pi-Footprint-Field (8640 of FIG. 28) of a PCS-ltem (8600a, 8600b of FIG. 28, 8435a-n of FIG. 27) if the Digital-Business resides in the Prepaid-Computation-Schedule (8420 of FIG. 27). The value of 1 for any other schedule.

If the currently selected schedule is either the Realtime-Computation-Schedule (8220 of FIG. 26) or the Prepaid-Computation-Schedule (8420 of FIG. 27) then the Digital-Business- Cycles (DBC) remaining is retrieved from the Whole of the Child of the PI-DBC-Remaining- Field (8620 of FIG. 28) of the PCS-ltem (8600a, 8600b of FIG. 28 and 8435a-n of FIG. 27) or the RI-Realtime-DBC-Remaining-Field (8720 of FIG. 28) of the RCS-ltem (8700a, 8700b of FIG. 28, 8235a-n of FIG. 26 and 9245 of FIG. 30). The value of the Whole of the Child of the Rl-Footprint-Field (8740 of FIG. 28) of the RCS-ltem or the Pi-Footprint-Field (8640 of FIG. 28) of the PCS-ltem is deducted from the DBC remaining and a new Child is inserted into the Neutral position of the PI-DBC-Remaining-Field (8620 of FIG. 28) or Rl-Realtime- DBC-Remaining-Field (8720 of FIG. 28) with its Whole set to the new DBC remaining.

The total of the Round-Accumulation is increased by the value of the Whole of the Child of either the Rl-Footprint-Field or the Pi-Footprint-Field (8640 or 8740 of FlG. 28) by 1 - depending on the currently selected schedule. The cursor of the current schedule is then shifted to the Right as outlined above and the selection of Digital-Businesses (8800 of FIG.

29) carries on.

BILLING

All prices for the Computation-Schedules are found in the Pricing-Item (19020 of FIG. 60 and 20000 of FIG. 61) located in the DBC-Pricing (19015 of FIG. 60) of the Resource-Pricing (7265 of FIG. 22 and 19000 of FIG. 60). These prices are set by the Governance Layer (101 b of FIG. 1 and 202b of FIG. 2). The Digital-Business (8800 of FIG. 29) is billed for the Realtime- Computation-Schedule (8220 of FIG. 26) and Prepaid-Computation-Schedule (8420 of FIG. 27) at the point at which the reservation is made from within the Governance Layer. However, the Digital-Business-Selector (1810 of FIG-. 12 and 2400 of FIG. 13) charges the Digital-Business (8800 of FIG. 29) for every DBC processed via the Standby-Computation-Schedule (8040 of FIG. 25 and 9250 of FIG. 30) by the Float of the Price (20040 of FIG. 61) located in Standby- Marketplace-Price (20075 of -FIG. 61). Every DBC processed via the Idle-Computation- Schedule (8050 of FIG. 25 and 9260 of FIG. 30) is charged by the Float of the Price (20090 of FIG. 61) located in Idle-Price-Price (20085 of FIG. 61). In the event that there are any additional Digital-Business-Cycles remaining after all the schedules have been processed, then these are directed to the Background-Marketplace. In this case, the bank account is deducted by the Float of the Price (20100 of FIG. 61) located in Background-Price-Price (20095 of FlG. 61) but is likely to be free of charge.

DISTRIBUTION

It is the Governance Layer (101b of FIG. 1 and 202b of FIG. 2) that determines the distribution for every RCS-ltem (8235a - 8235n of FIG. 26 and 8700a and 8700b of FIG. 28 and 9245 of FIG. 30) in the Realtime-Computation-Schedule (8220 of FIG. 26), PCS-ltem (8435a - 8435n of FIG. 27 and 8600a and 8600b of FIG. 28) in the Prepaid-Computation-Schedule (8420 of FIG. 27) or Digital-Business (8065a - 8065n and 8075a - 8075n of FIG. 25 and 8800 of FIG. 29) in both the Standby-Computation-Schedule (8040 of FIG. 25 and 9250 of FIG. 30) and Idle- Computation-Schedule (8050 of FIG. 25 and 9260 of FIG. 30). The resulting distribution is determined by Digital-Businesses that utilise the Govemance-Layer-lnterface (9500a, 9500b of FIG. 31 , 9700a, 9700b of FIG. 32 and 9815 of FIG. 33) to purchase computational resource, although it is the Governance Layer that will authorise the timing. The reference to the Digital- Business is stored to the Variable-Pool (1640. of FIG. 11 and 1900 of FIG. 12) in the VP-Digital- Business (1910 of FIG. 12).

SOLVENCY

The Bankrupter (2420 of FIG.13) ensures that each Digital-Business (8800 of FIG. 29) is solvent. To check the solvency status of the applicable Digital-Business, the Bankrupter reads the Float of the Child of the Bank-Account-Field (8890 of FIG. 29) to ensure that that this value is greater than zero. The solvency status of the Digital-Business is stored to the VP-Bankrupt- Status (1905 of FIG. 12) where Type-True is solvent and Type-False is bankrupt. A reference to the Bank-Account-Field (8840 of FIG. 29) is stored to the VP-Bank-Account (1920 of FIG. 12). VARIABLE-POOL

The Variable-Pool (1640 of FIG. 11 and 1900 of FIG. 12) acts as an optional fast cache in that it stores key handles and status information to registers for each Digital-Businesses (8800 of FIG. 29) that is being executed. The Variable-Pool may be used to store stack references directly to reduce the number of Kl-lnterface (see Appendix G) calls made and decrease the time for a single DBC. There is one Variable-Pool for each Item-Processor (1840, 1830, 1820 of FIG. 12 and 2480a-n of FIG. 13). The Variable-Pool contains a cluster of Boolean registers and 64-bit registers. The 64-bit registers are each capable of storing a single Cursor-Identification (5030 of FIG. 26, 6635 of FIG. 19 and 7620 of FIG. 24). The most probable cache candidates are the VP-Bankrupt-Status (1905 of FIG. 12), VP-Digital-Business (1910 of FIG. 12), VP-DB-Level (1915 of FIG. 12) and VP-Bank-Account (1920 of FIG. 12). The Variable-Pool may be extended to hold any state information for any executing Digital-Business so that the execution process may be accelerated.

VP-BANKRUPT-STATUS

The VP-Bankrupt-Status (1605 of FIG. 12) is a Boolean field that indicates whether this Digital- Business (8800 of FIG. 29) being processed by the Item-Processor (1840, 1830, 1820 of FIG. 12 and 2480a-n of FIG. 13) for this Variable-Pool (1640 of FIG. 11 and 1900 of FIG. 12) has been declared insolvent by another component.

VP-DIGITAL-BUSINESS

The VP-Digital-Business (1910 of FIG. 12) holds a Cursor-Identification (5030 of FIG. 26, 6635 of FIG. 19 and 7620 of FIG. 24) to the Digital-Business (8800 of FIG. 29) that is currently being processed by this Item-Processor (1840, 1830, 1820 of FIG. 12 and 2480a-n of FlG. 13) and is located by the Digital-Business-Execution-Sequence (6810 of FIG. 20 and 8000 of FIG. 25).

VP-BANK-ACCOUNT

The VP-Bank-Account for (1920 of FIG. 12) holds a Cursor-Identification (5030 of FIG. 26, 6635 of FIG. 19 and 7620 of FIG. 24) to the Bank-Account-Field (8890 of FIG. 29) for the executing Digital-Business (8800 of FIG. 29) that is used to check solvency. OTHER-CACHED-ITEMS

Other-Cached-ltems (1925 of FIG. 12) can hold any other state information associated with the Digital-Business (8800 of FIG. 29) being executed by this Item-Processor (1840, 1830, 1820 of FIG. 12 and 2480a-n of FIG. 13) that can be used to accelerate its execution.

ITEM-PROCESSOR

The function of the Item-Processor (1840, 1830, 1820 of FIG. 12 and 2480a-n of FIG. 13) is to execute UPTs (10615, 10625, 10635, 10645 and 10655 of FIG. 37) within the Kl-Switcher (1630 of FIG. 11 and 1800 of FIG. 12 and 1630 of FIG. 9). On receiving the On-Signal (1740 of FIG. 9) from the GL-Boptstrapper (1610 of FIG. 9) Item-Processors transmit the Item-Processor- Notification (1935 of FIG. 12 and 2470 of FIG. 13) to the Digital-Business-Selector (1810 of FIG. 12 and 2400 of FIG. 13) whenever they are ready to execute the next UPT. The Item- Processor then receives the Cursor-Identification (5030 of FIG. 26, 6635 of FIG. 19 and 7620 of FIG. 24) of the Digital-Business (8800 of FIG. 29) that it is required to execute from the Digital- Business-Selector. From the Digital-Business reference alone, the Item-Processor is required to select a single stack from which it is to process a single UPT. This is known as a Digital- Business-Cycle (DBC). The Item-Processor will continue to transmit the Item-Processor- Notification (1935 of FIG. 12) to the Digital-Business-Selector each time it executes a UPT until the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FlG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) is Shutdown.

STACK SELECTION

Each Item-Processor (1840, 1830, 1820 of FlG. 12 and 2480a-n of FIG. 13) must determine the stack to process. If neither the Governance-Layer (6475 of FIG. 18), nor the Digital-Business (8800 of FIG. 29) are involved in a periodic save (see UPT-Cycler), the stacks are selected with a specific precedence by the Item-Processor. At each iteration, a new stack is selected. A stack with No-Children (see Appendix G) is ignored. The order of precedence is as follows: -

The Realtime-Super-Stack (9411 of FIG. 31) of the DB-Execution (9400 of FIG. 31). The Prepaid-Super-Stack (9412 of FIG. 31) of the DB-Execution (9400 of FIG. 31). The Standby-Super-Stack (9413 of FIG: 31) of the DB-Execution (9400 of FlG. 31). The Idle-Super-Stack (9414 of FIG. 31) of the DB-Execution (9400 of FIG. 31).

The Background-Super-Stack (9415 of FIG. 31) of the DB-Execution (9400 of FIG. 31).

The next Realtime-Stack (10610 of FIG. 37) that contains UPTs (10615 of FIG. 37) from a round-robin of Thread-Instances (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) in the Realtime-Stack-List (10530 of FIG. 36) of the DTE-lnstance (9425 of FIG. 31 and 9800a of FIG. 33).

The next Realtime-Stack that contains UPTs from a round-robin of Thread-Instances (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) in the Realtime-Stack-List (10530 of FIG. 36) of the , GE-lnstance (9435 of FIG. 31 and 10000a of FIG. 34).

The next Prepaid-Stack (10620 of FIG. 37) that contains UPTs (10625 of FIG. 37) from a round- robin of Thread-Instances (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) in the Prepaid- Stack-List (10540 of FIG. 36) of the DTE-lnstance (9425 of FIG. 31 and 9800a of FIG. 33). The next Prepaid-Stack that contains UPTs from a round-robin of Thread-Instances (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) in the Prepaid-Stack-ϋst (10540 of FIG. 36) of the GE-lnstance (9435 of FIG. 31 and 10000a of FlG. 34).

The next Standby-Stack (10630 of FIG. 37) that contains UPTs (10635 of FIG. 37) from a round-robin of Thread-Instances (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) in the Standby-Stack-List (10550 of FIG. 36) of the DTE-lnstance (9425 of FIG. 31 and 9800a of FIG. 33).

The next Standby-Stack that contains UPTs from a round-robin of Thread-Instances (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) in the Standby-Stack-List (10550 of FIG. 36) of the GE-lnstance (9435 of FIG. 31 and 10000a of FIG. 34). The next Idle-Stack (10640 of FIG. 37) that contains UPTs (10645 of FIG. 37) from a round- robin of Thread-Instances (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) in the Idle-Stack- List (10560 of FIG. 36) of the DTE-lnstance (9425 of FIG. 31 and 9800a of FIG. 33). The next Idle-Stack that contains UPTs from a round-robin of Thread-Instances (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) in the Idle-Stack-List (10560 of FIG. 36) of the GE- lnstance (9435 of FIG. 31 and 10000a of FIG. 34). The next Background-Stack (10650 of FIG. 37) that contains UPTs (10655 of FIG. 37) from a round-robin of Thread-Instances (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) in the Background-Stack-List (10570 of FIG. 36) of the DTE-lnstance (9425 of FIG. 31 and 9800a of FIG. 33). The next Background-Stack that contains UPTs from a round-robin of Thread-Instances (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) in the Background-Stack-List (10570 of FIG. 36) of the GE-lnstance (9435 of FIG. 31 and 10000a of FIG. 34).

Thread-Instances (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) are located in the Thread-Group (9835 of FIG. 33, 10055 of FIG. 34 and 10400 of FIG. 36) for priorities 6-15 above of the Active-Thread (9830 of FIG. 33 and 10050 of FIG. 34). Active-Threads are found in both the DTE-lnstance (9425 of FIG. 31 and 9800a of FIG. 33) and the GE-lnstance (9435 of FIG. 31 and 10000a of FlG. 34). The structures of the Thread-Groups is the GE-lnstance and the DTE-lnstance are the same. The next stack that contains UPTs (10615, 10625, 10635, 10645 and 10655 of FIG. 37) in the Thread-Instance (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) is located through the Active-Stacks (10410 of FIG. 36) of the Thread-Group (10400 of FIG. 36).

THREAD CREATION

Each time a Thread-Instance (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) is inserted (see Monitors relating to Emulator-Components) into the Thread-List (10480 of FIG. 36) the following occurs:

The Cursor of the Thread-Instance (10600 of FIG. 37) is shifted to the Rightmost position and spawned, thereby ensuring that the spawned Cursor is pointing to the Realtime-Stack (10610 of FIG. 37). The spawned Cursor is then inserted into the Realtime-Stack-List (10530 of FIG. 36) of the Active-Stacks (10410 of FIG. 36). The Cursor of the Thread-Instance (10600 of FlG. 37) is then moved to the Right and spawned again. This spawned Cursor is pointing to the Prepaid-Stack (10620 of FIG. 37) and the resulting spawned Cursor is inserted into the Prepaid-Stack-List (10540 of FIG. 36) of the Active-Stacks (10410 of FIG. 36). The Cursor of the Thread-Instance (10600 of FIG. 37) is then moved to the Right and spawned again. This spawned Cursor is pointing to the Standby-Stack (10630 of FIG. 37) and the resulting spawned Cursor is inserted into the Standby-Stack-List (10550 of FIG. 36) of the Active-Stacks (10410 of FIG. 36).

The Cursor of the Thread-Instance (10600 of FIG. 37) is then moved to the Right and spawned again. This spawned Cursor is pointing to the Idle-Stack (10640 of FIG. 37) and the resulting spawned Cursor is inserted into the Idle-Stack-List (10560 of FIG. 36) of the Active-Stacks (10410 of FIG. 36).

The Cursor of the Thread-Instance (10600 of FIG. 37) is then moved to the Right and spawned again. This spawned Cursor is pointing to the Background-Stack (10650 of FIG. 37) and the resulting spawned Cursor is inserted into the Background-Stack-List (10570 of FIG. 36) of the Active-Stacks (10410 of FIG. 36).

The next Realtime-Stack (10610 of FIG. 37) that contains UPTs in the Thread-Instance (10485a - 10485n of FIG. 36 and 10600 of FIG. 37) is located by shifting the Cursor of the Realtime- Stack-List (10530 of FIG. 36) to the Right and retrieving the Realtime-Stack from the Thread- Instance-Spawn (10535a - 10535n of FlG. 36) of the Realtime-Stack-List. When the Cursor of the Realtime-Stack-List reaches the Rightmost position, it is then shifted back to the Leftmost position. The same process is repeated in order to locate The next Prepaid-Stack (10620 of FIG. 37) that contains UPTs in the Prepaid-Stack- List (10540 of FIG. 36).

The next Standby-Stack (10630 of FIG. 37) that contains UPTs in the Standby- Stack-List (10550 of FIG. 36). The next Idle-Stack (10640 of FIG. 37) that contains UPTs in the Idle-Stack-List

(.10560 of FIG. 36).

The next Background-Stack (10650 of FIG. 37) that contains UPTs in the Background-Stack-List (10570 of FIG. 36).

In an exemplary implementation, the Item-Processor ensures a homogenous distribution of processing by interleaving stack selection between the DTE-lnstance (9425 of FIG. 31 and 9800a of FIG. 33) and the GE-lnstance (9435 of FIG. 31 and 10000a of FIG. 34).

ITEM-PROCESSOR OPERATION

The exemplary Kl-Switcher (1630 of FIG. 11 and 1800 of FIG. 12) utilises 3 Item-Processors (1820, 1830 and 1840 of FIG. 12) for the execution of software providing that no two Item- Processors operate on the same Digital-Business (8800 of FIG. 29) at the same time. Each of these Item-Processors is identical in function. There may be any number of Item-Processors within a single Ill-Emulator (551 of FlG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) implementation. The primary function of the Item- Processor is to execute the UPT (10615, 10625, 10635, 10645 and 10655 of FIG. 37) in the Leftmost position of its applicable stack (10610, 10620, 10630, 10640 and 10650 of FIG. 37). If the Leftmost Child of a selected Stack is not a UPT, then it is ignored and removed from the Stack. Otherwise, processing is dependent on the Type of the Child being executed. Refer to Appendix B for a full listing of all executable UPTs.

STARTING AND STOPPING RESOURCE-MODEL SCHEDULING

Processing of stacks is attained while adhering to the Resource-Model. The Digital-Business- Selector (1810 of FIG. 12 and 2400 of FIG. 13) selects Digital-Businesses from the following Marketplaces:-

The Realtime-Computation-Schedule (8220 of FIG. 26). The Prepaid-Computation-Schedule (8420 of FIG. 27). The Standby-Computation-Schedule (8040 of FIG. 25). The Idle-Computation-Schedule (8050 of FIG. 25). Every-Digital-Business (6450 of FIG. 18) and Every-Sandbox-Digital-Business (6500 of FIG. 18).

PCS-ltems (8435a - 8435n of FIG. 27 and 8600a of FIG. 28) are inserted onto the Prepaid- Computation-Schedule (8420 of FIG. 27) by the Governance Layer (101 b of FIG. 1 and 202b of FIG. 2) when the Digital-Business (8800 of FIG. 29) makes a booking for computational process. The Governance Layer is also responsible for removing the PCS-ltem from the Prepaid-Computation-Schedule when it has expired.

RCS-ltems (8235a - 8235n of FIG. 26 and 8700a of FIG. 28) are created and inserted onto the Realtime-Computation-Schedule (8220 of FIG. 26) when a UPT is inserted onto an empty Realtime-Stack. Digital-Businesses (8065a - 8065n, 8075a - 8075n of FIG. 25 and 8800 of FIG. 29) are likewise inserted onto the Standby-Computation-Schedule (8040 of FIG. 25) and the Idle-Computation-Schedule (8050 of FIG. 25) when a UPT is inserted into the relative empty Standby-Stack (10630 of FIG. 37) or Idle-Stack (10640 of FIG. 37).

A waste of processing is prevented by removing either the RCS-ltem (8235a - 8235n of FIG. 26 and 8700a of FIG. 28) from the Realtime-Computation-Schedule (8220 of FIG. 26) or the Digital-Business (8065a - 8065n, 8075a - 8075n of FIG. 25 and 8800 of FIG. 29) from the Standby-Computation-Scheduie (8040 of FIG. 25) or the Idle-Computation-Schedule (8050 of FIG. 25) when there is nothing to process at a specific level of priority as follows:

In the event that there are no Children remaining in any of the Realtime-Stacks (10610 of FIG. 37) of the DTE-lnstance (9425 of FIG. 31 and 9800a of FIG. 33) and the Realtime- Stacks of the GE-lnstance (9435 of FIG. 31 and 10000a of FIG. 34), then each Child (9240 of FIG. 30) in the Realtime-Release (9210 of FIG. 30) has its currently selected Child - each an RCS-ltem (9245 of FIG. 30) deleted. Once each of these Children is deleted, the RCS- List (9240 of FIG. 30) to which it belongs is deleted from the Realtime-Release (9210 of FIG. 30) until it is empty. If there are no Children remaining in any of the Standby-Stacks (10630 of FIG. 37) of the

DTE-lnstance (9425 of FIG. 31 and 9800a of FIG. 33) and the Standby-Stacks of the GE- lnstance (9435 of FIG. 31 and 10000a of FIG. 34), and if there is a Child (9250 of FIG. 30) in the Standby-Release (9220 of FIG. 30), then it has its Child (9255 of FIG. 30) deleted and then the Standby-List (9250 of FIG. 22) itself is deleted from the Standby-Release (9220 of FIG. 30).

If there are no Children remaining in any of the Idle-Stacks (10640 of FIG. 37) of the DTE- lnstance (9425 of FIG. 31 and 9800a of FIG. 33) and the Idle-Stacks of the GE-lnstance (9435 of FIG. 31 and 10000a of FIG. 34), and if there is a Child (9260 of FIG. 30) in the Idle-Release (9230 of FIG. 30), then it has its Child (9265 of FIG. 30) deleted. The Idle-List (9260 of FIG. 30) itself is then deleted from the Idle-Release (9230 of FIG. 30).

The process of determing when a Realtime-Stack, Standby-Stack or Idle-Stack is empty, either before or after an insertion of a UPT, is managed through the use of Monitors which are attached to the relative Stacks through the Governance-Layer. This is outside the scope of this patent but may be accomplished through the use of the Pi-Monitor-No-Child and the Pl-Monitor- Has-Child.

ASYNCHRONOUS-BIT-SEQUENCES

An Asynchronous-Bit-Sequence (ABS) is a series of 64-bit blocks of variable length. All Asynchronous-Bit-Sequences are transmitted between Emulator-Components (FIGs 3-8) via the ABS-Dataflow (FIG. 5) by using the ABS-lnterface (5820 of FIG. 15, 6020 of FIG. 16, 6235, 6245 of FIG. 17). Although the Asynchronous-Bit-Sequences can be utilised or cached in any Emulator-Component, they can be stored permanently in the Slow-ABS (5800 of FIG. 15) or temporarily in the Fast-ABS (6000 of FIG. 16) until the Node (200a-e of FIG. 2 and 380, 395 of FIG. 4) shuts down. Software that is comprised solely of UPTs can manage the Asynchronous- Bit-Sequences by:

Attaching them directly to the Sets with the UPT-Create-ABS (see Appendix B). Creating Asynchronous-Bit-Sequences during the execution of AVMF. Creating Asynchronous-Bit-Sequences with an Emulator-Component (FIGs 3-8).

SLOW-ABS

The Slow-ABS (5800 of FIG. 15) is optimised for mass storage with slow transmission rates and supplies data to and from the Plugin-Manager (7600 of FIG. 24), Partner-Channel-Manager (430 of FIG. 5 and 13000 of FIG. 49) and the Fast-ABS (6000 of FIG. 16). These Emulator- Components (FIGs. 3-8) can generate large volumes of information from across the network or from the local host. The Slow-ABS is stored in the Permanent-Storage-B (1130b of FIG. 8 and 5805 of FIG. 15) enabling all Slow-ABS handles stored by the Kl-Memory (see Appendix G) to be retained on shutdown. FAST-ABS

The Fast-ABS (6000 of FIG. 16) provides fast but transient Asynchronous-Bit-Sequences to the 3IP-AVM (17200 of FIG. 58), 3IP-AVMF-Verifier (17200 of FIG. 58), ABS-Bus (6200 of FIG. 17). These Emulator-Components (FIGs 3-8) operate at a high speed and require the fast delivery of 64-bit blocks. On shutdown, all Fast-ABS data is erased as well as the handles stored by the Kl-Memory (see Appendix G) that refers to that data. Any sets that held the Fast-ABS will no longer hold those sequences on start-up.

ABS-BUS

Since the Fast-ABS (6000 of FIG. 16) is transient, it must first be loaded from the Slow-ABS (5800 of FlG. 15) prior to use via the ABS-Bus (6200 of FIG. 17). Furthermore, any data that requires persistence that is generated in the Fast-ABS needs to be stored to the Slow-ABS prior to shutdown. The ABS-Bus is part of the Primary-Dataflow as it receives direction from the UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9) via the UPT-Execution-lnterface (1795, 1635 of FIG. 11 and 1825, 1835, 1845, 1950 of FIG. 12) to move Asynchronous-Bit-Sequences between the Fast-ABS and the Slow-ABS.

ABS-INTERFACE

The Fast-ABS (6000 of FlG. 16) and Slow-ABS (5800 of FIG. 15) are the cornerstones of the ABS-Dataflow. Both Asynchronous-Bit-Sequences are accessed via Cursor-Identification (5030 of FIG. 26, 6635 of FIG. 19 and 7620 of FIG. 24) handles that are logically stored on Manabars- Sets (see Appendix G) and are physically stored in the Kl-Memory (see Appendix G).

HUMAN-COMMUNICATION-MANAGER

The Human-Communication-Manager or HCM (700 of FIG. 4 and 900 of FIG. 5) manages the ILl-Phenotype (6860 of FIG. 20) that is responsible for communication with the user. The ILI- Phenotype utilises a sensory model - the Mesh-Blueprint - where communication is channelled through an abstract human body (see Appendix F for an example as to how abstract human communication can be implemented using sets). The reasons and specification of the Mesh- Blueprint are beyond the scope of the patent - it is enough to say here that information may become both future and backwards compatible and is a fundamental property of a Universal Virtual Computer (UVC). Therefore, older software is able to communicate with the new Ill- Emulators and old Ill-Emulators (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FlG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) are able to communicate with new software. The abstract human interface need never change while communication is limited to humankind. However, although the Ill-Emulator specification does not change, it may be expanded on to increase sensory resolution without affecting the context of the data that passes through it. For example, an early version of the specification may only describe communication with the retina and cochlea. A later specification may be updated to include olfactory information. Since the Mesh-Blueprint may change, a standard embodiment of the Human- Communication-Manager (700 of FIG. 4 and 900 of FIG. 5) is expected to emerge.

The Human-Communication-Manager is responsible for:

Identifying versions of the Mesh-Blueprint.

Projecting the sensory experience from an identified Manabars-Sets (see Appendix G) in the

Mesh-Blueprint-Context (7830 of FIG. 40) and encoding a sensory perception that is generated from the human user back into the identified Manabars-Set.

Any mechanism to automatically update the Human-Communication-Manager (700 of FIG. 4 and 900 of FIG. 5) so that its can interpret newer versions of the Mesh-Blueprint are beyond the scope of this patent, but do not limit it.

PARTNER-CHANNEL-MANAGER

The Partner-Channel-Manager or PCM (430 of FIG. 3, 630 of FIG. 4, 830 of FIG. 5, 1030 of

FIG. 6, 1230 of FIG. 7, 1430 of FIG. 10 and 13000, 13100, 13120 and 13140 of FIG. 49)

Emulator-Component has 5 distinct roles as determined by the PCM-lnterface (12056, 12066 and 12076 of FIG. 44, 12226, 12236 and 12246 of FIG. 45 and 13025, 13105, 13125 and 13145 of FIG. 49 and FIG. 70):-

To set up connections between Nodes (200a - 20Oe of FIG. 2, 12010a - 1201On of FIG. 44,

12210a - 1221On of FIG. 45 and 13090, 13110 and 13130 of FIG. 49) thereby establishing the connection between Node partners. The process of linking Nodes is beyond the scope of this patent, as the implementation of the PCM-lnterface can be performed in many ways and may use many transport layers such as TCP/IP, Frame Relay and point-to-point protocols.

Project each Node partner by the creation of an Nl-Partner (7046a - 7046n of FIG. 21 and 12400 of. FIG. 46). Each Nl-Partner is inserted into the NP-List (7045 of FIG. 21 and

12280, 12290 and 12300 of FIG. 45). Transmit data between Digital-Businesses (8800 of FIG. 29) at a specific rate by performing deep scanning of the Nl-Partners (12400 of FIG. 46 and 12285a, 12285b, 12295a, 12295b, 12305a and 12305b of FIG. 45) to transmit bandwidth in adherence to the Resource-Model. Perform a cross-compilation on the Slow-ABS (5800 of FIG. 15) primitive of any UPTVA VM- Verify (see Appendix B) that represents Asynchronous-Virtual-Machine-Format or AVMF

(see Appendix E). The cross-compilation must ensure that all Asynchronous-Virtual- Machine-Instructions or AVMI (see Appendix E again) are able to execute on the destination Node (200a-e of FIG. 2 and 380, 395 of FIG. 4) and represent a logically identical execution. A new Slow-ABS primitive that contains the cross-compilation is generated and replace as the original in the UPT-AVM-Verify (see Appendix B).

Commit money transfers to and from Digital-Businesses (8800 of FIG. 29) on the Node partner (12010a, 12010b, 1201On of FIG. 44 and 12210a, 12210b, 1221On of FIG. 45). The total amount of money transferred to local Digital-Businesses (8800 of FIG. 29) on behalf of the Node partner (12010a, 12010b, 1201On of FIG. 44 and 12210a, 12210b, 1221 On of FIG. 45) is stored to the Float primitive of the Total-Credit-Transfers-Field Child (12897 of FIG.

48). Transfers are always performed in local currency of the Node partner, so it needs to be converted to the local Node currency by multiplying it by the Local-Currency-Exchange (12899 of FIG. 48). It is the responsibility of the Node partners themselves to arrange the appropriate payment to clear unbalanced credit transfers in a similar way that a bank makes bulk transfers to cater for drifting surplus or deficit. Alternatively, some implementations may simply adjust the Local-Currency-Exchange-Field (12896 of FIG. 48) to enable the imbalance to self-correct.

CONNECTING NODES

The actual connection to Node partners (12010a - 1201On of FIG. 44 and 12210a, 12210b, 1221On of FIG. 45) is an implementation specific function. In implementing the PCM-I nterfa.ce (12056, 12066 and 12076 of FIG. 44, 12226, 12236 and 12246 of FIG. 45 and 130125, 13105, 13125 and 13145 of FIG. 49), the Partner-Channel-Manager (13000, 13100, 13120 and 13140 of FIG. 49) is required to manage Nl-Partners (7046a - 7046n of FIG. 21 and 12400 of FIG. 46) from the NP-List (7045 of FIG. 21) on:

By creating an Nl-Partner on a new connection. By deleting an Nl-Partner if a connection has been removed.

The PCM-I nterface is implemented in pairs (12056, 12066 and 12076 of FIG. 44), so there is a positive (+) and a negative (-) implementation for each Node partner corresponding to a single Nl-Partner. Each Nl-Partner structure presents a Node (12010a - 1201On of FIG. 44) only when:

> Both Node partner administrators have agreed to connect to each other. The physical implementation of the PCM-lnterface has enabled the connection. .

For the Node partner to be fully online, the Children of the Physical-Connection-Field (12470 of FIG. 46) and the Logical-Connection-Field (12480 of FIG. 46) both need to have a Type set to Type-True. If the Child of the Physical-Connection-Field (12470 of FIG. 46) has its Type set to Type-True, then the connection is physically established, and this can only be set by the Partner-Channel-Manager (13000 of FIG. 49). The Governance Layer (101b of FIG. 1 and 202b of FlG. 2) may reassign the Cursor of the Logical-Connection-Field to a Child with its Type set to Type-False if it wishes to prevent the logical connection to this partner, otherwise it is set to Type-True. A Child with its Type set to Type-False inside the Logical-Connection-Field (12480 of FIG. 46) is a suspend directive and prevents new Digital-Businesses (8800 of FIG. 29) from being formed in either direction by the Partner-Channel-Manager, as well as suspending any transmission between Digital-Businesses on the partner and the local host. However, there is nothing that limits a Digital-Business that is already established on the Partner from attempting to find another route to the local host during the suspend directive. While the Types of both the Children of the Physical-Connection-Field (12470 of FIG. 46) and the Logical-Connection-Field (12480 of FIG. 46) are set to Type-True all transmissions between the Nodes (12010a - 1201On of FIG. 44 and 13090, 13110 and 13130 of FIG. 49) are then made through the PCM-lnterface (12056, 12066 and .12076 of FIG. 44 and 13025, 13105, 13125 and 13145 of FIG. 49).

PRESENTING DB-PARTNERS

An Nl-Partner (12400 of FIG. 46) keeps track of all information necessary to maintain a connection between two Node partners (12010a - 1201On of FIG. 44 and 12210a, 12210b, 1221On of FIG. 45). A DB-Partner (13200 of FIG. 50) retains all information necessary to maintain a connection between two Digital-Businesses (8800 of FIG. 29). A single Digital- Business may propagate across to one or more Node partner. A single Digital-Business may also propagate across to a single Node partner one or more times. For each of the propagations that occur, a DB-Partner (12436a - 12436n of FIG. 46 and 13200 of FIG. 50) is created (see Digital-Business Propagation below). A single Digital-Business stores each DB- Partner that it is connected to, in Node-Communication (8930 of FIG. 29 and 14200 of FIG. 55), no matter what Node (200a-e of FIG. 2 and 380, 395 of FIG. 4) it resides on. A single Nl- Partner (12400 of FIG. 46) stores a DB-Partner (12436a - 12436b of FIG. 46) in the Node- Transfers-Field (12430 of FIG. 46) for each Digital-Business (8800 of FIG. 29) that has propagated across to the corresponding partner.

DIGITAL-BUSINESS PROPAGATION

When a Digital-Business (8800 of FIG. 29) wants to propagate to either the Local Node (12010a - 1201On of FIG. 44) or a Node partner the Governance Layer (101b of FIG. 1, 202b of FlG. 2) will insert a PCM-Connection-Request (21000 of FIG. 62) into the Child of the PCM-Notify-Field (7060 of FIG. 21). How the propagation occurs is implementation specific, however, 2 possible configurations are:

PCM-Connection-Request-lmage (21000 of FIG. 62) is the transmission of the entire executable image for the Digital-Business (8800 of FIG. 29). The PCM-Connection-Request contains only two Fields inside the Data (21040 of FIG. 62). These Fields hold the Startup-Funding-Field (21060 of FIG. 62) and the DTE-lnstance (21080 of FIG. 62 and 9800a of FIG. 33) of the Digital-Business image to be executed on the target Node. On propagation the Float value of the Startup-Funding is added to the Float value of the Child of the Bank-Account-Field (8890 of FIG. 29) of the new Digital-Business (8800 of FIG. 29) on the target Node. Startup-Funding is specified in the target Node currency. The DTE-lnstance is inserted into the Design-Time- Execution (9420 of FIG. 31) and the Digital-Business is inserted into Every-Digital-Business-List (6455 of FIG.33).

PCM-Connection-Request-Object-Orientation (21200 of FIG. 64) allows the DTE-lnstance (21080 of FIG. 62 and 9800a of FIG. 33) to be constructed utilising the Object-Orientation support of the invention. The PCM-Connection-Request-Object-Orientation has 3 Fields inside the Data (21240 of FIG. 64). These being the Startup-Funding-Field (21250 of FIG. 64), the Unlinked-Class-List-Field (21270 of FIG. 64) and the Parameters-Field (21290 of FIG. 64). The Float value of the Startup-Funding (21260 of FIG. 64) is added to the Float value of the Child of the Bank-Account-Field (8890 of FIG. 29) of the new Digital-Business (8800 of FIG. 29). The Unlinked-Class-List and the Parameters are used to construct the Boot-Data-Set (9855 of FlG. 33 and FIG. 39) that is then inserted into the DB-Boot-Field (9850 of FIG. 33) of the DB-Logic (9840 of FIG. 33) in the DTE-lnstance (9800a of FIG. 33). It is the responsibility of the Governance Layer to ensure that the DTE-lnstance (6475 of FIG. 18) of the DTE-Template- Field (6481 of FIG. 18) has suitable booting code to link the Object-Orientated structures contained in the Boot-Data-Set.

There are three main steps to propagation. Each step is performed by alternate Node partners (12010a, 12010b, 1201On of FIG. 44 and 12210a - 1221On of FIG. 45). The three steps are: The Partner-Channel-Manager (13000 of FIG. 49) sets a Monitor (5200 of FIG. 14) on to PCM- Notify (7065 of FIG. 21) to listen for the instructions of a PCM-Connection-Request-lmage (21000 of FIG. 62) or a PCM-Connection-Request-Object-Orientation (21200 of FIG. 64). When the Monitor is triggered, the following occurs:

The Partner-Channel-Manager (13000 of FIG. 49) creates a new DB-Partner (13200 of FIG. 50) and inserts it into the NT-List (12435 of FIG. 46) of the Nl-Partner (12400 of FIG. 46), and the DB-Partners-Field (21110 of FIG. 63 and 21620 of FIG. 66) of the PCM-Mapped-Set (21100 of FIG. 63) of the relevant PCM connection request.

The PCM-Mapped-Set (21100 of FIG. 63) is then inserted into both the RM-Field (13290 of FIG. 50) and the PCM-Field (13300 of FIG. 50) located in the Entangled-Sets (13220 of FIG. 50) of the newly created DB-Partner (13200 of FIG. 50). At this point in time the Local-DB-Field (13310 of FIG. 50) of Connection-Unfrozen (13230 of FIG. 50) will have a Child with its Type set to Type-True to indicate that the

Digital-Business (8800 of FIG. 29) is ready to transmit on the Local Node (12210a - 1221On of FIG. 45). However the Child of the Peer-DB-Field (13320 of FIG. 50) will have a Type of Type-False to indicate that the peer Digital-Business (8800 of FIG. 29) is unable to accept any transmissions. The Node (12210a - 1221On of FIG. 45) that the Digital-Business (8800 of FIG. 29) wants to propagate to is located through the Peer-Node-Field (21150 of FIG. 63) of the relevant PCM connection request.

The final step in setting up the DB-Partner (13200 of FIG. 50) before sending the relevant PCM connection request to the Node partner (12210a - 1221On of FIG. 45) is to insert the DB-Partner into either the Local-Node-Communication-List (14230 of FIG. 55) or the Partner-Node-Communication-List (14240 of FIG. 55) of the Digital-Business (8800 of FIG. 29), depending on whether the Child of the Peer-Node-Field (21150 of FIG. 63) of the connection request is the Local-Node or a Node partner. Although the actual transmission of the request to the Node partner (12210a - 1221On of

FIG. 45) is implementation specific and is therefore beyond the scope of this patent, part of the transmission will involve identifying PCM-Mapped-Sets (13305 of FIG. 50, 21020 of FIG. 62, 21100 of FIG. 63, 21220 of FIG. 64 and 21420 of FIG. 65) and locating a matching Set on the Node partner. If there is no existing matching Mapped-Set then one will be created (see UPT-Map and UPT-Unmap of Appendix B).

On receipt of the relevant PCM connection request the Partner-Channel-Manager (13000 of FIG. 49) will: Create a new Digital-Business (8800 of FIG. 29) signalled by the appropriate Data (21040 of FIG. 62) of the relevant PCM connection request to enable the Digital- Business to function, as previously specified. Insert the newly created Digital-Business into Every-Digital-Business-List (6455 of FIG.

18).

Create a new DB-Partner (13200 of FIG. 50) and insert it into both the Node- Communication (8930 of FlG. 29 and 14200 of FIG. 55) of the Digital-Business (8800 of FIG. 29 and 14250 of FIG. 55), and the NT-List (12435 of FIG. 46) of the Nl-Partner (12400 of FIG. 46).

Insert the newly created DB-Partner (13200 of FIG. 50) into the Founder- Communication-Field (8920 of FIG..29) of the Digital-Business (8800 of FIG. 29) in order for the newly created Digital-Business to locate its parent Digital-Business. The newly created DB-Partner (13200 of FIG. 50) is also inserted into the DB-Partner- Field (21110 of FIG. 63 and 21620 of FIG. 66) of the PCM-Mapped-Set (21100 of FIG.

63 and 21220 of FIG. 64).

The PCM-Mapped-Set (21100 of FIG. 63 and 21220 of FIG. 64) is inserted into the PCM-Field (13300 of FIG. 50) of the DB-Partner. At this point in time the RM-Field (13290 of FIG. 50) will remain empty, as the newly created Digital-Business (8800 of FIG. 29) is unaware of the connection. Also at this point in time both the Local-DB-Field (13310 of FIG. 50) and the Peer-DB-Field (13320 of FIG. 50) of Connection-Unfrozen (13230 of FIG. 50) will have a Child with its Type set to Type-True inserted, to indicate that the Digital-Business (8800 of FIG. 29, 12286 and 12306 of FIG. 45) is ready to transmit on both Nodes (12210a and 1221On of FIG. 45). Finally the Partner-Channel-Manager (13000 of FIG. 49) will send back to the Node partner (13090, 13110 or 13130 of FIG. 49) a PCM-Connection-Result (21400 of FIG. 65) with the Type of the Result (21440 of FIG. 65) set to Type-True or Type-False to represent whether it was a successful propagation.

On receipt of a PCM-Connection-Result (21400 of FIG. 65) the Partner-Channel-Manager (13000 of FIG. 49) will:

Check the Type of the Child of the Result-Field (21430 of FIG. 65). If the Type is of Type-False then the Partner-Channel-Manager (13000 of FIG. 49) will delete all references to the DB-Partner (13200 of FIG. 50) using all spawned Cursor-Identifications listed in the Release-List (13330 of FIG. 50) of the DB-Partner.

If the Type is of Type-True then the Partner-Channel-Manager (13000 of FIG, 49) will insert a Child with its Type set to Type-True into the Peer-DB-Field (13320 of FIG. 50) of Connection-Unfrozen (13230 of FIG. 50) to indicate that the Peer Digital-Business (12286 and 12306 of FIG. 45) is ready to accept transmissions.

TRANSMITTER

The Transmitter (13020 of FIG. 49) is a component of the Partner-Channel-Manager (13000, 13100, 13120 and 13140 of FIG. 49) that is responsible for transmitting data between Nodes (13090, 13110 and 13130 of FIG. 49). Nodes are responsible for the management and reservation of outbound bandwidth only. The adjacent partners manage and reserve the inbound data. For a Digital-Business (12286 and 12306 of FIG. 45) to truly control its own inbound bandwidth, it will need to communicate with its peer Digital-Business and have it perform the reservation. Node owners are required to manage any financial imbalances with their partner for asymmetric costs on a channel.

The management and reservation of bandwidth adheres to the rules of the Resource-Model when communicating between Node partners (12010a -1201On of FIG. 44). The 5 Marketplaces are located in the Active-Booking-Schedules (14010 of FIG. 54). These Marketplaces are:

AR-Schedule (14030 of FIG. 54).

AP-Schedule (14040 of FIG. 54).

AS-Schedule (14050 of FIG. 54).

Al-Schedule (14060 of FIG. 54).

Node-Transfers-Field (12430 of FIG. 46).

When a Digital-Business (12286 and 12306 of FIG. 45) wants to communicate with a peer

Digital-Business (8800 of FIG. 29) the Governance Layer (101 b of FIG. 1 and 202b of FIG. 2) will insert a PCM-Transfer-ltem (13816, 13826, 13836, 13846 and 13856 of FIG. 53) onto the relative List (13815, 13825, 13835, 13845 and 13855 of FIG. 53) located in Send (13800 of FiG. 53) of the corresponding DB-Partner (13200 of FIG. 50). The Transmitter (13020 of FIG. 49) regularly cycles through the Active-Booking-Schedules (14010 of FIG. 54) looking for PCM-

Transfer-ltems that are ready to be sent in the following order:

The Transmitter searches all DB-Partners (14036 of FIG. 54 and 13200 of FIG. 50) from Left to Right in the AR-Schedule (14030 of FIG. 54) checking to see if the DB-Partner has any PCM- Transfer-ltems (13816 of FIG. 53) in the SR-List (13815 of FIG. 53). If a PCM-Transfer-ltem is found the Transmitter will check the Active-Prepaid-Booking-List (12740 of FIG. 47) to see if the DB-Partner has any Prepaid-Contract-lnstances (12745a - 12745n of FIG. 47). If it does then the PCM-Transfer-ltem is transmitted utilising the Prepaid-Contract-Instance, otherwise the PCM-Transfer-ltem is transmitted utilising a Realtime-Contract-Instance (12645a - 12645n of FIG. 47) located in the Active-Realtime-Booking-List (12620 of FIG. 47). If no PCM-Transfer-ltems (13816 of FIG. 53) are found in any of the SR-Lists (13815 of FIG. 53) of the DB-Partners in the AR-Schedule (14030 of FIG. 54) then the Transmitter (13020 of FIG.

49) will move to the AP-Schedule (14040 of FIG. 54).- Each Prepaid-Contract-Instance (14046 of FIG. 54 and 14500 of FIG. 56) is located from Left to Right and the relative DB-Partner (13200 of FIG. 50) is found through the Owner-ID-Field (14510 of FIG. 56). The Transmitter will check the SR-List (13815 of FIG. 53), SP-List (13825 of FIG. 53), SS-List (13835 of FIG. 53), Si-List (13845 of FIG. 53) and SB-List (13855 of FIG. 53), in that order, for any PCM-Transfer- ltems (13816, 13826, 13836, _.13846 and 13856 of FIG. 53 and 21600 of FIG. 66). If a PCM- Transfer-ltem is found it is transmitted using the Prepaid-Contract-Instance. If no PCM-Transfer-ltems (13816 of FIG. 53) are found in any of the DB-Partners (13200 of FIG.

50) in the Prepaid-Contract-lnstances (14046 of FIG. 54 and 14500 of FIG. 56) in the AP- Schedule (14040 of FIG. 54), the, Transmitter (13020 of FIG. 49) will move to the AS-Schedule

(14050 of FIG. 54) and, working from Left to Right, will check the SR-List (13815 of FIG. 53), SP-List (13825 of FIG. 53) and SS-List (13835 of FIG. 53), in that order, for any PCM-Transfer- ltems. If no PCM-Transfer-ltems (13816 of FIG. 53) are found in any of the DB-Partners (14056 of FIG. 54) in the AS-Schedule Schedule (14050 of FIG. 54) then the Transmitter (13020 of FIG. 49) will move to the Al-Schedule (14060 of FIG. 54) and, working from Left to Right, will check the SR-List (13815 of FIG. 53), SP-List (13825 of FIG. 53), SS-List (13835 of FIG. 53) and Si-List (13845 of FIG. 53), in that order, for any PCM-Transfer-ltems. If no PCM-Transfer-ltems (13816 of FIG. 53) are found in the Al-Schedule (14060 of FIG. 54) then the Transmitter (13020 of FIG. 49) will search for any PCM-Transfer-ltems in the SR-List (13815 of FIG. 53), SP-List (13825 of FIG. 53), SS-List (13835 of FIG. 53), Si-List (13845 of FIG. 53) and SB-List (13855 of FIG. 53), in that order, for each DB-Partner (12436a - 12436n of FIG. 46) in the Node-Transfers-Field (12430 of FIG. 46) in each and every Nl-Partner (7046a - 7046n of FIG. 21 and 12400 of FIG. 46).

The actual transmission of the PCM-Transfer-ltem (13816 of FIG. 53) via the PCM-lnterface between Nodes (13090, 13110 and 13130 of FIG. 49) is implementation specific and is therefore beyond the scope of this patent. If at any time a Child with a Type of Type-False is inserted into either the Local-DB-Field (13310 of FIG. 50) or the Peer-DB-Field (13320 of FIG. 50) of the DB-Partner (13200 of FIG. 50), or the Physical-Connection-Field (12470 of FIG. 46) or the Logical-Connection-Field (12480 of FIG. 46) of the Nl-Partner (12400 of FIG. 46), then all transmissions for the DB-Partner are frozen until all Fields hold a Child with its Type set to Type-True. This is accomplished by: Removing the DB-Partner (13200 of FIG. 50 and 14036, 14056 and 14066 of FIG. 54) from any Active-Booking-Schedules (14010 of FIG. 54) using the spawned Cursor-Identifications in the Active-Resource-Release (13410 of FIG. 51), of the PCM-Resource-Release (13400 of FIG. 51).

Inserting the DB-Partner (13200 of FIG. 50 and 14076, 14096 and 14106 of FIG. 54) into the corresponding Frozen-Booking-Schedules (14020 of FIG. 54) using the KI-lnsert-And-Spawn method.

The resulting spawned Cursor-Identification is then inserted into the corresponding Frozen- Resource-Release (13420 of FIG. 51) of the PCM-Resource-Release (13240 of FIG. 50 and 13400 of FIG. 51).

Searching through all Prepaid-Contract-lnstances (12755a - 12755n of FIG. 47 and 14500 of FlG. 56) of the DB-Partner (13200 of FIG. 50) and remove the Prepaid-Contract-lnstance from the APS-List (14045 of FIG. 54) using the Spawned-APS-List (14575 of FIG. 56) held in the Active-Resource-Release-Field (14570 of FIG. 56).

Insert each Prepaid-Contract-lnstance (12755a - 12755n of FIG. 47 and14500 of FIG. 56) into the FPS-List (14085 of FIG. 54) of the Frozen-Booking-Schedules (14020 of FIG. 54) using the KI-lnsert-And-Spawn method. Inserting the resulting Spawned-FPS-List (14585 of FIG. 56) into the Frozen-Resource- Release-Field (14580 of FIG. 56) of the Prepaid-Contract-lnstance (14500 of FIG. 56).

When the DB-Partner (13200 of FIG. 50 and 14076, 14096 and 14106 of FIG. 54) is once more

Unfrozen then the DB-Partner is removed from the Frozen-Booking-Schedules (14020 of FIG.

54) using the Frozen-Resource-Release (13420 of FIG. 51) and is once more inserted into the Active-Booking-Schedules (14010 of FIG. 54) using the spawned Cursor-Identifications found in the Active-Resource-Release (13410 of FIG. 51). All Prepaid-Contract-lnstances (12755a -

12755n of FIG. 47 and 14500 of FIG. 56) are also reinserted into the APS-List (14045 of FIG.

54) and deleted from the FPS-List (14085 of FIG. 54) using the Spawned-FPS-List (14585 of

FIG. 56) of the Frozen-Resource-Release-Field (14580 of FIG. 56).

SCHEDULER

The Scheduler (13030 of FIG. 49) is a component of the Partner-Channel-Manager (13000, 13100, 13120 and 13140 of FIG. 49) that is responsible for the maintenance of Realtime- Contract-Instances (12645a - 12645n and 12655a - 12655n of FIG. 47 and 14400 of FIG. 56) and Prepaid-Contract-lnstances (12745a - 12745n and 12755a - 12755n of FIG. 47 and 14500 of FIG. 56) in the Booking-Schedules (14000 of FIG. 54). Bookings for bandwidth are created for each individual DB-Partner (13200 of FIG. 50) through the Governance Layer (101b of FIG. 1 and 202b of FIG. 2). This process is implementation specific and so cannot be defined through this patent but the result is a Prepaid-Contract-lnstance or a Realtime-Contract- Instance being inserted into the correct place in Bandwidth-Bookings (13340 of FIG. 50 and 12600 of FIG. 47) of the DB-Partner. Each DB-Partner (13200 of FIG. 50) may have one or more bookings for bandwidth. Each Prepaid-Contract-lnstance (14500 of FIG. 56) and Realtime-Contract-lnstance (14400 of FIG. 56) contains a Start-Time (14445 and 14545 of FIG. 56) and a Duration (14455 and 14555 of FIG. 56) time. It is the responsibility of the Scheduler (13030 of FIG. 49) to cycle through the Bandwidth-Bookings (13340 of FIG. 50 and 12600 of FIG. 47), of each DB-Partner (12436a - 12436n of FIG. 46 and 13200 of FIG. 50), of each Nl- Partner (7046a - 7046n of FIG. 21 and 12400 of FIG. 46), checking the Active-Realtime- Booking-List (12640 of FlG. 47), the Suspended-Realtime-Booking-List (12650 of FIG. 47), the Active-Prepaid-Booking-List (12740 of FIG. 47) and the Suspended-Prepaid-Booking-List (12750 of FIG. 47) looking for the following:

While cycling through the Active-Realtime-Booking-List (12640 of FlG. 47) the Scheduler (13030 of FIG. 49) is checking for any Realtime-Contract-Instances (12645a - 12645n of FIG. 47 and 14400 of FIG. 56) whose Duration (14455 of FIG. 56) time has expired. Realtime- Contract-Instances are inserted into the Active-Realtime-Booking-List in the order of their duration expiry time. The Scheduler stops cycling the lists once a valid booking is encountered. Any Realtime-Contract-lnstances that have expired will be deleted from the Active-Realtime- Booking-List.

While cycling through the Active-Prepaid-Booking-List (12740 of FIG. 47) the Scheduler (13030 of FIG. 49) is checking for any Prepaid-Contract-lnstances (12745a - 12745n of FIG. 47 and 14500 of FIG. 56) whose Duration (14555 of FlG. 56) time has expired. Prepaid-Contract- Instances are inserted into the Active-Prepaid-Booking-List in order of when their duration expiry time. The Scheduler stops cycling the lists once a valid booking is encountered. Any Prepaid-Contract-lnstances that have expired will be deleted from the APS-List (14045 of FIG. 54) using the Spawned-APS-List (14575 of FIG. 56) before also being deleted from the Active- Prepaid-Booking-List. While cycling through the Suspended-Realtime-Booking-List (12650 of FIG. 47) the Scheduler (13030 of FIG. 49) is checking for any Realtime-Contract-lnstances (12655a - 12655n of FIG. 47 and 14400 of FIG. 56) whose Start-Time (14445 of FIG. 56) has been reached. These Realtime-Contract-lnstances are then inserted into the correct position in the Active-Realtime- Booking-List (12640 of FlG. 47) depending on the duration (14455 of FIG. 56) time of the Realtime-Contract-lnstance. These Realtime-Contract-lnstances are then deleted from the Suspended-Realtime-Booking-List List (12650 of FIG. 47). Realtime-Contract-lnstances are placed in the Suspended-Realtime-Booking-List in order of when the Start-Time is reached. The Scheduler stops cycling the lists once a valid booking is encountered. While cycling through the Suspended-Prepaid-Booking-List (12750 of FIG. 47) the Scheduler (13030 of FIG. 49) is checking for any Prepaid-Contract-lnstances (12755a - 12755n of FIG. 47 and 14500 of FIG. 56) whose Start-Time (14545 of FIG. 56) has been reached. These Prepaid- Contract-lnstances are then inserted into the correct position in the Active-Prepaid-Booking-List (12740 of FIG. 47) depending on the Duration (14555 of FIG. 56) time of the Prepaid-Contract- Instance. These Prepaid-Contract-lnstances are then deleted from the Suspended-Prepaid- Booking-List (12750 of FIG. 47). Prepaid-Contract-lnstances are placed in the Suspended- Prepaid-Booking-List in order of when the Start-Time is reached. The Scheduler stops cycling the lists once a valid booking is encountered. Finally the Prepaid-Contract-lnstance is inserted into the APS-List (14045 of FIG. 54) in the Rightmost position using the KI-lnsert-And-Spawn (see Appendix G) method with the resulting Spawned-APS-List (14575 of FIG. 56) being inserted into the Active-Resource-Release-Field (14570 of FIG. 56) of the Prepaid-Contract- lnstance. A single Prepaid-Contract-lnstance may only be inserted onto the APS-List once.

A DB-Partner (14036 of FIG. 54 and 13200 of FIG. 50) is inserted onto the ARS-List (14035 of FIG. 54) of the Active-Booking-Schedules (1,4010 of FIG. 54) when a PCM-Transfer-ltem (21600 of FIG. 66) is inserted onto the SR-List (13815 of FIG. 53) of the Send (13800 of FIG. 53) in Transfers (13260 of FIG. 50 and 13600 of FIG. 53), only if the DB-Partner has bookings for Realtime-Bandwidth. A DB-Partner is also inserted onto the ASS-List (14055 of FIG. 54) and AIS-List (14065 of FIG. 54) of the Active-Booking-Schedules (14010 of FIG. 54) when PCM-Transfer-ltems are inserted onto either the SS-List (13835 of FIG. 53) or Si-List (13845 of FIG. 53) of the Send in Transfers. A DB-Partner is deleted from the ARS-List (14035 of FIG. 54), ASS-List (14055 of FIG. 54) or AIS-List (14065 of FIG. 54) of the Active-Booking-Schedules s (14010 of FIG. 54) when the corresponding SR-List (13815 of FIG. 53), SS-List (13835 of FIG. 53) or Si-List (13845 of FIG. 53) has been emptied.

ASYNCHRONOUS-DUPLICATOR

The Asynchronous-Duplicator (400 of FlG. 5 and 1660 of FIG. 9) is responsible for the duplication of a single Child by implementing the UPT-Execution-lnterface (475 of FIG. 3, 6255 of FIG. 17 and FlG. 67) and uses the Kl-lnterface (see Appendix G) to perform the actual duplication. The Asynchronous-Duplicator interprets the UPT (see Appendix B) provided by the spawned stack reference listed as parameter [A] in the UPT-Execution-lnterface (21800 of FIG. 67). This UPT may be of Type:

Type-UPT-Recursive-Copy copies each Child including all their respective Children recursively so that the result represents a perfect copy (see UPT-Recursive-Copy of Appendix B). Type-UPT-Denatured-Recursive-Copy copies a set while denaturing it (see UPT-Denatured- Recursive-Copy of Appendix B).

Type-UPT-Copy-AII-Children only copies each Child and will not step into each of their Children, so represents only a partial or flat copy (see UPT-Copy-Ali-Children of Appendix B). Type-UPT-Entangled-Recursive-Copy copies a set while preserving its entangled properties (see UPT-Entangled-Recursive-Copy of Appendix B).

Type-UPT-Entangled-Denatured-Recursive-Copy copies a set while both preserving its entangled properties and denaturing it (see UPT-Entangled-Denatured-Recursive-Copy of Appendix B).

The Asynchronous-Duplicator (400 of FIG. 5 and 1660 of FIG. 9) doesn't process the duplication instructions in the order that they arrive. Instead, it utilises a realtime schedule and prepaid schedule that can be implemented in many ways, providing that it is consistent with the Resource-Model of the invention. See UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9) and Partner-Channel-Manager (13000 of FIG. 49) for exact examples for as to how the Resource- Model can be implemented.

This preserves consistent operation for all Digital-Businesses (8800 of FIG. 29) that may want to use the Asynchronous-Duplicator (400 of FIG. 5 and 1660 of FIG. 9). By enabling managed access to the Asynchronous-Duplicator by using the Resource-Model, it prevents a single Digital-Business from overloading the Asynchronous-Duplicator.

Once the duplication has been achieved, a Child with its Type set to Type-Unlock (see Appendix A) is inserted into the Neutral position of the Activity-Status-Field (9440 of FIG. 31) in order to release this Digital-Business (8800 of FIG. 29) and the UPT is removed from the stack.

The Asynchronous-Duplicator (400 of FIG. 5 and 1660 of FIG. 9) must retain state information for tracking which Children have already been duplicated, so as to prevent infinite recursive looping. Sufficient memory, for this function should be allocated to handle most recursive structures. As memory begins to become loaded, the price for duplication should be increased proportionally, so as to discourage its use as per the Resource-Model. Alternatively, an additional field can be assigned to each set in the Kernel-Image (see Appendix G) to track the duplication status. The end result should be an identical structure, complete with Cursor- Identifications (5030 of FIG. 26, 6635 of FIG. 19 and 7620 of FIG. 24) in the same positions as the source. PLUGIN-MANAGER

The Plugin-Manager (7600 of FIG. 24) allows for hardware components that are not trusted to interact with the Ill-Emulator while maintaining its integrity. This prevents the need for reviewing the security of the Ill-Emulator whenever a new Plugin architecture is installed. The Plugin

(7665a, 7665b, 7665n of FIG. 24) is unable to access Cursor-Identification (6635 of FIG. 19 and

7620 of FIG. 24) handles directly like conventional Emulator-Components (FIGs 3-8). Instead, it utilises a relative indexing mechanism that maintains a separate list of Cursor-Identifications for every Child created by the Plugin. The KI-lndex-Filter (7615a, 7615b, 7615n of FIG. 24) exposes a Pseudo-KI-lnterface (7650 of FIG. 24) to the Plugins. The Pseudo-KI-lnterface is identical to the Kl-lnterface (see Appendix G) except that:

All indexes, Cursor-Identifications (6635 of FIG. 19 and 7620 of FIG. 24), Fast-ABS primitive handles and Slow-ABS primitive handles are translated into a relative addressing system to prevent Plugins (7665a, 7665b, 7665n of FIG. 24) from accessing handles outside of its scope. Kl-Get-Govemance-Layer (see Appendix G) is not supported. KI-Get-Parent-ldentification (see Appendix G) is not supported.

Kl-Get-Powerset (see Appendix G) does not return the actual Powerset (6400 of FIG. 18) but the Plugin-Powerset (7400 of FIG. 23). The KI-lndex-Filter (7615a, 7615b, 7615n of FIG. 24) operates by managing a mapping between the actual Cursor-Identifications (6635 of FIG. 19 and 7620 of FIG. 24) and the Filtered-lndex (7630 of FIG. 24), which acts as the relative reference for the Pseudo-KI-lnterface (7650 of FIG. 24). Each time the Pseudo-KI-lnterface is used to retrieve a new reference, then a new entry is added to this mapping table. If a new Child is created it is simply assigned a new entry as well. At no point does the Pseudo-KI- Interface have a Cursor-Identification without a mapping.

Any Digital-Business (8800 of FIG. 29) can connect to any Plugin (7665a, 7665b, 7665n of FIG. 24) within the Plugin-Manager (7600 of FIG. 24) by utilising the Governance-Layer-Interface (9500a, 9500b of FIG. 31 , 9700a, 9700b of FIG. 32 and 9815 of FIG. 33) - located in the Governance-Layer-Interface-Field (9810 of FIG. 33) and set up by the Governance Layer (101bof FIG. 1 and 202b of FIG. 2). The Governance Layer itself may connect to any Plugin (7665a, 7665b, 7665n of FIG. 24) in the Plugin-Manager (7600 of FIG. 24) by utilising the ILI- Plugin (6850 of FIG. 20) of the Global-Static-Store (6440 of FlG. 18, 10025 of FIG. 34 and 6800 of FlG. 20). The Governance Layer creates a Plugin-Powerset (6858 of FIG. 20 and 7400 of FIG. 23) for the Plugin. This Child contains an ILI-Plugin-lnstance (6859 of FIG. 20 and 7410 of FIG. 23). The Governance Layer then inserts the Plugin-Powerset into the ILI-Plugin. The Plugin-Manager has a Monitor installed on the ILI-Plugin to detect incoming Children. On receiving the Plugin-Powerset, the Plugin-Manager authorises the call with the appropriate -Plugin. The Plugin is specified by the Whole of the Child of the IPI-Plugin-ID-Field (7420 of FIG.

23). The Whole of the Child for both the I Pl-User-I D-Field (7440 of FIG. 23) and the IPI-

Password-Field (7450 of FIG. 23) are used for authorisation if appropriate. The Whole of the

IPI-User-ID-Field is used to identify the calling Digital-Business (8800 of FIG. 29). The actual mechanism that the Plugin-Manager (7600 of FlG. 24) uses to communicate this authorisation process to the Plugins (7665a, 7665b, 7665n of FIG. 24) is beyond the scope of this patent, as this is an implementation issue. If authorisation is successful, then the Plugin-Manager enables the KI-lndex-Filter (7615a, 7615b, 7615n of FIG. 24) for the specified channel for that Plugin. If unsuccessful, then the Plugin-Manager inserts a Child of Type Type-Fail into the IPI-Context (7465 of FIG. 23) instead. The Child may contain any error information.

MONITORS

Monitors allow Emulator-Components or software executing as UPTs to receive events when characteristics of a set are modified during a Kl-lnterface method call or UPT that modifies a set structure. The invention utilises the Kernel-Image (see Appendix G) to create a UPT-Monitor-

Generator (see Appendix B), which is placed on the stack. The UPT-Monitor-Generator processes a captured instant in time when the characteristic was changed and triggers off every appropriate event associated with that Monitor. The UPT-Monitor-Generator triggers the UPT- Cycler (470 of FIG. 3) to either:

Execute code in triggering the event for UPT software.

Transmit a signal via the Event-Triggered-Dataflow (see FIG. 8) by using the UPT-Event- Triggered-lnterface (see FIG. 69) for Emulator-Components.

MONITOR LIFECYCLE

For a Monitor to be triggered, the following steps must occur:

Either a UPT software or an Emulator-Component requires a Monitor.

A Monitor (5200 of FIG. 14) is created.

The Monitor is attached to the Manabars-Set that is to be watched by using:

UPT-Add-Monitor (see Appendix B) for UPT software.

Kl-Add-Monitor (see Appendix G) for Emulator-Components. The Monitor is triggered by the Kernel-Image (see Appendix G), which captures the state of the

Manabars-Set at the point where the Monitor was generated and returns a UPT-Monitor generator, which is placed on the stack.

The UPT-Monitor-Generator is processed by the UPT-Cycler to trigger the. event. The Monitor may be removed by using: UPT-Remove-Monitor (see Appendix B) for UPT software. Kl-Remove-Monitor (see Appendix G) for Emulator-Components.

ASYNCHRONOUS-VIRTUAL-MACHINE-QUEUER

The Asynchronous-Virtual-Machine-Queuer (410 of FIG. 3) operates as a simple queue for executable jobs destined for the 3IP-AVM (17200 of FIG. 58) for the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6-, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57). The only requirement is that the Partner-Channel-Manager (13000 of FIG. 49) must cross- compile AVMF into the correct format of the destination Partner Node (see Partner-Channel- Manager). The 3IP-AVM makes requests to the Asynchronous-Virtual-Machine-Queuer for new executable jobs via the AVM-lnterface (see Appendix C and FIG. 72).

3I P-AVM

The 3IP-AVM (17200 of FIG. 58) provides mass computation for the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) by engaging numerous processors in the von Neumann-Processor-Farm (17205 of FIG. 58). To enable the greatest range of deployments, the full implementation of the 3IP-AVM (17200 of FIG. 58) is unspecified. By keeping part of the Ill-Emulator unspecified, it enables chip capability to be expanded without introducing incompatibilities. This enigma is possible because the Ill-Emulator provides a foundation architecture to enable cross-compilation via the Partner-Channel-Manager or PCM (13000 of FIG. 49) for new 3IP architectures. Preventing incompatibilities is essential in the deployment of a homogeneous grid platform with heterogeneous Node (200a-e of FIG. 2 and 380, 395 of FIG. 4) architectures. The 3IP-AVM manages the loading of this Emulator-Component (FIGs. 3-8) by adhering to the Resource- Model and charging accordingly.

METHODOLOGY

It is the cross-compilation aspect of the 3IP (17000 of FIG. 57) that enables the superconductive transcoding of Digital-Business (8800 of FIG. 29) across heterogeneous networks that makes a truly open grid possible. The computing model to enable cross-compilation is minimal and is orientated around the traditional von Neumann architecture primarily for reasons of efficiency, but also to leverage on the vast base of knowledge that has accumulated around this single mechanism. The 3IP-AVM (17200 of FIG. 58) as a component of the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) is actualised in hardware, so has both a logical and physical capability. The logical capability is expressed as the type of Asynchronous-Virtual-Machine-Format or AVMF (see Appendix E) managed by the 3IP and hence dictates the format required for executing code. The physical capability is the processing speed and size of memory components of the AVM-Processor (17210a, 17210b, 1721On of FIG. 58 and 17400 of FIG. 59) and the speed of the Scoped- FABS-I nterf ace (17240 of FIG. 58 and 17495 of FIG. 59). It is the physical capability of the 3IP-' AVM that is integrated into the Resource-Model (see mass computation of the Resource- Model).

3IP-AVM ARCHITECTURE

The 3IP-AVM (17200 of FIG. 58) attempts to load each AVM-Processor (17210a, 17210b, 1721On of FIG. 58 and 17400 of FIG. 59) on start up. The Job-Scheduler (17275 of FIG. 58) loads each job via the AVM-I nterf ace (17299 of FIG. 58). For each job the AVMF sequence is stored as a Fast-ABS. primitive entry on the UPT-AVM (see Appendix B) in the Leftmost Child as the AVMF-Sequence (see UPT-AVM Parameter Name of Appendix B) and is loaded via the Scoped-FABS-lnterface (17240 of FIG. 58 and 17495 of FIG. 59). The native executable code is loaded from the 3IP-AVMF-Verfier (17280 of FIG. 58) via the Verified-AVMF-lnterface (17285 of FIG. 58) where it may have been compiled into a more efficient form. For example, in a Java implementation, the AVMF may be compiled directly into a Java Class file. If the code has not been verified correctly, then the job is ignored. Otherwise, each job is forwarded to an awaiting AVM-Processor (17210a, 17210b, 1721On of FIG. 58 and 17400 of FIG. 59) by using the Execution-Interface (17490 of FIG. 59). During execution the AVM-Processors read and write Fast-ABS primitive data to the FABS-Access-Manager (17230 of FIG. 58) by using the Scoped- FABS-lnterface (17495 of FIG. 59) via a reference parameter set up by the Digital-Business (8800 of FIG. 29) software known as the FABS-Parameters (see UPT-AVM Parameter Name of Appendix B). Once the UPT-AVM (see Appendix B) has been processed, the 3IP-AVM unlocks the Digital-Business by inserting Child with its Type to Type-Unlock into the Activity-Status-Field (9440 of FIG. 31) of the Digital-Business.

ASYNCHRONOUS-VIRTUAL-MACHINE-FORMAT

The Asynchronous-Virtual-Machine-Format (AVMF) is a framework provided by the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) that provides a foundation von Neumann architecture that can be extended with new instructions. Appendix E contains a list of mandatory instructions to be included in any 3IP so as to provide a basis to ensure cross-compiler success regardless of the 3IP architecture of the target Node (200a-e of FIG. 2 and 380, 395 of FIG. 4). These base instructions can be used in clusters to emulate the behaviour of any new instruction that a Partner-Channel- Manager (13000 of FIG. 49) may need when generating the cross-compilation of an AVMF sequence that is attached to an UPT-AVM (see Appendix B).

The AVMF is constituted from a series of abstract virtual machine instructions. Each instruction performs an operation on either the AP-Stack (17470 of FIG. 59) or the Scoped-FABS-lnterface (17240 of FlG. 58 and 17495 of FIG. 59) by utilising the AP-CPU (17435 of FIG. 59).

AVM-PROCESSOR

Collectively the AVM-Processor (see FIG. 58 and FIG. 59) performs the majority of measurable work within the invention. Each AVM-Processor (17210a, 17210b, 1721On of FIG. 58 and 17400 of FIG. 59) is an idealistic abstract processor, capable of being implemented efficiently on traditional chipset architectures during the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG.

5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) simulation or harnessing a single CPU core.

The AVM-Processor (17210a, 17210b, 1721On of FIG. 58 and 17400 of FIG. 59) has 3 main components:

(A) The AP-Memory (17420 of FIG. 59). (B) The AP-CPU (17435 of FIG. 59). (C) The AP-Stack (17470 of FIG. 59).

AP-MEMORY

The AP-Memory (17420 of FIG. 59) is indexed in 64-Bit blocks and connects to the AP-CPU (17435 of FIG. 59) across a 64-Bit bus known as the Memory-CPU-Bus (17425 of FIG. 59). The AP-Stack (17470 of FIG. 59) operates across the CPU-Stack-Bus (17465 of FIG. 59) to deliver and store values as requested by the AP-CPU (17435 of FIG. 59. The AP-Memory (17420 of FIG. 59) has 2 sub-components:

The AVMF-Memory (17420 of FlG. 59) contains the AVMF code to be executed for this UPT- AVM (see Appendix B) that originated at the UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9) and was forwarded to the Asynchronous-Virtual-Machine. The Heap (17410 of FIG. 59) where there is no actual division in the 64-Bit memory array as these components are all indexed directly by the AP-CPU (17435 of FIG. 59) with an offset.

AP-CPU

The AP-CPU (17435 of FIG. 59) contains a 64-Bit Program-Counter to indicate the next instruction for the AP-CPU (17435 of FIG. 59) to execute. The AP-CPU will only execute a fixed number of instructions that is stored in the Clock-Limit (17450 of FIG. 59), that is set by the Governance Layer (101b of FIG. 1 and 202b of FIG. 2) and transmitted at the beginning of each execution as the AP-Clock-Limit-Signal (17455 of FIG. 59). The AP-CPU tracks the number of instructions executed since the start of the program in the AP-Clock (17445 of FIG. 59). The

AP-CPU processes each instruction by moving information across either the CPU-Stack-Bus

(17465 of FIG. 59), Memory-CPU-Bus (17425 of FIG. 59) or the Scoped-FABS-lnterface (17495 of FIG. 59 and 17240 of FIG. 58). Execution ends when the AVMI-Exit (see Appendix E) instruction is encountered or the AP-Clock (17445 of FIG. 59) reaches the Clock-Limit (17450 of FIG. 59).

AP-STACK

The AP-Stack (17470 of FIG. 59) performs the role of registers in the von Neumann architecture, but it is more scalable and can have a varying number of elements on the AP- Stack (17470 of FIG. 59), up to a limit of Max-Stack-Size (7267 of FIG. 22).

EXECUTION

Execution starts once the AP-Loaded-Signal (17430 of FIG. 59) and the AP-Clock-Limit-Signal (17455 of FIG. 59) have been received by the AP-CPU (17435 of FIG. 59). This is a result of the previous execution transmitting the AP-Execution-Complete-Signal (17460 of FIG. 59) that causes the AP-Logic (17480 of FIG. 59) to load the current job via the AP-Memory-Signal (17415 of FIG. 59), the AP-Clock-Limit-Signal (17455 of FIG. 59) and the AP-Stack-Signal (17475 of FIG. 59), which it transmits simultaneously.

Some implementations may be optimised in a variety of ways - for example: The Job-Scheduler (17275 of FIG. 58) may determine which AVM-Processor (17210a, 17210b, 1721On of FIG. 58 and 17400 of FIG. 59) will become available next by tracking the remainder of the Clock-Limit (17450 of FIG. 59). In this case, to load the AVMF into a standby cache on board the Job- Scheduler. Otherwise, in the standard implementation, the AP-Memory-Signal (17415 of FIG. 59) forwards the AVMF to be executed in the-AP-Memory (17420 of FIG. 59). The AP-Memory responds by loading the AVMF into the memory starting at address 0000 and setting all remaining addresses to zero.

AVMF-VERIFY-QUEUER

The AVMF-Verify-Queuer (490 of FIG. 3) operates as a queue for executable code waiting to be authorised for execution. Some implementations may assume all AVMF is valid and ignore this module and the associated 3IP-AVMF-Verifier (17280 of FIG. 58, 17025 of FIG. 59 and 23000 of FIG. 74) entirely by executing AVMF natively. A direct execution would simply exit if the AVM-Processor (17210a, 17210b, 1721On of FIG. 58 and 17400 of FIG. 59) crashed. However, it is included in the standard implementation because it may not be ideal to allow the AVM- Processor to crash. Furthermore, some Ill-Emulators (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FlG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) may require a formal step to compile the AVMF into a more optimised format. All software utilising the UPT-AVM (see Appendix B) must formally call the U PT-AVM F-Verify (see Appendix B). Even on native implementations, failure to do this results in an ignored UPT-AVM so as to preserve a homogeneous behaviour.

3IP-AVMF-VERIFIER

The 3IP-AVMF-Verifier (17025 of FIG. 59, 23000 of FIG. 74 and 17280 of FIG. 58) ensures that the proposed AVMF is correctly formed to prevent the AVM-Processor (17210a, 17210b, 1721On of FIG. 58 and 17400 of FIG. 59) from crashing. At some point after verification has occurred the 3I P-AVM (see Appendix B) is likely to attempt to execute the AVMF sequence via the Verified-AVMF-lnterface (23035 of FIG. 74 and 17285 of FIG. 58).

The 3IP-AVMF-Verifier uses the Verification-Job-Manager (23040 of FIG. 74) to co-ordinate the verification. It inserts the 64-Bit AVMF data sequence into the next available Verification- Processor (23200 of FIG. 75). The data sequence contains a series of Abstract-Virtual- Machine-Instructions or AVMI (see Appendix E) that are streamed from the Fast-ABS primitive - identified by the only parameter of the UPT-AVMF-Verify (see Appendix B) and was passed in from the AVMF-Verify-lnterface (23050 of FIG. 74) to the 3I P-AVM F-Verifier (17025 of FIG. 57 and 23000 of FIG. 74). After the verification and regardless of the outcome, the 3IP-AVMF-Verifier (17025 of FIG. 57 and 23000 of FIG. 74) deletes the UPT-AVMF-Verify (see Appendix B) from the stack and finally unlocks the Digital-Business (8800 of FIG. 29) by setting the Activity-Status-Field (9440 of FIG. 31) by inserting a Child of Type-Unlock into the Neutral position. VERIFICATION-PROCESSOR

The Verification-Processor (23200 of FIG. 75) ensures that an AVMF execution sequence is correctly formed. The AVMF-Memory (23210 of FIG. 75) accepts the next queued verification job made available from the Verification-Job-Manager (23040 of FIG. 74) by using the Verification-Interface (23270 of FIG. 76). The AVMF-Memory (23210 of FIG. 75) contains:

The Proposed-AVMF (23215 of FIG. 75), which contains the executable sequence. Boolean-Land-Array (23220 of FIG. 75) that indicates if at least one branching instruction is directed to this AVMI.

The Boolean-Jump-Array (23225 of FIG. 75) that indicates if this instruction branches to another AVMI.

The Verification-Processor (23200 of FIG. 75) performs the following steps upon receiving the AV-Engaged-Signal (23231 of FIG. 75) that is part of the Verification-Interface (23270 of FIG. 75):

INITIALISATION

Every Boolean in both the Boolean-Land-Array (23220 of FIG. 75) and the Boolean-Jump- Array (23225 of FIG. 75) is set to false. The Jump-Loader (23230 of FIG. 75) of the AVMF- Memory (23210 of FIG. 75) retrieves the Proposed-AVMF (23215 of FIG. 75) originally from the Fast-ABS primitive. Once the Boolean-Land-Array and the Boolean-Jump-Array have been cleared, the Jump-Loader configures the bits on the Boolean-Land-Array and the

Boolean-Jump-Array to create an executable signature for the AVMF so that it can be evaluated in the next stage. The Jump-Loader (23230 of FIG. 75) uses the following algorithm:

The Jump-Loader steps through each AVMI.

If the AVMI is a branching instruction, it marks the Boolean-Jump-Array (23225 of

FIG. 75) at the same index as the AVMI in the AVMF sequence for that instruction as true, otherwise it remains false.

If the instruction was branching, the Jump-Loader locates all AVMI indexes (index for the Program-Counter of 17440 of FIG. 59) where the instruction could branch to and marks those indexes in the Boolean-Land-Array (23220 of FIG. 75) as true.

Once the AVMF-Memory (23210 of FIG. 75) is configured, it transmits the AVMF-Loaded- Signal (23245 of FIG. 75) to the Integrity-Checker (23250 of FIG. 75): In some implementations the AVMF-Loaded-Signal (23245 of FIG. 75) maybe transmitted prior to the actual completion of the loading in order to accelerate processing time. The Integrity- Checker sets the Stack-Count () to zero and clears the Simulated-Stack (23260 of FIG. 75) and then begins confirming that the proposed AVMF sequence is legitimate by transferring the AVMF across the AVMF-Bus (23240 of FIG. 75).

INTEGRITY VERIFICATION

Every AVMI is transferred across the AVMF-Bus (23240 of FIG. 75), starting at the first index and ending at the last. Each time an instruction modifies the stack, the changes are reflected in the Simulated-Stack (23260 of FIG. 75) and the Stack-Count (23255 of FIG. 75). For each AVMI transferred, 2 associated bits are also transferred that indicates:

A bit from the Boolean-Land-Array (23220 of FIG. 75) indicates if a branching instruction points to the AVMI.

A bit from the Boolean-Jump-Array (23225 of FIG. 75) indicates if the execution flow branches to another AVMI.

As each AVMI is received, a number of tests are conducted in parallel.

TYPE-ERROR CHECKING

There are 4 Stack-Types for data in the Asynchronous-Virtual-Machine:

A Whole that is a 64-Bit signed whole number.

A Float that is a 64-Bit signed floating-point number. An array of Float. An array of Whole.

It is critical that the instructions operate with AP-Stack (17470 of FIG. 59) items of the correct stack type. For example, AVMI-W-Add (see Appendix E) takes Wholes from the AP-Stack and replaces them with their addition, which is also a Whole. Since the native representation of the Whole and Float are implementation specific, it is meaningless to allow them to interchange freely. To achieve a conversion between two types such as from a Float to a Whole, a cast can be performed with the AVMI-F-to-W instruction, or a Whole to a Float with the AVMI-W-to-F instruction.

The process of type error checking involves simulating a run-time AP-Stack (17470 of FIG. 59) in the Simulated-Stack (23260 of FIG. 75) during the processing of each AVMI sequence. Instead of an actual value, the simulated stack holds only the stack type information. Each time an instruction is processed, the Verification-Processor (23200.of FIG. 75) compares the type data on the Simulated-Stack (23260 of FIG. 75) to ensure that it matches the required AVMI types. In this way, the simulation can pre-emptively match the next instruction with the correct type on the AP-Stack (17470 of FIG. 59), prior to the actual execution (see Stack Type Behaviour of Appendix E).

STACK OVERFLOW AND UNDERFLOW CHECKING

Stack overflow and underflow errors are checked to ensure that regardless of the conditional logic, the AP-Stack (17470 of FIG. 59) will not continue to grow unchecked or reach a point where there are insufficient 64-bit stack blocks left to process an AVMI. Each time an AVMI is processed, the Stack-Count is adjusted to reflect the alteration to the stack (see Stack-Change of Appendix E). Checking occurs by ensuring that the Stack-Count (23255 of FIG. 75) always synchronises at zero whenever a Boolean-Jump-Array (23225 of FIG. 75) or Boolean-Land- Array (23220 of FIG. 75) bit is True.

BRANCH CODE CHECKING

Branch code checking occurs as each AVMI is processed to ensure that a branching statement moves the Program-Counter (17440 of FIG. 59) to a valid AVMI. This check is performed by simply ensuring that the AVMI points to a legitimate instruction whenever the Boolean-Land- Array (23220 of FIG. 75) bit is True. Some implementations may combine this check with Type- Checking, which also manages branching.

JOB UNLOADING

Once this checking process is complete, the Integrity-Checker (23250 of FIG. 75) transmits the Compiler-Status (23235 of FIG. 75) to the AVMF-Memory (23210 of FIG. 75) that is forwarded to the 3IP-AVMF-Verifier (23000 of FIG. 74) via the Verification-Interface (23270 of FIG. 75) that can be:

(A) Successful. (B) Compilation failed at a particular instruction.

(C) The Stack failed at a particular instruction.

(D) The UPT-AVM (see Appendix B) exceeds the maximum number of AVMIs allowed. If the Compiler-Status -(23235 of FIG. 75) is (A) successful, then the Proposed-AVMF (23215 of FIG. 75) is formally sanctioned to the Authentication-Database (23030 of FIG. 74) via the 3IP- AVMF-Verifier (23000 of FIG. 74).

GOVERNANCE LAYER

The Governance Layer (101b of FIG. 1 and 102b of FIG. 2) is the adjacent layer to the invention. The invention occupies the Interoperability Layer (101a of FIG. 1 and 102a of FIG. 2) and functionally provides the infrastructure for the Digital-Businesses (8800 of FIG. 29) that are found in the Information Layer (101c of FIG. 1 and 102c of FIG. 2). Therefore, the function of Governance Layer is beyond the scope of the Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FlG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57). However, the communication between the invention and the Governance Layer is defined.

POWERSET-BINDING

To maximise the security of the invention, the Governance-Layer (6475 of FIG. 18) should be located as the Powerset's (6400 of FIG. 18) only Child so that the Governance-Layer is bound to the Powerset and hence occupies the highest level of scope. This prevents the possibility of any unpredictable process that may be loaded within this scope, which would otherwise enable this process to access the Governance-Layer and its associated Digital-Businesses (8800 of FIG. 29).

ACCESS TO COMPUTATION

The Ill-Emulator (551 of FlG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) enables computational completeness virtually in the Kernel-Image (see Appendix G) in a context where the other Emulator-Components (FIGs 3-8) are real. The Governance Layer (101b of FIG. 1 , 202b of FIG. 2) is virtual^' software operating within this framework in an identical manner as any Digital-Business (8800 of FIG. 29) does in the Information Layer (101c of FlG. 1 and 202c of FIG. 2). For the Governance Layer to attain access to computation, it is required to represent its various functions as pseudo Digital- Businesses, so that the invention may operate on it. The Governance Layer resides in the GE- instance (9435 of FIG. 31 , 9630 of FlG. 32 and 10000a, 10000b of FIG. 34) for each Digital- Business. It is most probable that the Governance Layer will operate in a distributed fashion across multiple Nodes (200a - 20Oe of FIG. 2 and 380, 395 of FIG. 4) on a peer-to-peer network to enable an homogeneous Operating System capable of enabling global compliance of trade and communication. ACCOUNTABILITY OF GOVERNANCE LAYER SERVICES

The Governance Layer (101 b of FIG. 1 , 202b of FIG. 2) is expected to ensure that the DTE- Instance (6476 of FIG. 18, 9425 of FIG. 31 , 9620 of FIG. 32 and 9800a, 9800b of FIG. 33) and the GE-lnstance (9435 of FIG. 31 , 9630 of FIG. 32, 10000a, 10000b of FIG. 34) share an identical Manabars-Set (see Appendix G) to enable communication between the Governance

Layer and the Information Layer (101c of FIG. 1 , 202c of FIG. 2) for each Digital-Business. This shared set is inserted into the Govemance-Layer-lnterface-Field (9810 of FIG. 33) by software executing in the GE-lnstance. The Reference-Membrane (outside the scope of this patent) as invented by Dr Fielden is a mechanism to enable secure communication across this shared level of scope and prevents its exploitation by malicious software running in the DTE-I nstance.

Where in the foregoing description reference has been made to specific components or integers of the invention having known equivalents, then such equivalents are incorporated herein as if individually set forth. The invention is not limited to the specific embodiments disclosed herein and it is to be understood that many modifications or improvements may be made without departing from the scope of the invention.

APPENDIX A - EMULATOR SPECIFIC TYPES

The following is a list of Types that are used by the Ill-Emulator, however, the actual ID and names are irrelevant and can be substituted with any arbitrary equivalent.

APPENDIXA

APPENDIXA

APPENDIX A

210 Type-Error

212 Type-Monitor

213 Type-Child

214 Type-Field

- Operators

301 Type-Addition

302 Type-Subtraction

303 Type-Multiplication

304 Type-Division

305 Type-Greater-Than

306 Type-Greater-Than-Or-Equal-To

307 Type-Less-Than

308 Type-Less-Than-Or-Equal-To

309 Type-Equals

310 Type-Fixed-Operation

311 Type-Dynamic-Operation

312 Type-Remainder

Content

401 Type-Whole

402 Type-Float

403 Type-Array-Of-Whole

404 Type-Array-Of-Float

405 Type-Fast-ABS

406 Type-Slow-ABS

407 Type-Type

Object Orientation

058 Type-UPT-Method-Call-ltem

059 Type-UPT-Method

060 Type-U PT-This-Object

062 Type-U PT-Locate-Variable

501 Type-Inputs-Field

502 Type-Locals-Field

503 Type-Outputs-Field

504 Type-Global-Field APPENDIXA

TYPES FOR PARTNER-CHANNEL-MANAGER

TYPES FOR HUMAN-COMMUNICATION-MANAGER

Sensory-Perception-Type

40001 Type-Vocal-Perceptioπ

40002 Type-Move-Perception

40003 Type-Point-Perception

40004 Type-Action-Perception

40005 Type-Anger-Perception

40006 Type-Focus-Perception

Sensory-Experience-Type

40100 Type-Visual-Experience

40101 Type-Sound-Experience

40102 Type-Smell-Experience

Primitive-Type

40200 Type-Primitive-Strip

40201 Type-Primitive-Fan

40202 Type-Primitive-Hexatone

40203 Type-Primitive-Polygon

40204 Type-Primitive-Lathe APPENDIX A

Texture-Type

40301 Type-Image-Texture

40302 Type-Video-Texture

Texture-Mode-Type

40400 Type-Object-Texture-Mode

40410 Type-Eye-Texture-Mode

40420 Type-Sphere-Texture-Mode

40430 Type-Normal-Texture-Mode

40440 Type-Reflection-Texture-Mode

Lights-Type

40500 Type-Ambient-Light

40510 Type-Point-Light

40520 Type-Spot-Light

40530 Type-Directional-Light

APPENDIX B - UNIVERSAL PROCESS TYPES

Field: A Child in a UPT.

Value: The Child located by the Cursor within a Field. All Fields ending in -Field actually include an additional Child known as a Value. This extra Child is not represented on the tables.

Number-Resolution: A Field requiring a number. The Value may contain none, one or two values. If no numbers are attached to the Value, then the number is zero. If there is only a Float or Whole, then that number is used. If there is both a Whole and Float, then the highest resolution in the number system is achieved by overlaying their symmetric spectrums.

Action-Polarity-Resolution: A Field that requires an Action-Polarity. If there is no Value in the Field or the Value that is present is not of Type Type-Left or Type-Right then the Action-Polarity is Left. Otherwise the Action-Polarity is specified by the Value where Type-Left is Left and Type-Right is Right.

Action-Trilarity-Resolution: A Field that requires Action-Trilarity. If there is no Value in the Field or the Value that is present is not of Type Type-Left, Type-Right or Type- Neutral then the Action-Trilarity is Neutral. Otherwise the Type is specified by the Value where Type-Left is Left, Type-Right is Right and Type-Neutral is Neutral.

Lock-Mode-Resolution: A Field that requires Lock-Mode. If there is no Value or the Value that is present is not of Type Type-Lock or Type-Unlock then the Lock-Mode is locked. Otherwise the Type is specified by the Value where Type-Lock is locked and Type-Unlock is unlocked.

Boolean-Resolution: A Child within a Value that is expected to be a Boolean value. If the Value is not of Type Type-True or Type-False then the Boolean value is True. Otherwise the Type is specified by the Type of the Value where Type-True is true and Type-False is false.

Type-Resolution: A Field that requires a Type. If there is no Value in the Field or the Value does not contain a Whole, then the Type is zero; otherwise the Type is specified by the Whole of the Child currently selected.

Primitives: Data that is attached to a Manabars-Set and includes a Whole, Float, Fast- ABS, Slow-ABS and Type.

Logic List: A series of Boolean Primitives that are evaluated by logic operators such as UPT-And.

Spawn: A process where a new Cursor is created for a Manabars-Set with the Kl- Insert-And-Spawn Kl-lnterface method call. See Appendix G. The new Cursor will access the same Children as the original Cursor but is free to move independently of it.

Method-Frame-Indexing: An implementation specific mechanism for encoding variables that can be accessed with an index but is contained within a single Manabars- APPENDIX B

Set. Method-Frame-Indexing is used heavily during Object Orientated support to enable independent method-frames to access their own variables.

Digital-Business Locking/Unlocking: UPTs that take more than one Digital-Business cycle to process the UPT are responsible for locking the Digital-Business by setting the Value of the Activity-Status-Field (9440 of FIG. 31) to Type-Lock to lock it and Type- Unlock to unlock it.

APPENDIX B

UPT-ABS-Bus

APPENDIX B UPT-Add-Monitor

UPT-And M

APPENDIX B

UPT- Assignment

co

UPT- AVM

APPENDIX B

UPT- AVMF-Verϊfy

UPT- Break

APPENDIX B the start of the loop has been located. Both the located UPT-Sequence and the UPT-Sequence that holds the UPT- Break are deleted from the stack. The final step of the UPT-Break is to shift the Cursor of the UPT-Sequence that restarts the loop to the Right.

UPT-Cast

OI

APPENDIX B

If the Type of the Target-Field is of Type-Whole then the Whole value of the Target is set to the retrieved value.

If the Type of the Target-Field is of Type-Float then the Float value of the Target is set to the retrieved value.

If the Type of the Target-Field is of Type-Type then the Type of the Target is set to the retrieved value.

If the Type of the Target-Field is Type-String then a Manabars-Set is created in the Target for each Character in the

String. The Whole of the newly created Manabars-Set is set to the Unicode value of the Character.

Once the retrieved value has been successfully converted the Target is inserted into the Target-Field before the UPT-Cast is deleted from the Stack.

(J)

UPT-Comparison

l¥Pe_ 001

Description The UPT-Comparison-Float is a branching structure that compares two float numbers (Left-Value-Field & the Right- Value-Field using Number-Precedence) against the Operator (<, <=, >, >=, =).

Behaviour This UPT retrieves the Left and Right numbers from the Left-Value-Field and the Right-Value-Field. If either of these numbers are Whole numbers then they are cast to a Float number. These numbers are then compared using the Operator, located in the Operator-Field as a basis for the Comparison. If the result is True then a new Child is created with a Type of Type-True, otherwise the new Child has a Type of Type-False. This new Child is then inserted into the Leftmost position of the list held inside the Logic-List-Field.

APPENDIX B

UPT- Continue

APPENDIX B

UPT-Copy-AII-Children

OO

APPENDIX B

UPT-Copy-Child

CO

UPT-Create-ABS

lYJPe. 037

Description The UPT-Create-ABS transfers data as Float or Whole directly into either Fast-ABS or Slow-ABS.

Behaviour The UPT-Create-ABS creates a new Asynchronous-Bit-Sequence (ABS) in either the Fast-ABS or the Slow-ABS, depending on the Type of the ABS-Type-Field Value. The UPT-Create-ABS then systematically steps through the list of Children in the Source-Field Value retrieving the Type and relative number primitive from each Child. If the Type is of Type-Whole or Type-Float then the number is converted to a 64-Bit block and added to the newly created Asynchronous-Bit-Sequence. If the Type of the Child is of Type-Fast-ABS or Type-Slow-ABS, the value is already an Asynchronous-Bit-Sequence primitive; it is concatenated to the newly created Asynchronous-Bit-Sequence. The newly created Asynchronous-Bit-Sequence primitive is then assigned to the Parent contained in the Target-Field Value. If the Type of the Child is neither Type-Whole, Type-Float, Type-Fast-ABS or Type-Slow-ABS then the UPT is ignored.

APPENDIX B

UPT-Create-Manabars-Set )

Behaviour This UPT-Create-Manabars-Set inserts a new Child in the Neutral position of the Target-Field.

UPT-Debug-Output

APPENDIX B

UPT-Delete-AH-Children

M

UPT-Delete-Child

APPENDIX B

UPT-Denatured-Recursive-Copy

APPENDIX B

UPT-Entangle

w

CO

APPENDIX B

UPT-Entangled-Denatured-Recursive-Copy

APPENDIX B

UPT-Entangled-Recursive-Copy

N3 Oi

APPENDIX B

UPT- Evaluate

CO

APPENDIX B

UPT-Fixed-Operation

K)

UPT-Get-Boundary-Cursor-Identification

APPENDIX B

UPT-Get-Child

oo

UPT-Get-DTE-lnstance

APPENDIX B

N3 CD

UPT-Get-Fast-ABS-Hashkey

APPENDIX B

UPT-Get-Float-Hashkey

O

UPT-Get-GE-Instance

APPENDIX B

UPT-Get-lndex

OJ

APPENDIX B

UPT-Get-Number-Children

UPT-Get-Number-Cursors

APPENDIX B

UPT-Get-Number-Shared-Cursor-ldentifications

OJ

UPT-Get-Slow-ABS-Hashkey

APPENDIX B

UPT-Get-Whole-Hashkey

UPT-If

APPENDIX B

UPT-lnsert-And-Spawn

UPT-Insert-Child

APPENDIX B

UPT-Locate-Variable

CO

APPENDIX B

UPT-Map

CO

APPENDIX B

UPT-Method

OO

APPENDIX B

UPT-Method-Call-ltem

CO CD

APPENDIX B matching Method-Signature-Item is found then the processing UPT-Method-Call-ltem must wait until the conflicting UPT-Method-Call-ltem is complete.

Certain implementations may choose to process the conflicting UPT-Method-Call-ltem to speed up the process and not waste the Digital-Business-Cycle. Once all Method-Signature-Items have been checked then the Spawned- Parallel-Exclusion-List is deleted from the Current-Parallel-Exclusion-List-Spawn-Cursor-Field and the Spawned- Current-Method-Call-List is shifted to the Right. Once the Spawned-Current-Method-Call-List has checked each UPT-Method-Call-ltem then a UPT-Method is created by:

Creating a new Pseudo-Stack and inserting the UPTs in the Utilised-Method-Stack-Drop-UPT-Field (11337 of FIG. 41) and the Method-Startup-UPT-Field onto the Pseudo-Stack in the Leftmost position. Creating a new Method-Values-Field with new Index-Start-Points for the Input-Field, Local-Field and Output- Field.

Inserting the Object of the UPT-Method-Call-ltem into the Object-Field.

Insert the processing UPT-Method-Call-ltem into the Current-Method-Call-List using the Spawned-Current- Method-Call-List. The Spawned-Current-Method-Call-List is then inserted into the Spawned-Current-Method- Call-List-Field of the UPT-Method and the currently processing stack is inserted into the Stack-Field of the processing UPT-Method-Call-ltem. O

Inserting the Post-Method-Drop-UPT found in the Post-Method-Drop-Field of the UPT-Method-Call-ltem into the Post-Method-Drop-Field of the UPT-Method. Finally the UPT-Method is inserted onto the Leftmost position of the stack and the UPT-Method-Call-ltem is deleted from the stack.

APPENDIX B

UPT-Monitor-Generator

APPENDIX B triggered. For each MG-Capture-lnstance one of six possible Monitor-Events is searched:

Monitors triggered through changes made to the Parent-Identification of the Cursor-Identification passed through to the Kl-lnterface are found in the Pi-Monitor-Event in the Parent-Monitor-Field. These Monitors include all Monitors with a Type of Pi-Monitor.

Monitors triggered through changes made to the Child-Identification passed through to the Kl-lnterface that the Cursor-Identification was pointing to before the changes were made are found in the CHI-Monitor-Event in the Current-Child-Monitor-Field. These Monitors include:

CHI-Monitor-Child-Delete

CHI-Monitor-Cursor-ldentification-Shifted-Off-Child CHI-Monitor-No-Cursor-Identification CHI-Monitor-Number-Sharing-Cursor-ldentifications-Queried.

4^

Monitors triggered through changes made to the Child-Identification to the Left of the Child-Identification that the M Cursor-Identification that was passed through to the Kl-lnterface was pointing to before the changes were made, are found in the CHI-Monitor-Event in the Left-Child-Monitor-Field. These Monitors include:

CHI-Monitor-Child-Terminate-Right CHI-Monitor-Child-Links-Right CHI-Monitor-Child-lnserts-Right CHI-Monitor-Child-Deletes-Right.

Monitors triggered through changes made to the Child-Identification to the Right of the Child-Identification that the Cursor-Identification was pointing to before the changes were made, are found in the CHI-Monitor-Event in the Right-Child-Monitor-Field. These Monitors include:

CHI-Monitor-Child-Terminate-Left CHI-Monitor-Child-Links-Left CHI-Monitor-Child-Inserts-Left CHI-Monitor-Child-Deletes-Left.

APPENDIX B

Monitors triggered through the Cursor-Identification that was passed through to the Kl-lnterface shifting to a new Child, are found in the CHI-Monitor-Event in the New-Child-Monitor-Field. These Monitors all have a Type of CHI- Monitor-Cursor-ldentification-Shifted-Onto-Child.

Monitors triggered through changes made to the Cursor-Identification that was passed through to the Kl-lnterface are found in the CUI-Monitor-Event in the Cursor-Monitor-Field. These Monitors include:

CUI-Monitor-Cursor-At-Boundary

CUI-Monitor-Cursor-At-Leftmost

CUI-Monitor-Cursor-At-Rightmost

CUI-Monitor-Cursor-Retrieved

CUI-Monitor-lndex-Queried.

If the relevant Monitor-Event-Field is empty or there is no matching Monitor inside the Monitor-Event, then the MG- Capture-lnstance is ignored and the next MG-Capture-lnstance is retrieved. Once a Monitor has been located it is triggered as outlined below and the UPT-Monitor-Generator will then continue searching the Monitor-Event until all matching Monitors have been located.

How a Monitor is triggered depends on whether the Monitor was constructed by an Emulator-Component or a Digital-Business. This is ascertained in the following manner: co

If the Type of the ET-lnstance, located inside the Event-Target of the Monitor, is of Type-Emulator-Component then the Monitor was created by an Emulator-Component. The Float value of the ET-lnstance is used to determine the source Emulator-Component that is waiting on this event and 64-Bit Whole, attached to the ET-lnstance, and the MG-Capture-lnstance are transmitted to the Emulator-Component via the Kl-Broadcast method call (see Appendix G). The following values are mapped directly to Emulator-Components:

Asynchronous-Duplicator Kernel-Image Environment-Manager UPT-Cycler

Partner-Channel-Manager Plugin-Manager ABS-Bus Slow-ABS Fast-ABS Asynchronous-Virtual-Machine

APPENDIX B

AVM-Compiler Human-Communication-Manager.

A Monitor created by a Digital-Business contains a Thread-Instance as the ET-lnstance inside the Event-Target. Located in the DB-Event of the Monitor are the DE-Realtime-Event-Field, DE-Prepaid-Event-Field, DE-Standby- Event-Field, DE-ldle-Event-Field and the DE-Background-Event-Field. Each of these Event-Fields holds a UPT that is to be inserted onto the corresponding Stack inside the Thread-Instance. These UPTs must be able to access the Event-Parameters. Since the Monitor may be processed in parallel, a UPT-Monitor-Sequence is constructed for each UPT when the Monitor is triggered and inserted onto the appropriate stack. The UPT is inserted onto the Pseudo-Stack of the UPT-Monitor-Sequence and the matching MG-Capture-lnstance is inserted into the Event- Parameters-List of the Monitor, in the Rightmost position using the KI-lnsert-And-Spawn method call. The resulting spawned Event-Parameters-List is inserted into the Event-Parameters-Field of the UPT-Monitor-Sequence. The UPT-Monitor-Sequence is finally inserted onto the corresponding stack in the Thread-Instance, in the Leftmost or Rightmost position as identified via the Type of the Polarity-Field Value in the Monitor. See UPT-Monitor-Sequence for how this UPT-Monitor-Sequence is subsequently processed.

UPT-Monitor-Sequence

APPENDIX B

which UPT-

UPT-New-Child

APPENDIX B

UPT-Not

UPT-Or CD

APPENDIX B

UPT-Rθcursϊve-Copy

UPT-Recursive-Delete

APPENDIX B

UPT-Reference-Comparison

Tγpe_ 006

Description The UPT-Reference-Comparison compares a Logic-List of Children to verify if they are the same set by reference.

Behaviour The UPT-Reference-Comparison retrieves the Leftmost Child of the Comparison-List, which is contained in the Comparison-List-Field by shifting the Cursor to the Leftmost position. The UPT-Reference-Comparison then iteratively shifts the Cursor of the Comparison-List to the Right, retrieves the next Child and compares it to the first Child. If the two Children are the same then the process will carry on, otherwise a new Child with its Type set to Type-False is inserted into the Leftmost position of the Logic-List contained in the Logic-List-Field and the process is halted. The UPT may take multiple Digital-Business-Cycie attempts to complete the UPT. If all of the Children in the Comparison-List are indeed the same Child, then a new Child with its Type set to Type-True is inserted into the Leftmost position of the Logic-List. The Children are compared using the Parent-Identification of the Manabars-Set as the Children may be referenced using a spawned Cursor. If the two Children have the same Parent-Identification then they are the same Manabars-Set.

OD

UPT-Remove-Monitor

APPENDIX B

UPT-Sequence

UPT-Shift-Cursor CD

APPENDIX B

UPT-Shift-Cursor-To-Boundary

UPT-Start

O

APPENDIX B

UPT-Stop

Ol

UPT-Spawn-Cursor-Identification

APPENDIX B

UPT-Super-Sequence

UPT-This-Object

then be used to locate global information related to the UPT-Method that called the UPT-This-Object.

APPENDIX B

Behaviour The UPT-This-Object is only able to operate if it resides in the Pseudo-Stack (11352 of FIG. 42) of a UPT-Method. The UPT-This-Object shifts the Cursor of the UPT-Method to the Object-Field and retrieves the Object-Field Value. The retrieved Object is inserted into the Target-Field in the Neutral position. If there is no Object contained in the Object-Field then the Target-Field of this UPT-This-Object will remain empty.

UPT-This-Stack

en ω

UPT-This-Thread

APPENDIX B

UPT-Try-Sequence

Oi

APPENDIX B

UPT-Unentangle

Type 031

Description The UPT-Unentangle is used to remove an entangled reference to a particular Cursor-Identification.

Behaviour The Asynchronous-Duplicator maintains a hashtable that keeps references of all entangled Cursor-Identifications associated with certain hashtable keys. This UPT-Unentangle retrieves the hashtable that matches the key in the Key-Field. The UPT-Unentangle locates the Cursor-Identification that is entangled with the Parent-Identification of the source contained in the Source-Field. The UPT-Unentangle then removes the entry whose hashtable key matches the Parent-Identification of the aource, and the entry whose hashtable key matches the Parent- Identification of the retrieved Cursor-Identification from the retrieved hashtable.

en

UPT-Unmap

APPENDIX B

UPT-Xor

Ol

APPENDIX C - INTERFACE-DEFINITIONS

Interface-Definitions define the communication between two components. The Interface- Definition is asymmetric as the behaviour is different for both components. For example, the telephone answering protocol requires that the person who dialled the number waits for the receiver to say 'hello' first before the conversation can begin. Only one party dials while the other says 'hello'.

All Interface-Definitions are drawn diagrammatically as a single line that connects two components. The asymmetry of the protocol is indicated by assigning a (+) and a (-) to identify the polarity of the protocol. When the Interface-Definition is defined, only the (+) need be articulated, as the (-) can be deduced. In the telephone example, the caller could be assigned the (+) polar definition and the receiver the (-) polar definition. In documenting the (+) Interface- Definition, the caller would:

Dial the number. Await call to be answered. Await 'hello'. Begin conversation

The deduced (-) Interface-Definition that does not require documenting involves the following implied steps:

Answer the phone.

Say 'hello'.

Await start of the conversation.

APPENDIX D - OBJECT ORIENTATION

The Ill-Emulator (551 of FIG. 3, 751 αf FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 1551 of FIG. 10 and 17001 of FIG. 57) provides support for Object Orientation with a number of UPTs. Set Theory specifically prevents access of information out of scope, so certain functions that rely on shared code would otherwise be impossible to perform without this specialised support.

UPT-METHOD-CALL-ITEM

The UPT-Method-Call-ltem (11326 of FIG. 41) is used by an Object Orientated compiler to call a new method. The UPT-Method-Call-ltem is a record of the method before its birth to after its termination. The UPT-Method-Call-ltem is stored inside the Object (11800 of FIG. 43) as a record of every method call (11830 of FIG. 43) as well as for all current method calls (11845 of FIG. 43). The UPT-Method-Call-ltem doubles as an active UPT that is recognised directly by the UPT-Cycler hardware to maintain the Data Segment (DS) and Code Segment (CS) separation. Some compilers may not utilise the Historic-Method-Call-List (11825 of FIG. 43) during release builds in order to aid memory management to allow the garbage collector to remove these completed method frames. However, this stack trace is invaluable during debugging.

When the UPT-Cycler encounters a UPT-Method-Call-ltem on either the stack or the Pseudo- Stack of a UPT-Method, it attempts to create a new method frame through the establishment of a new UPT-Method. However, before the UPT-Method can be created, the UPT-Cycler first checks if the new method may execute in parallel with the other methods already executing. Methods can be tagged to prevent them from executing in parallel with other methods that have specific signatures. This enables software to control access to data fields inside a class and prevents data corruption through parallel access. The process of checking the execution status may take several Digital-Business-Cycles. At each point, if execution cannot take place, then the UPT-Cycler may execute another method that is allowed to run.

LAUNCH CHECKING

In order to check that the method can execute, the UPT-Cycler retrieves the Object (11800 of FIG. 43) from the Object-Field of the UPT-Method-Call-ltem (see Appendix B and 11341 of FIG. 41). Once the Object is located, the Cursor of the Current-Method-Calls-List (11840 of FIG. 43) of the Current-Method-Calls-List-Field (11835 of FIG. 43) is spawned. By producing a new spawned Cursor-Identification for this transaction, it prevents data corruption across APPENDIX D independent method frames. The UPT-Method-Call-ltem may span multiple Digital-Business- Cycles so a unique Cursor prevents competing UPT-Method-Call-ltems corrupting the current location. This spawned Cursor is inserted into the Current-Method-Call-List-Spawn-Cursor- Field (11359 of FIG. 42) of the UPT-Method (11350 of FIG. 42). The Cursor is shifted to the Leftmost position, prior to the searching of conflicting method frames.

Once the spawned Cursor is in the Leftmost position, the UPT-Cycler can begin checking each UPT-Method-Call-ltem in the Child of the Current-Method-Call-List-Spawn-Cursor-Field. For each Method-Call-Item encountered, the UPT-Cycler scans the Method-Signature-Item-Field to^J retrieve the Method-Signature-Item, Which contains the Parallel-Exclusion-List-Field. The Parallel-Exclusion-List contains a series of Method-Signature-Items that each represent an illegal parallel exclusion indicating that a method may not execute until various blocking methods have been completed. The UPT-Cycler checks each of these Method-Signature-Items against the single Method-Signature-Item of the current UPT-Method-Call-ltem awaiting execution. This comparison is done by reference only and the actual Method-Signature-Items are not scanned to ensure isomorphism. Providing no Method-Signature-Item is matched, then the method may be launched. If the UPT-Cycler encounters an excessive number of currently executing methods, then it shifts the Cursor Rightwards for each check until it no longer has any remaining time within the current Digital-Business-Cycle. The next time the UPT-Method-Call- ltem is encountered, the UPT-Cycler resumes the launch check from the UPT-Method-Call-ltem identified by the spawned Cursor. If the UPT-Cycler encounters blocked method execution, then it may choose to execute the currently executing UPT method so as not to waste the current Digital-Business-Cycle.

METHOD LAUNCHING

The method is launched once the UPT-Cycler has determined that there are no conflicting methods that are currently executing. The UPT-Cycler creates a UPT-Method (11350 of FIG. 42) and inserts this into the Leftmost position of the stack, regardless of whether the UPT- Method-Call-ltem was on the stack or pseudo stack of another executing UPT-Method. The. UPT-Cycler then deletes the original UPT-Method-Call-ltem.

UPT-METHOD

The UPT-Method superstructure (11350 of FIG. 42) is constructed by the UPT-Cycler. The Pseudo-Stack (11352 of FIG. 42) is created with the Utilised-Method-Stack-Drop-UPT and the Startup-UPT (11336 of FIG. 41) inserted in the Leftmost positions (in that order). These UPTs are found in the UPT-Method-Call-ltem that is responsible for generating this UPT-Method. The APPENDIX D

Method-Values (11354 of FIG. 42 and 11200 of FlG. 40) are all newly created with the exception of the Index-Start-Point for the Output-Field, which is retrieved from the UPT-Method- Call-ltem. The Object that is hosting the UPT-Method-Call-ltem is inserted into the Object-Field (11356 of FIG. 42). This is obtained from the Object-Field (11341 of FIG. 41) of the UPT- Method-Call-ltem. The Index-Start-Point of the Static-Variable-List-Field (11357 of FIG. 42) is retrieved from the Static-Variable-List-Field (11339 of FIG. 41) of the UPT-Method-Call-ltem and the Current-Method-Call-List is retrieved from the Current-Method-Call-List-Spawn-Cursor-Field (11343 of FlG. 41) of the UPT-Method-Call-ltem and is inserted into the Spawned-Current- Method-Call-List-Field (11359 of FIG. 42).

The UPT-Method effectively replaces the UPT-Method-Call-ltem on the stack.

METHOD-FRAME-INDEXING

Each method frame shares the same code as every other method frame. The program counter is represented by a spawned Cursor available for each method frame to identify its currently executing instruction. However, the parameters, local variables and return values (Data Segment) require hardware support to reference the actual values, as they cannot be stored in the method code (Code Segment). This separation of the Data Segment and Code Segment is performed by four Types that are assigned to the Value of a Field of any UPT executing inside the Pseudo-Stack (11352 of FIG. 42):

Type-lnputs-Field for reading parameters for a method. Type-Locals-Field for reading and writing local variables. Type-Outputs-Field for returning values from a method. Type-Global-Field for enabling global variable access.

Method-Frame-Indexes are therefore used in situ within the UPT on an executing stack, enabling the UPT to locate the actual value from the correct method frame. The UPT-Cycler locates the correct Manabars-Set by using the index established as a Whole on the Value. The actual Manabars-Set is found in the Method-Values of the UPT-Method.

When the Type-lnputs-Field, Type-Locals-Field, Type-Outputs-Field or Type-Global-Field are encountered directly on the stack outside of an embedded pseudo stack, then the entire UPT that holds these Method-Frame-Indexes is ignored. APPENDIX D

Method-Frame-Indexes enable method code to execute in parallel without data corruption occurring across UPT Fields that may be used simultaneously by multiple method frames or by UPTs that are dependent on output from other UPTs in a previous execution.

APPENDIX E - AVMF MANDATORY INSTRUCTIONS

Contains a Whole to represent the index.

APPENDIX E

APPENDIX E

APPENDIX E

Whole Float

Location²

Trilarity Polarity / Boolean³

² A Whole that represents an AVMF index to move the Program-Counter to (310 of FIG. 2).

³ Left is equivalent to True

⁴ The index into the AVMF-Variable to store the value.

⁵ Same as AVMI-W-Store

⁶ The index into the AVMF-Variable to locate the value.

⁷ Same as AVMI-W-Store

APPENDIX E

⁸ The item to be shifted

⁹ The number of bits that the item is to be shifted

APPENDIX E

10 The size of the array.

11 The value to be assigned

12 The index of the array

13

The reference that holds the array object

¹⁴ The index of the array

¹⁵ The reference that holds the array object

16 The value that is returned to the top of the Operand-Stack

APPENDIX E

17 The current location

18 The target AVMI index ¹⁹ The location to return to.

APPENDIX E

All Fast-ABS sequences are indexed by the 1^st stack item - a Whole that points to the index of the FABS-Parameters (see UPT-AVM of Appendix B) Value, where 1 is the Leftmost Child and 2 is the Child to the Right of the Leftmost Child. At any stage, if the Fast-ABS is indexed with a value for which there is no Child, then the Fast-ABS sequence is considered to be null.

APPENDIX F

HCM Implementation Scenario

The following is an example of a Mesh-Blueprint and HCM implementation. The actual specification should change as more sensory equipment is invented. Each alteration should only increase the sensory resolution, but leave the format unchanged - enabling backwards and forwards compatibility.

SENSORY-EXPERIENCE

The Sensory-Experience (24470 of FIG. 81) contains the actual data to describe all objects as being perceived through human senses.

SENSORY-PERCEPTION

The Sensory Perception (23870 of FIG. 78) contains data generated from the user that has the ability to alter the Sensory-Experience (24470 of FIG. 81). These Sensory-Perceptions can include an anger perception to detect shouting or swearing, an action perception to detect a mouse click or touching of the screen. The types of Sensory-Perceptions are unlimited and only restricted by the ability of the hardware installed.

MESH-BLUEPRINT

The Mesh-Blueprint (24200 and 24345 of FIG. 80 and 23850 of FIG. 78) contains all data required to deliver a Sensory-Experience (24470 of FIG. 81) and capture the Sensory- Perception (23870 of FIG. 78).

CHANNEL

A Channel (24060a - 2406On of FIG. 79) is an output device that is connected to the invention within the HCM implementation and may include such items as monitors, speakers, overhead projectors or touch screens. Any output device can be invented and attached. The ILI- Phenotype (6860 of FIG. 35) of the Global-Static-Store (6440 of FIG. 33 and 6800 of FIG. 20) contains an ILI-Phenotype-Data-List (23810 of FIG. 78), which is a list of Channels (23855 of FIG. 78) that are connected to the invention. The Portal inserts the Mesh-Blueprint (23850 of FIG. 78 and 24200 of FIG. 80) into the Render-Field (23830 of FIG. 78) of the Channel. This Mesh-Blueprint (in this example implementation) contains the User-Position-lnformation (24240 of FIG. 80) that the Human-Communication-Manager (24000 of FIG. 79) utilises when APPENDIX F projecting the Sensory-Experience. The Mesh-Blueprint also contains embedded Mesh- Blueprints (24320 of FIG. 80) that the Human-Communication-Manager scans to render all necessary Sensory-Experiences (24470 of FIG. 81). The Mesh-Blueprint (24200 and 24345 of FIG. 80) also contains an Entity-List (24250 of FIG. 80) that contains every Entity (24400 and 24490 of FIG. 81 and 24310 of FIG. 80) that is to be rendered.

ENTITY

An Entity (24400 and 24490 of FIG. 81 and 24310 of FIG. 80) is one particular Object to be rendered in any Channel (24060a - 2406On of FIG. 79). An example of an Entity may be a car on a racetrack. The Entity consists of three Fields explained below:

The Sensory-Experience-Field (24410 of FIG. 81) contains a list of Sensory-Experiences (24470 of FIG. 81), which holds the Render-Information (24505 of FIG. 81) and the Composite- Data (24515 of FIG. 81). The Composite-Data contains information stored in Fast-ABS (850 of FIG. 5) that specifies what the Sensory-Experience (24470 of FIG. 81) is. In the car example above, the Composite-Data for the Entity would contain information about what the car looks like, smells like or sounds like. The Render-Information (24505 of FIG. 81) gives the Human- Communication-Manager (24000 of FIG. 79) extra data such as the location, size and volume. This data is dependant on the Type of the Sensory-Experience (24470 of FIG. 81) and how it is defined. In the example of the car Entity, two cars may be created with the same Composite- Data (24515 of FIG. 81) but with different Render-Information (24505 of FIG. 81), which makes the car look the same, but placed on the racetrack in different positions. This Render- Information (24505 of FIG. 81) is combined with the User-Position-Information (24240 of FIG. 80) to remap the projection to a global location in the virtual universe. Each Channel (24060a - 2406On of FIG. 79) may scan through the Sensory-Experience-List (24440 of FIG. 81) and only utilise the information relevant to the specific Channel. For example headphones would only use the Sensory-Experience (24470 of FIG. 81) with a Type of Type-Sound-Experience and ignore all Sensory-Experiences with a Type of Type-Visual-Experience, whereas a computer monitor or printer may utilise the information stored in the Sensory-Experiences with a Type of Type-Visual-Experience and Type-Sound-Experience. There are no limitations to the amount of Sensory-Experiences that the Channel (24060a - 2406On of FIG. 79) may use.

The Sensory-Perception-Listener-Field (24420 of FIG. 81) consists of a List of Sensory- Perception-Listeners (24480 of FIG. 81) that contain information about what occurs when the user affects the Entity (24400 of FlG. 81). In the car example, a user may open the door of the car, thereby causing the Render-Information (24505 of FIG. 81) of the door Entity to be altered. APPENDIX F

These Perception-Listeners are activated through the use of Monitors when the relative Entity (24400 and 24490^'of FIG. 81 and 23885 of FIG. 78) is inserted into the SP-Entity-Field (23880 of FIG. 78) of the Sensory-Perception (23870 of FIG. 78) in the Sensory-Perception-List (23860 of FIG. 78).

The Embedded-Entity-Field (24430 of FIG. 81) contains a List of Entities (24490 of FIG. 81) that is affected by the outermost Entity (24400 of FIG. 81). In the car example, an embedded Entity may be the door of the car. The door is attached to the car and moves with the car when the car moves. However, the door also has its own Sensory-Experiences (24470 of FIG. 81) that are separate from the overall car. These Sensory-Experiences allow the door to be opened and closed and may include the sound of the door opening and the smell of the rich leather seats inside.

RENDER-INFORMATION

The Render-Information (24505 of FIG. 81 and 24650a - 2465On of FIG. 82 and 24800 of FIG. 120 and 25000 of FIG. 121) is used inside the Sensory-Experience (24470 of FIG. 81) of the Entity (24400 of FIG. 81) and inside the MB-Render-lnformation (24335 of FIG. 81 and 24600 of FIG. 82) of Embedded-Mesh-Blueprints (24320 of FIG. 80). It contains all data used to render the Mesh-Blueprint (24345 of FIG. 80) contained in the Mesh-Blueprint-Field (24340 of FlG. 80).

The MB-Render-lnformation (24335 of FIG. 81 and 24600 of FIG. 82) holds all other Render- Information that is dependent on the type of the Sensory-Experience (24470 of FIG. 81). For example, a Sensory-Experience with the Type of Type-Sound-Experience determines the volume by the Volume-Field (24810 of FIG. 120) and the playback speed by the Speed-Field (24820 of FIG. 120).

Alternatively, a Sensory-Experience with a Type of Type-Visual-Experience holds the Scale (25015 of FIG. 121), Location via the Location-Field (25020 of FIG. 121), Rotation via the Rotation-Field (25030 of FIG. 121) and overall Appearance (25045 of FIG. 121 and 25200 of FIG. 122) for the rendered object. Furthermore, the Appearance include the Texture (25215 of FIG. 122 and 25400), Colour via the Colour-Field (25240 of FIG. 122), Material (25225 of FIG. 122), Lights (25320 of FIG. 122) via the Lights-List (25235 of FIG. 122) and Transparency (25255 of FIG. 122) of the rendered object.

The Render-Information of the Entity (24400 of FIG. 81) may be reused for all embedded Entities contained in the Embedded-Entity-List (24460 of FIG. 81), unless the embedded Entity APPENDIX F contains its own Render-Information. In the given example of the car Entity, the car may have the colour Blue specified in the Render-Information. The door may default to the same colour blue, which means that the Render-Information does not have to be repeated again, or the door Entity may contain data in its own Render-Information that specifies that the door is red - to override the default colour of blue.

APPENDIX F

RGB-Set

Description Specifies the level of Red, Green and Blue.

HCM SUPERSTRUCTURE DEFINITIONS

XYZ-Set

Description Contains X, Y and Z co-ordinates.

APPENDIX F

ATTENUATION-SET

Description Specifies the intensity of light decreases with distance

C

AMBIENT-LIGHT

The following lights are inserted into the Lights-List (25235 of FIQ. 85).

Type 40500

Description Defines an Ambient-Light that provides background lighting with no particular direction.

Child Location Parameter Name Description

1 Colour This Value is an RGB-Set that holds information about the colour of the Light.

APPENDIX F

DIRECTIONAL-LIGHT

Type 40530

Description A Light, such as a torch, shining in a specific direction.

POINT-LIGHT C

Type 40510

Description Light eminating from a single point

APPENDIX F

SPOT-LIGHT

APPENDIX G

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. APPENDIX G

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 APPENDIX G 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

FlG. 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 APPENDIX G 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-Haπdle, 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. APPENDIX G FIG. 7

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

FIG. 8

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

FIG. 9

FIG. 9 shows the Parent-ldentification-Coπtent (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. APPENDIX G

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

EXPANSION

APPENDIX G

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

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. APPENDIX G

FIELDS AND VALUES

Governance-Layer-lπterface

12345 GLI-lnstance 333a

ORDERING

Parent 1 Parent 2 Child # 1 (202) ] 5810 5820

[child # 1 (202) j [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.

APPENDIX G

MASKED DETAIL

Kernel-Image

321

REPEATED SCOPE

ExecufJbn-Jns.tance 4300a ,'^' _Thread_Group-

Execution-Instance 4440 4300b

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. APPENDIX G

PLURALITY

Node 5880 Partner-Instance 333b 333n 333a

NAMING

Goverπance-Layer-lπterface

4320 .

; 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. APPENDIX G

TYPE IDENTIFICATION

AVMI-VF-State 6270

Tvoe = True

INTERFACE CONNECTIVITY

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. APPENDIX G

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 APPENDIX G

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 Emuiator-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. APPENDIX G PARENT-HANDLE-PORT

The Pareπt-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 FIG. 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 FIG. 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- APPENDIX G

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:

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

LEFTMOST-CHILD-HANDLE AND RIGHTMOST-CHILD-HANDLE

The Leftmost-Child-Handle (3230 of FIG. 3) and Rightmost-Child-Handle (3240 of FIG. 3) contains the Leftmost-Child-ldentification (4810 of FIG. 10) and Rightmost-Child-Identification (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:

NUMBER-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). APPENDIX G 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 FIG. 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 FIG. 11) provides a handle to a Monitor-Event (5100 of FIG. 11) that contains Monitors (51 10a - 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. APPENDIX G

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 FlG. 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 ail the Children of the Manabars-Set (3000 of FIG. 2). Any one of many algorithms may be used for determining the Float-Hashkey. APPENDIX G 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-Identification (4830 of FIG. 10) and Right-Child-Identification (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. APPENDIX G 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-ldentification-Content (3445 of FIG. 4 and 4200 of FIG. 8) contains 2 fields listed below:

CHI-MONITOR-EVENT

The CHI-Monitor-Eveπt (4210 of FIG. 8 and 5025 of FIG. 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 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 FIG. 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 APPENDIX G

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 Subievel-Proxy-ldentifications on a regular basis.

PROXY-CHILD-HANDLE

The Proxy-Child-Handle (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 FlG. 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-LEFTWIOST-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. APPENDIX G 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 Kl-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 FIG. 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 Kl-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 Kl-Memory is the primary memory system in the Emulator. APPENDIX G

KI-INTERFACE

The Kl-lnterface (2810 of FIG. 1) is the only conduit through which Emulator-Components can access the Kl-Memory (2610 of FIG. 14). The Kl-lπterface 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 FlG. 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 Kl-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 Kl-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 APPENDIX G 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-interface (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 FIG. 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 FIG. 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. APPENDIX G

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 FlG. 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-ldeπtification-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 FIG. 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-Identification-Content (3445 of FIG. 4 and 4200 of FIG. 8). APPENDIX G

For a full list of Monitors, their Types and their Parameters see Appendix B. Monitors (5110a - 511On of FIG. 11 and FlG. 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. 11), 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 - 511On 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. δ) 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). APPENDIX G

The CHI-Monitor-Event (4210 of FlG. 8 and 5485 of FIG. 12) of the Child to the Right 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 Right-Child-Monitor-Field (5480 of FIG. 12). The CHI-Monitor-Event (4210 of FlG. 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-Field (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-Moπitor-Geπerator 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 G

APPENDIX A

Kl-lnterface Methods

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

APPENDIX G

KI-Add-Monitor

APPENDIX G

Kl-Broadcast

APPENDIX G

Kl-Create-Manabars-Set

APPENDIXG

Kl-Delete-Child

APPENDIX G

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

Next-Child: (Able to be No-Child) The Child to which all Cursors currently referenping the Child to be deleted will now be referencing. Found through the Left-Child-Handle (3410 of FIG. 4) or the Right-Child-Handle (3420 of FIG. 4) of the Current-Child based on the Action-Polarity (input 2).

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-Deletes-Right for the Left-Child.

Step 2: Update the Proxy-Handle (3620 of FIG. 5) of the Next-Proxy to reference the Current-Proxy. Depending on the Action-Polarity (input (2)) update the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) or the Proxy-

APPENDIX G

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 FlG. 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 ofFIG. 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 Asynchronous-Garbage-Collector (2630 of FIG. 13) is informed of the released Child-Identification (3020 of FIG. 2 and 3400 of FlG. 4) and the Number-Of-Children (4410 of FIG. 9) found in the Parent-ldeπtification- Conteπt (3225 of FlG. 3 and 4400 of FIG. 9) of the Parent-Identification is decreased. Check for PI-Monitor- Deletes-Child for the Parent-Identification and CHI-Monitor-No-Cursor-Identification and CHI-Monitor Child Delete for the Child to be deleted.

Fields Altered Left-Child-Handle (of the Right-Child), Right-Child-Handle (of the Left-Child), Proxy-Handle (of the Next-Proxy), Proxy-Leftmost-Cursor-Handle or the Proxy-Rightmost-Cursor-Handle (of the Current Proxy depending on Action- Polarity (input (2)), Proxy-Size (of the Next-Proxy), Proxy-Child-Handle (of the Next-Proxy), Proxy-Child-Handle (of the Current-Proxy), Child-Proxy-Handle (of the Next-Child), Child-Proxy-Handle (of the Current-CNId), Number-Of- Children (of the Parent-Identification), Index-Integrity (of the Parent-Identification)

APPENDIX G

Monitors CHI-Monitor-Child-Deletes-Left (for the Right-Child), CHI-Moπitor-Child-Deletes-Right (for the Left-Child), Pl- Monitor-Bad-lndex (for the Parent-Identification), Pl-Monitor-Deletes-Child (for the Parent-Identification), CHI- Monitor-Child-Delete (for the Current-Child), CHI-Monitor-No-Cursor-Identification (for the Current-Child)

APPENDIX G

APPENDIX G

APPENDIX G

KI-Get-Adjacent-Cursor-ldentification

APPENDIX G

Kl-Get-Boundary-Cursor-ldentification

APPENDIX G

Kl-Get-Chiki

APPENDIX G

Monitors CUI-Moπitor-Cursor-Retrϊeved (for the retrieved Cursor)

KI-Get-Fast-ABS-Handle

APPENDIX G

KI-Get-Fast-ABS-Hashkey

Kl-Get-Float

APPENDIX G

APPENDIX G

Kl-Get-Float-Hashkey

Kl-Get-Governance-Layer

APPENDIX G

KI-Get-lndex

APPENDIX G

APPENDIX G

KI-Get-Number-Children

Kl-Get-N umber-Cursors

In puts (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.

APPENDIX G

KI-Get-Number-Sharing-Cursor-ldentifications

APPENDIX G

KI-Get-Parent-ldentification

APPENDIX G

Kl-Get-Powerset

KI-Get-Slow-ABS-Handle

APPENDIX G

(3225 of FIG. 3 and 4400 of FIG. 9) of the Parent-Identification.

Fields Altered None

Monitors None -

Kl-Get-SIow-ABS-Hashkey

Kl-Get-Type

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), which locates the Type (4480 of FIG. 9) to be retrieved.

APPENDIX G

Kl-Get-Whole

APPENDIX G

Kl-Get-Whole-Hashkey

APPENDIX G

KI-lnsert-And-Spawn

Kl-lnsert-Child

Inputs (1) The Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) that identifies the destination location where the new Manabars-Set reference is to be inserted, (2) the Cursor-Identification identifies the source Child to be inserted

APPENDIX G into the 1 parameter, (3) Action-Trilarity (4) Lock-Mode

Outputs None

References set up at Current-Proxy: The main Proxy-Identification (3010 of FIG. 2 and 3870 of FIG. 6) found through the Cursor-Proxy- the start 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 FIG. 5) of the¹ Current-Proxy.

New-Child: The new Child-Identification (3020 of FIG. 2 and 3400 of FIG. 4) that is created in Step 1.

Left-Child: (Able to be No-Child) The Child that will be to the Left of the Child to be inserted (New-Child) if the 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)).

APPENDIX G

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.

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 FIG. 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 FIG. 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-lndex 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_r0f- 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-Moπitor-Child-lnserts- Right forthe Left-Child, and Pi-Monitor-Inserts-Child for the Parent-Identification.

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.

APPENDIX G

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

APPENDIX G

APPENDIX G

APPENDIX G

Monitors Pi-Monitor-Bad-Index (for the Parent-Identification), CHI-Monitor-Child-Inserts-Left (for the Right-Child), CHI- Monitor-Child-Inserts-Right (for the Left-Chiid), Pl-Monitor-lnserts-Child (for the Parent-Identification)

APPENDIX G

New-Child), [Proxy-Child-Handle (of the new Proxy-Identification), Proxy-Handle (of the new Proxy-Identification), Proxy-Leftmost-Cursor-Handle and the Proxy-Rightmost-Cursor-Handle (of the new Proxy-Identification), Proxy- Size (of the new Proxy-Identification)] or [Child-Proxy-Handle (of the Current-Child), Proxy-Child-Handle (of the Current-Proxy)].

Monitors Pl-Monitor-Bad-lndex (for the Parent-Identification), CHI-Monitor-Child-lnserts-Left (for the Right-Child), CHI- Monitor-Child-Inserts-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 Pl-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- 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-

APPENDIX G

APPENDIXG

APPENDIX G

APPENDIX G

APPENDIX G

Shifted-Onto-Child (for the Next-Child), CHI-Monitor-No-Cursor-Identification (for the Current-Child), CUI-Monitor- Cursor-At-Boundary (for input (1)), CUI-Monitor-Cursor-At-Leftmost or CUI-Monitor-Cursor-At-Rightmost (for input (1))-

APPENDIX G

APPENDIX G

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

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

Current-Proxy: The main Proxy-Identification (3010 of FIG. 2 and 3870 of FIG. 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 FIG. 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 FIG. 3) or the Rightmost-Child-Handle (3240 of FIG. 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.

APPENDIX G

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

Rightmost-Child: Found through the Rightmost-Child-Handle (3240 of FIG. 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-Handle (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 FlG. 7), found in the Proxy-Identification-Content (3615 of FIG. 5 and 4020 of FIG. 7) of the New-Proxy, to equal 0. If the Action-Polarity

APPENDIX G

(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 Current-Proxy is the same as the Cursor-Identification (input (1)) then update the Proxy-Rightmost-Cursor-Handle to reference the Old-Left-Cursor. Otherwise if the Proxy-Leftmost-Cursor-Handle (3630 of FIG. 5) of the Current- Proxy is the same as the Cursor-Identification (input (1)) then update the Proxy-Leftmost-Cursor-Handle to reference the Old-Right-Cursor.

Step 4: Check for the CHI-Monitor-Cursor-Identification-Shifted-Off-Child for the Current-Child, CHI-Monitor- Cursor-ldentification-Shifted-Onto-Child for the New-Child. Lastly check for the CUI-Monitor-Cursor-At-Boundary and the CUI-Monitor-Cursor-At-Leftmost or CUI-Monitor-Cursor-At-Rightmost for input (1).

Fields Altered Left-Cursor-Handle (of the Old-Right-Cursor), Right-Cursor-Handle (of the Old-Left-Cursor), [Left-Cursor-Handle (of the Leftmost-Cursor-Identification of the Parent-Identification), Leftmost-Cursor-Handle (of the Parent- Identification)] or [Right-Cursor-Handle (of the Rightmost-Cursor-Identification of the Parent-Identification), Rightmost-Cursor-Handle (of the Parent-Identification)], Left-Cursor-Handle and Right-Cursor-Handle (of the Cursor-Identification (input (1))), Proxy-Child-Handle (of the New-Proxy), Child-Proxy-Handle (of the Leftmost-Child

APPENDIX G or the Rightmost-Proxy - 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 Pi-Monitor-Cursor-Leftmost or Pi-Monitor-Cursor-Rightmost (for the Parent-Identification), CHI-Monitor-Cursor- Identification-Shifted-Off-Child for the Current-Child, CHI-Monitor-Cursor-ldentification-Shifted-Onto-Child for the New-Child, CUI-Monitor-Cursor-At-Boundary, CUl-Monitor-Cursor-At-Leftmost or CUI-Monitor-Cursor-At-Rightmost for input (1).

APPENDIX G

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 CUI-Monitor- Cursor-At-Rightmost for input (1).

Case 3

Occurrence There is only one Cursor in the Current-Proxy

Deviated Behaviour Steps 1 + 2: Are the same as in Generic Behaviour.

Step 3a: If there is no New-Proxy update the Child-Proxy-Handle (3430 of FIG. 4) of the New-Child to reference the Current-Proxy, update the Proxy-Child-Handle (3610 of FIG. 5) of the Current-Proxy- to reference the New- Child. Update the Child-Proxy-Handle (3430 of FIG. 4) of the Current-Child to reference No-Proxy.

Step 3b: 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. 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)). Update the Proxy-Leftmost- Cursor-Handle (3630 of FIG. 5) and the Proxy-Rightmost-Cursor (3640 of FIG. 5) to reference Cursor-Terminator and decrease the Proxy-Size (4030 of FIG. 7) of the Current-Proxy by 1.

Step 4: Check for the CHI-Monitor-No-Cursor-Identification for the Current-Child, CHI-Monitor-Cursor- Identification-Shifted-Off-Child for the Current-Child, and CHI-Monitor-Cursor-ldentification-Shifted-Onto-Child for the New-Child. Lastly check for the CUI-Monitor-Cursor-At-Boundary and the CUI-Monitor-Cursor-At-Leftmost or CUI-Monitor-Cursor-At-Rightmost for input (1).

APPENDIX G

Fields Altered Left-Cursor-Handle (of the Old-Right-Cursor), Right-Cursor-Handle (of the Old-Left-Cursor), [Left-Cursor-Handle (of the Leftmost-Cursor-Identification of the Parent-Identification), Leftmost-Cursor-Handle (of the Parent- Identification)] or [Right-Cursor-Handle (of the Rightmost-Cursor-Identification of the Parent-Identification), Rightmost-Cursor-Handle (of the Parent-identification)], Left-Cursor-Handle and Right-Cursor-Handle (of the Cursor-Identification (input (1))),

[Child-Proxy-Handle (f the New-Child), Proxy-Child-Handle (of the Current-Proxy)] or [Proxy-Size (of the New- Proxy), Cursor-Proxy-Handle (of the Cursor-Identification (input (1))), Proxy-Leftmost-Cursor-Handle or Proxy- Rightmost-Cursor-Handle (of the New-Proxy)], Child-Proxy-Handle of the Current-Child.

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

APPENDIX G

New-Cursor: Will be set in Step 1.

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 creates a new Cursor based on the Cursor-Identification of input (1) and places it to the right of input (1).

Step 1 : Create a new Cursor-Identification (3030 of FIG. 2 and 3800 of FIG. 6) for the New-Cursor and copy the Cursor-Proxy-Handle (3810 of FIG. 6) and Parent-Handle-Port (3820 of FIG. 6), references of the Cursor- Identification (input (1)). Increase the Number-Of-Cursors (4420 of FIG. 9), found through the Parent-Identification- Content (3225 of FIG. 3 and 4400 of FIG. 9) of the Parent-Identification, by 1. Update the CUI-Monitor-Event (4010 of FIG. 7), found through the Cursor-Identification-Content (3890 of FIG. 6 and 4000 of FIG. 7) of the New-Cursor to reference No-Monitor-Event. Update the Right-Cursor-Handle (3840 of FIG. 6) of the Cursor-Identification (input (1)) and the Left-Cursor-Handle (3830 of FIG. 6) of the New-Cursor to reference each other.

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

Step 3: 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 Current-Proxy, by 1. If the Cursor-Identification (input (1)) is the same as the Proxy- Rightmost-Cursor-Handle (3640 of FIG. 5) of the Current-Proxy then update the Proxy-Rightmost-Cursor-Handle to reference the New-Cursor.

Step 4: Check for the following monitors: CHI-Monitor-Cursor-ldentification-Shifted-Onto-Child for the Current- Child, Pl-Cursor-ldentification-lnserted-lnto-Parent for the Parent-Identification.

APPENDIX G

Fields Altered Cursor-Proxy-Handle, Parent-Handle-Port, CUI-Monitor-Event, Right-Cursor-Handle and Left-Cursor-Handle (of the New-Cursor), Number-Of-Cursors (of the Parent-Identification), Right-Cursor-Handle (of the Cursor-Identification (input (1))), Left-Cursor-Handle (of the Right-Cursor), Proxy-Size (of the Current-Proxy) and possibly Proxy- Rightmost-Cursor-Handle (of the Current-Proxy).

Monitors CHI-Monitor-Cursor-ldentification-Shifted-Onto-Child (for the Current-Child), Pl-Cursor-ldentification-lnserted-lnto- Parent (for the Parent-Identification).

APPENDIX G

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 G Child-ldentification-Monitors

APPENDIX G

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

²¹ Same as above.

²² Same as above

23

Same as above

APPENDIXG

APPENDIX G Parent-Identification-Monitors

APPENDIX G

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

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

APPENDIX G

APPENDIX G Cursor-Identification-Monitors

APPENDIX G

Appendix C

APPENDIXG

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.

1 1. 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. APPENDIX G

APPENDIX G

FIG. 2

APPENDIX G

FIG. 3

Parent-Identification (3200) Cursor-Identification

3260

Parent-Identification- ' Leftmost-Cursor-Handle

Content 3210

3225

I Rightmost-Cursor-Handle I 3220

Parent-Handle-Port 3270

Leftmost-Child-Handle Rightmost-Child-Handle

3230 3240

Child-Identification 3250

APPENDIX G

FIG. 4

Parent-Identification (3450) Proxy-Identification (3480) Cursor-Identification (3490)

Leftmost-Child-Handle Proxy-Child-Handle 3460 3500

Rightmost-Child-Handle 3470

Child-Identification (3400)

Left-Child-Handle Right-Child-Handle Proxy-Handle Parent-Handle- I Child-ldentification- 3410 3420 3430 Starboard (3440) • Content (3445)

U

APPENDIX G

FtG. 5

APPENDIX G

FIG. 6

Cursor-Identification (3800)

Proxy-Identification

3870 Cursor-Proxy-Handle

3810

Cursor-ldentification- I . Content (3890) I

Parent-Identification Parent-Handle-Port I

3860 3820 I

L _ _ I

Left-Cursor-Handle Right-Cursor-Handle 3830 3840

Child-Identification

3880 Parent-Handle-Starboard 3850

-

APPENDIX G

RG. 7

Cursor-Identification-Content 4000

CUI-Monitor-Eveπt 4010

Proxy-Identification-Content 4020

Proxy-Size 4030

APPENDIX G

FIG. 8

Child-ldentification-Content 4200

CHI-Monitor-Event 4210

Left-Index 4220

APPENDIX G

FIG. 9

Parent-Identification-Content 4400

Number-of-Children Fast-ABS-Handle Number-Of-lnserts 4410 4460 4510

Number-of-Cursors Slow-ABS-Handle Whole-Hashkey 4420 4470 4520

Index-Integrity Type FIoat-Hashkey 4430 4480 4530

Whole Pi-Monitor-Event Fast-ABS-Hashkey 4440 4490 4540

¹

Float Reset-Index Slow-ABS-Hashkey 4450 4500 4550

-

APPENDIX G

FIG. 10

Arbitrary Manabars-Set that is empty 4920 No-Child 4930

Cursor-Handle is r-Terminator

Leftmost-Cursor-Handle points . Rightmost-Cursor-Handle points to Cursor-Identification (4940)

to Cursor-Identification (4980)

APPENDIX G

FIG. 11

APPENDIX G

FIG. 12

UPT-Monitor-Generator (5400)

MG-Capture-Field (5420)

MG-Capture-List . (5440)

MG-Capture- lnstance (5445)

Type = [Type- Monitor-Identifier]

Type = Type-ϋPT-Monitor-Generator

APPENDIX G

FIG. 13

MG-Capture-lnstance 5600

Parameter2-Field 5640

Parameter 5645

APPENDIX G

2680

Key It 2685 Kl-lnterface Implementation-Level-Access

APPENDIX G

FIG. 15

Claims

292CLAIMS

1. A Universal Virtual Computer (LJVC) having means to produce a homogeneous grid environment from a set of heterogeneous hosts by enabling computational completeness via a common execution format.

2. A UVC as claimed in claim 1 wherein the common execution format can be simulated on any machine in the grid environment through cross-compilation.

3. A UVC as claimed in claim 1 or claim 2 having means to support an Operating System that serves mobile agents that are able to transcode from hosts on a peer-to- peer network.

4. A Universal Virtual Computer comprising a memory store of Sets, a central processor that enables computational completeness and means to transmit instructions to a multitude of components to be completed asynchronously.

5. A UVC in a grid network including means to prevent undesirable hosts from joining the grid network, as directed by the Operating System.

6. A UVC as claimed in claim 2 capable of computational completeness and fully operational without extension.

7. A UVC as claimed in claim 6 extended such that some components allow for the compilation and execution of binaries designed for von Neumann processors.

8. A UVC as claimed in claim 7 wherein the compilation and execution of binaries is derived from an abstract set of machine instructions that can be reproduced on various von Neumann processors.

9. A UVC where a first component processes instructions either synchronously or asynchronously so that synchronous instructions are completed immediately and asynchronous instructions are forwarded to one or more additional components to be completed in parallel while the first component completes further instructions.

10. A UVC that supports a plurality of mobile agents and assigns an account to each mobile agent, and means to add and/or deduct resources to or from the account upon purchase of resources.

11. A UVC as claimed in claim 10 wherein the mobile agent is destroyed when the account has a null balance.

12. A UVC as claimed in claim 1 including multiple components that each provide a resource made available via a market orientated mechanism including but not limited to bandwidth, computation and memory.

13. A UVC as claimed in claim 12 including a Realtime-Marketplace that allows mobile agents to purchase the resource for a specific time period and up to a limited level 293 that is negotiated by the mobile agent prior to resource usage enabling the resource to be drawn on demand.

14. A UVC as claimed in claim 12 including a Prepaid-Marketplace that allows mobile agents to reserve the resource at a required level for a specific time period, for which a price is determined prior to purchasing the resource.

15. A UVC as claimed in claim 12 wherein the purchase can be represented by the Universal Virtual Computer as an identifier to be sold in an open digital marketplace, later to be reclaimed by any mobile agent that presents the same identifier.

16. A UVC as claimed in claim 13 wherein the purchase can be represented by the Universal Virtual Computer as an identifier to be sold in an open digital marketplace, later to be reclaimed by any mobile agent that presents the same identifier.

17. A UVC as claimed in claim 14 wherein the purchase can be represented by the Universal Virtual Computer as an identifier to be sold in an open digital marketplace, later to be reclaimed by any mobile agent that presents the same identifier.

18. A UVC as claimed in claim 12 wherein the capacity of the resource can be recharged at the discretion of the host environment.

19. A UVC as claimed in claim 13 wherein the resource can be made available at a cost effective rate using a standby model where resource availability is erratic and distributed as the remainder after the Realtime-Marketplace has been satisfied.

20. A UVC as claimed in claim 14 wherein the resource can be made available at a cost effective rate using a standby model where resource availability is erratic and distributed as the remainder after the Prepaid-Marketplace has been satisfied.

21. A UVC as claimed in claim 19 wherein resource can be made available at a more cost effective rate using an idle model where resource availability is not only erratic but can experience major lulls and distributed as the remainder after the Realtime- Marketplace has been satisfied.

22. A UVC as claimed in claim 20 wherein resource can be made available at a more cost effective rate using an idle model where resource availability is not only erratic but can experience major lulls and distributed as the remainder after the Prepaid- Marketplace has been satisfied.

23. A UVC as claimed in claim 12 wherein the resource can be made available at the most cost effective rate for one or more marketplaces for the resource using a background model where resource availability is totally unreliable and is distributed as a remainder after all other marketplaces have been satisfied.

24. A UVC as claimed in claim 12 wherein the purchase transaction includes a reimbursement price for which the mobile agent is willing to accept in exchange for the unexpected cancellation of either the purchase transaction as a realtime contract or as a prepaid contract. 294

25. A UVC substantially as herein described with reference to any embodiment.

26. A UVC substantially as herein described with reference to any embodiment illustrated in the drawings.