[go: up one dir, main page]

WO2007037709A1 - Plate-forme d'abreges permettant de faciliter l'interoperabilite d'informations - Google Patents

Plate-forme d'abreges permettant de faciliter l'interoperabilite d'informations Download PDF

Info

Publication number
WO2007037709A1
WO2007037709A1 PCT/NZ2006/000254 NZ2006000254W WO2007037709A1 WO 2007037709 A1 WO2007037709 A1 WO 2007037709A1 NZ 2006000254 W NZ2006000254 W NZ 2006000254W WO 2007037709 A1 WO2007037709 A1 WO 2007037709A1
Authority
WO
WIPO (PCT)
Prior art keywords
digital
upt
business
resource
uvc
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/NZ2006/000254
Other languages
English (en)
Inventor
Suzanne Joy Sullivan
David Gray HUGHES
Adrian Laurence MEEKINGS
Michael James BLYTH
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
MANABARS IP Ltd
Original Assignee
MANABARS IP Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by MANABARS IP Ltd filed Critical MANABARS IP Ltd
Publication of WO2007037709A1 publication Critical patent/WO2007037709A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation

Definitions

  • This invention relates to grid computing and 1 information technology.
  • the invention has particular relevance to homogeneous environments for mobile agents that can lead to a distributed Operating System.
  • UVC Universal Virtual Computer
  • Adobe AcrobatTM 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.
  • 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.
  • 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.
  • UVC Universal Virtual Computer
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • UVC Universal Virtual Computer
  • 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.
  • 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.
  • GIS Global Information Infrastructure
  • 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).
  • 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).
  • Dr Fielden 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.
  • UVC Universal Virtual Computer
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the platform 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).
  • Nodes 380, 395 of FIG. 4 and 200a - 20Oe of
  • 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
  • the Governance Layer is the
  • 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.
  • 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 35 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.
  • 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.
  • 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:-
  • 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.
  • UVC Universal Virtual Computer
  • 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.
  • 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 located at the Information Layer 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.
  • 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.
  • 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.
  • 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.
  • Mass storage such as a hard disk
  • Fast storage such as memory
  • Bandwidth connectivity with adjacent Nodes (200a-200e of FIG. 2, 380, 395 of FIG. 4). Electrical power trading with adjacent Nodes.
  • 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.
  • 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.
  • the architecture is optimised for a hardware implementation where processes can execute in parallel on multiple components in the Ill-Emulator.
  • 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.
  • 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.
  • 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.
  • Emulator-Components The components and data flows are shown in further detail in Figures 3-8.
  • 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.
  • 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.
  • DBC Digital-Business-Cycle
  • 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).
  • 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 allows binary data to the transferred between the Slow-ABS and the Fast-ABS.
  • 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.
  • 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.
  • 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 may be maintained.
  • 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).
  • 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).
  • 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).
  • 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.
  • 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).
  • FIG. 1 A first figure.
  • 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).
  • 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 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).
  • 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
  • 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).
  • 202z Host Platform Layer
  • 202b Governance Layer
  • 202c Information Layer
  • 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 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 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 shows the Primary-Dataflow of the invention as the UPT-Cy
  • 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.
  • 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 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 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.
  • 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 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 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).
  • Asynchronous-Virtual-Machine-Queuer (1410
  • Partner-Channel-Manager (1430
  • Asynchronous-Duplicator (1440
  • ABS-Bus (1420
  • AVMF- Verify-Queuer 1490
  • Human-Communication-Manager (1500
  • 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.
  • 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).
  • 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 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 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 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 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 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 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 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 shows the Governance-Boot-Instance (6600a) that is the first executable
  • 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 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 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 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).
  • 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 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).
  • 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 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 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 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.
  • 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 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 shows the DB-Execution (9400) that forms part of the Digital-Business (8800 of FIG.
  • 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 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 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 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.
  • 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 The Every-Digital-Business-Spawned-Field
  • 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 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 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.
  • 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.
  • 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 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 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 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 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 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 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 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 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 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 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 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.
  • 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 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 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 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 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 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 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 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 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 shows the 3IP-lnterface Dataflow as data moves between the Ill-Common-Context (17035) and the 3IP-lnterface (17000).
  • 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).
  • 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 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 shows the Resource-Pricing (19000) that contains pricing information for each resource available on the invention.
  • 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.
  • 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).
  • 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 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).
  • a reference to the propagation can be structured as a PCM-Mapped-Set which is mapped using the UPT-Map (see Appendix B).
  • 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.
  • 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 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 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).
  • 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 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 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 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 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 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 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).
  • 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 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).
  • 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 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 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 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 (232
  • 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 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 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 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 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 shows the Entity (24400) that delivers a Sensory-Experience and captures a Sensory- Perception for a single entity in the virtual universe.
  • FIG. 82 shows the MB-Render-lnformation (24600) that allows multiple sensory data components to be overlayed in a single Sensory-Experience.
  • FIG. 83 shows the MB-Render-lnformation (24600) that allows multiple sensory data components to be overlayed in a single Sensory-Experience.
  • FIG. 83 shows the Render-Information (24800) for the sound experience.
  • FIG. 84 shows the Render-Information (25000) for the visual experience.
  • 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 shows a Texture (25400) that is used to provide texture data for the Texture-Field (25210 of FIG. 85).
  • 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.
  • 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.
  • a single Cursor-Identification reference can be represented with an arrow that identifies the Child to which the Cursor points.
  • 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.
  • 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.
  • Child # 1 (202) Child # 2 (203) Child # 2 (202)
  • 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.
  • 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.
  • 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
  • the Type information is highlighted at the bottom right of the Manabars-Set.
  • 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.
  • 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.
  • 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.
  • AVMI Abstract Virtual Machine Instructions
  • AVMF Asynchronous-Virtual-Machine-Format
  • 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.
  • Manabars-Sets 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
  • Emulator-Components (470 of FIG. 3) that includes activity generated by other Emulator-Components (FIGs 3-8).
  • 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).
  • 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.
  • FPGA Field Programmable Gate Arrays
  • Ill-Emulators for alternative software environments will operate perfectly, albeit slower.
  • 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.
  • the Kernel-Image 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • AVMF Asynchronous- Virtual-Machine-Format
  • AVMIs Virtual-Machine-lnstructions
  • ABS and to manipulate information within the 3IP-AVM through the utilisation of a stack and 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 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).
  • 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).
  • the AVMF-Verifier 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.
  • 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 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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).
  • 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).
  • Emulator-Components 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).
  • the Kl-Dataflow involves every Emulator-Component and allows each to access the Kernel-Image (680 of FIG. 6 and Appendix G) via the Kl-lnterface.
  • 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.
  • the Asynchronous-Bit-Streamer (ABS) dataflow or ABS-Dataflow 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.
  • 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).
  • the lO-Dataflow 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.
  • 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.
  • the start-up sequence occurs in 4 stages: -
  • 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).
  • the Reset Kl-lnterface method 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.
  • 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.
  • 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.
  • 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.
  • Emulator-Components 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
  • 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,
  • 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
  • Thread-Instance 10600 of FlG. 37 and 10485a - 10485n of FlG. 36
  • Thread-Group (6650 of FIG. 19, 9835 of FIG. 33, 10400 of FIG. 36 and 10055 of FIG. 34)
  • 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.
  • FIG. 35 into the Background-Stack (10470 of FIG. 36 and 10650 of FIG. 37).
  • 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).
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • FIG. 18, 9425 of FIG. 31 , 9620 of FIG. 32 and 9800a and 9800b of FIG. 33 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 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 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 Ill-Emulator (551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG. 6, 1351 of FIG. 7, 15
  • the Manabars-Set is a mechanism to represent Set Theory for a computational environment and is described in Appendix G as an additional patent.
  • 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.
  • the UPT-Cycler enables computational completeness by processing Universal-Process-Types or UPTs (see Appendix B) as instructions.
  • 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.
  • 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.
  • 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
  • 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.
  • 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).
  • 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)
  • 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
  • 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.
  • 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
  • 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).
  • the Governance-Layer 6475 of FIG. 18
  • 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 UPT-Cycler 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).
  • 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.
  • 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).
  • the UPT-Cycler (1470 of FIG. 10 and 1600 of FIG. 9) begins saving the Governance Layer. It does this in the following way.
  • 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 honor 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.
  • 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).
  • 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).
  • each Emulator-Component 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).
  • FPGA Field Programmable Gate Array
  • each Emulator- Component can expand its capacity as demand for the resource changes (see Resource-Model further below).
  • 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: -
  • 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.
  • the Idle- Computation-Schedule 8050 of FIG. 25 and 9260 of FIG. 30
  • 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).
  • 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:
  • Thread-Instance 10485a, 10485b, 10485n of FIG. 36 and 10600 of FIG. 37.
  • 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).
  • 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.
  • Type (see Appendix G again), which gives it context amongst the multitude of other possible Manabars-Set structures.
  • 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.
  • Emulator-Components 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.
  • 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.
  • 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).
  • the marketplaces are dynamic so that the pricing for each resource and for each priority changes over time as determined by supply and demand.
  • 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.
  • 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.
  • 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.
  • the Gover ⁇ a ⁇ ce Layer 101b of FIG. 1 and 202b of FIG.
  • 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.
  • 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).
  • 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.
  • the Governance Layer may cancel the contract and pay the cancel price in order to generate additional resource in order to satisfy realtime contracts.
  • the Digital-Business may have its contract revoked at any point and be paid the reimbursement price that it originally set.
  • the prepaid contract can be sold in a digital marketplace with an ID and password like the realtime contract.
  • 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 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.
  • 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.
  • 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:
  • 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. ⁇
  • 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-
  • Emulator-Component either reimburses the Digital-Business (8800 of FIG.
  • Emulator-Component (FIGs. 3-8) will provide it after realtime and prepaid demand has been satisfied.
  • Emulator-Component (FIGs. 3-8) will provide it after realtime, prepaid and standby demand has been satisfied.
  • Emulator-Component (FIGs. 3-8) will provide it after realtime, prepaid, standby and idle demand has been satisfied.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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).
  • 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).
  • Every-Digital-Business (6450 of FIG. 18)
  • 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.
  • the Digital-Business (8800 of FIG. 29) to be selected is identified through either:
  • 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.
  • 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.
  • 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.
  • 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 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).
  • DRC Digital-Business- Cycles
  • 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.
  • 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).
  • 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 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).
  • 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.
  • 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.
  • 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.
  • 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).
  • 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 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-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.
  • 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).
  • Item-Processors 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.
  • the Ill-Emulator 551 of FIG. 3, 751 of FIG. 4, 951 of FIG. 5, 1151 of FIG
  • 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 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 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 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-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.
  • 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 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).
  • 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.
  • 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.
  • 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:
  • 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.
  • 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
  • An Asynchronous-Bit-Sequence 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:
  • 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.
  • 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.
  • 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.
  • 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).
  • 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).
  • 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).
  • UVC Universal Virtual Computer
  • Ill-Emulators 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.
  • 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:
  • the Partner-Channel-Manager or PCM (430 of FIG. 3, 630 of FIG. 4, 830 of FIG. 5, 1030 of
  • 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):-
  • 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
  • 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).
  • 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.
  • Node partners (12010a - 1201On of FIG. 44 and 12210a, 12210b, 1221On of FIG. 45) is an implementation specific function.
  • 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:
  • 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:
  • the Governance Layer 101b of FIG. 1 and 202b of FlG.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • the Partner-Channel-Manager 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).
  • PCM-Connection-Request-lmage 21000 of FIG. 62
  • PCM-Connection-Request-Object-Orientation 21200 of FIG. 64.
  • 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).
  • 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
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Node-Transfers-Field (12430 of FIG. 46).
  • 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).
  • 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.
  • 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).
  • FIG. 56 of the Frozen-Resource-Release-Field (14580 of FIG. 56).
  • 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.
  • the Scheduler 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.
  • 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.
  • 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.
  • the Prepaid-Contract-lnstance is inserted into the APS-List (14045 of FIG.
  • 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.
  • 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.
  • 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.
  • 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-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 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:
  • 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.
  • 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.
  • 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.
  • the Plugin-Manager enables the KI-lndex-Filter (7615a, 7615b, 7615n of FIG. 24) for the specified channel for that Plugin.
  • 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 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-
  • 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:
  • a Monitor (5200 of FIG. 14) is created.
  • the Monitor is attached to the Manabars-Set that is to be watched by using:
  • Kl-Add-Monitor for Emulator-Components.
  • the Monitor is triggered by the Kernel-Image (see Appendix G), which captures the state of the
  • 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.
  • 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).
  • 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.
  • 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.
  • 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).
  • 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).
  • 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.
  • 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).
  • 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).
  • 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.
  • the Asynchronous-Virtual-Machine-Format 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).
  • 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.
  • 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).
  • 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.
  • 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).
  • AP-CPU processes each instruction by moving information across either the CPU-Stack-Bus
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • AVMI Abstract-Virtual- Machine-Instructions
  • 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 (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.
  • 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.
  • 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):
  • 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
  • the Jump-Loader uses the following algorithm:
  • FIG. 75 at the same index as the AVMI in the AVMF sequence for that instruction as true, otherwise it remains false.
  • 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.
  • the AVMF-Memory (23210 of FIG. 75) transmits the AVMF-Loaded- Signal (23245 of FIG. 75) to the Integrity-Checker (23250 of FIG. 75):
  • 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).
  • Every AVMI is transferred across the AVMF-Bus (23240 of FIG. 75), starting at the first index and ending at the last.
  • the changes are reflected in the Simulated-Stack (23260 of FIG. 75) and the Stack-Count (23255 of FIG. 75).
  • 2 associated bits are also transferred that indicates:
  • a bit from the Boolean-Land-Array indicates if a branching instruction points to the AVMI.
  • a bit from the Boolean-Jump-Array indicates if the execution flow branches to another AVMI.
  • AVMI-W-Add 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.
  • 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.
  • 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 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.
  • 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 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.
  • 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:
  • 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.
  • 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).
  • 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).
  • the Governance Layer 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.
  • 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
  • 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.
  • 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
  • Method-Frame-Indexing is used heavily during Object Orientated support to enable independent method-frames to access their own variables.
  • 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 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.
  • the Whole value of the Target is set to the retrieved value.
  • the Float value of the Target is set to the retrieved value.
  • Type of the Target-Field is of Type-Type then the Type of the Target is set to the retrieved value.
  • Target is inserted into the Target-Field before the UPT-Cast is deleted from the Stack.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Multi Processors (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Un ordinateur virtuel universel permet de fournir un environnement de grille homogène à un ensemble d'hôtes hétérogènes. On obtient ce résultat en fournissant un format d'exécution commun par compilation croisée.
PCT/NZ2006/000254 2005-09-30 2006-10-02 Plate-forme d'abreges permettant de faciliter l'interoperabilite d'informations Ceased WO2007037709A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US72289605P 2005-09-30 2005-09-30
NZ542761 2005-09-30
NZ54276105 2005-09-30
US60/722,896 2005-09-30

Publications (1)

Publication Number Publication Date
WO2007037709A1 true WO2007037709A1 (fr) 2007-04-05

Family

ID=37900034

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/NZ2006/000255 Ceased WO2007037710A2 (fr) 2005-09-30 2006-10-02 Dispositif de calcul informatique pour gestion d'ensembles
PCT/NZ2006/000254 Ceased WO2007037709A1 (fr) 2005-09-30 2006-10-02 Plate-forme d'abreges permettant de faciliter l'interoperabilite d'informations

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/NZ2006/000255 Ceased WO2007037710A2 (fr) 2005-09-30 2006-10-02 Dispositif de calcul informatique pour gestion d'ensembles

Country Status (1)

Country Link
WO (2) WO2007037710A2 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030187915A1 (en) * 2002-03-29 2003-10-02 Xian-He Sun Communication and process migration protocols for distributed heterogenous computing
US20030225822A1 (en) * 2002-05-30 2003-12-04 Microsoft Corporation Unbounded computing space
US20040205751A1 (en) * 2003-04-09 2004-10-14 Berkowitz Gary Charles Virtual supercomputer
US20050021594A1 (en) * 2002-02-04 2005-01-27 James Bernardin Grid services framework
US20050125537A1 (en) * 2003-11-26 2005-06-09 Martins Fernando C.M. Method, apparatus and system for resource sharing in grid computing networks
US20050160413A1 (en) * 2004-01-21 2005-07-21 International Business Machines Corporation Method and system for a grid-enabled virtual machine with movable objects

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5592667A (en) * 1991-05-29 1997-01-07 Triada, Ltd. Method of storing compressed data for accelerated interrogation
US5479656A (en) * 1992-05-13 1995-12-26 Rawlings, Iii; Joseph H. Method and system for maximizing data files stored in a random access memory of a computer file system and optimization therefor
CA2225932A1 (fr) * 1997-05-09 1998-11-09 Kim Lawson Rochat Gestion de la memoire dans un systeme de programmation a recuperation partielle des miettes
US5924098A (en) * 1997-06-30 1999-07-13 Sun Microsystems, Inc. Method and apparatus for managing a linked-list data structure
AU3907300A (en) * 1999-03-19 2000-10-09 Raf Technology, Inc. Rollup functions for efficient storage, presentation, and analysis of data

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050021594A1 (en) * 2002-02-04 2005-01-27 James Bernardin Grid services framework
US20030187915A1 (en) * 2002-03-29 2003-10-02 Xian-He Sun Communication and process migration protocols for distributed heterogenous computing
US20030225822A1 (en) * 2002-05-30 2003-12-04 Microsoft Corporation Unbounded computing space
US20040205751A1 (en) * 2003-04-09 2004-10-14 Berkowitz Gary Charles Virtual supercomputer
US20050125537A1 (en) * 2003-11-26 2005-06-09 Martins Fernando C.M. Method, apparatus and system for resource sharing in grid computing networks
US20050160413A1 (en) * 2004-01-21 2005-07-21 International Business Machines Corporation Method and system for a grid-enabled virtual machine with movable objects

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
ADABALA S. ET AL.: "From virtualized resources to virtual computing grids: the In-VIGO system", FUTURE GENERATION COMPUTER SYSTEMS, vol. 21, no. 6, June 2005 (2005-06-01), pages 896 - 909, XP004904961 *
FIGUEIREDO R. ET AL.: "A Case for Grid Computing On Virtual Machines", IEEE PROCEEDINGS OF THE 23RD CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS, 2003, 19 May 2003 (2003-05-19) - 22 May 2003 (2003-05-22), pages 550 - 559, XP010642326 *
KRSUL I. ET AL.: "VMPlants: Providing and Managing Virtual Machine Execution Environments for Grid Computing", PROCEEDINGS OF THE 2004 ACM/IEEE CONFERENCE ON SUPERCOMPUTING, 2004, XP010780332 *
SUNDARARAJ A. ET AL.: "Towards Virtual Networks for Virtual Machine Grid Computing", PROCEEDINGS OF THE 3RD USENIX VIRTUAL MACHINE RESEARCH AND TECHNOLOGY SYMPOSIUM (VM 2004), pages 1 - 15, XP007902101 *
ZHANG X. ET AL.: "Virtual Cluster Workspaces for Grid Applications", TR-ANL/MCS-P1246-0405, April 2005 (2005-04-01), pages 1 - 12, XP003008896 *

Also Published As

Publication number Publication date
WO2007037710A3 (fr) 2007-05-31
WO2007037710A2 (fr) 2007-04-05

Similar Documents

Publication Publication Date Title
US20200351341A1 (en) System method and model for social synchronization interoperability among intermittently connected interoperating devices
Allen Reactive design patterns
Cirne et al. Labs of the world, unite!!!
Warneke et al. Nephele: efficient parallel data processing in the cloud
Schmidt et al. Pattern-oriented software architecture, patterns for concurrent and networked objects
Gregor et al. Lifting sequential graph algorithms for distributed-memory parallel computation
KR101076910B1 (ko) 객체 지향 언어로의 병행 프로그램 구현
CN103262064A (zh) 分布式计算体系结构
Karmani et al. Actors
FR2810423A1 (fr) Systeme informatique modulaire et procede associe
US20070256059A1 (en) Abstract platform to facilitate the interoperability of information
US20240020100A1 (en) Decentralized software development environment for function-based executable applications
Karau et al. Scaling Python with Ray
Dumas et al. Event-based coordination of process-oriented composite applications
WO2007037709A1 (fr) Plate-forme d'abreges permettant de faciliter l'interoperabilite d'informations
Jamali et al. A scalable approach to multi-agent resource acquisition and control
Morrison et al. WebCom-G: A candidate middleware for Grid-Ireland
Liu A distributed data flow model for composing software services
Nguyen An object-oriented model for adaptive high-performance computing on the computational grid
Cao et al. Architecting and implementing distributed Web applications using the graph‐oriented approach
Margaria et al. Leveraging Applications of Formal Methods, Verification and Validation. Specialized Techniques and Applications: 6th International Symposium, ISoLA 2014, Imperial, Corfu, Greece, October 8-11, 2014, Proceedings, Part II
Stoutchinin A Dataflow Framework For Developing Flexible Embedded Accelerators A Computer Vision Case Study.
Spreitzer et al. Ripple: Improved architecture and programming model for bulk synchronous parallel style of analytics
Gray Ph. D. Thesis Proprosal: Transportable Agents
Huang C++: a concurrent object-oriented programming language

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06812829

Country of ref document: EP

Kind code of ref document: A1