Application Number: AU 2026202148

The Enterprise Model Lives on the Chip A Small Computer That Runs a Company Model Instead of Querying a Database

The word microprocessor in the title is doing something specific and slightly misleading. This is not a new instruction set or a new silicon design. Claim 1 recites "a semiconductor chip (microprocessor) having both data and software instructions embedded therein as a single model", and the point of the phrase is the embedding, not the

Open for Public Inspection
AU 2026202148 Featured Image

View the The Enterprise Model Lives on the Chip PDF

Download the PDF version of this Application Open to Public Inspection

Despite its title, this application is not about a faster processor. It claims a small computer, described throughout as a single board computer, whose memory holds a structured model of how an organisation actually works, and whose processor executes that model directly rather than fetching records from a separate database by query. Claim 1 spells out the internal layout in unusual detail: two buses that can reach each other only through the CPU, a kernel memory hidden from everything else, a working memory carrying more than one model of a business domain, and an encryption unit sitting across everything that leaves the board. It was filed by Dimitris Lyras, a Greek shipowner who founded the maritime software company Ulysses Systems, with Konstantinos Dimopoulos named as co-inventor.

The Problem

The specification’s complaint is that general purpose computers are the wrong shape for enterprise work. Ordinary machines carry human interaction facilities, as the specification puts it, far exceeding the facilities needed for a specific enterprise application, and those facilities have to be integrated with a large volume of enterprise information and a plethora of software features. The result, it argues, is that specific applications end up resource intensive and slow.

It singles out the database layer. SQL and its equivalents require a service to run and handle retrieval and storage in most enterprise software, with several sub steps needed for every retrieval, and the programming around that service is described as intensive. The specification’s position is that a system which already holds its logic and its data together does not need the query layer at all.

The second complaint is about upgrades. Software development spending, the specification says, is often considered to consist broadly of fifty per cent requirements elicitation, design and implementation and fifty per cent testing, and it notes there are few other industries where testing takes such a share. It traces that cost to a lack of traceability: without a model that describes enterprise processes and status, nobody can tell which parts of a system a change will reach, so partial upgrades cannot be relied on to be free of defects.

Two settings make that upgrade problem acute. The first is the internet of things, where components are not necessarily managed or produced by one stakeholder and must interoperate during end use without having been designed together, so incompatibility gets resolved by upgrade. The second is emergency response, where the specification works through an unfolding incident in which unanticipated requirements appear mid event, and argues that being able to modify the software during the emergency could materially change the outcome. Cybersecurity is offered as a third consequence of the same cause: because conventional systems share layers of common software for storing and retrieving data, illicit agents can infiltrate a large majority of them with the same methods.

What This Invention Does

The word microprocessor in the title is doing something specific and slightly misleading. This is not a new instruction set or a new silicon design. Claim 1 recites “a semiconductor chip (microprocessor) having both data and software instructions embedded therein as a single model”, and the point of the phrase is the embedding, not the chip. The specification is candid that prototypes are built from discrete, widely available components, and that only after the microkernel stabilises would the parts be assembled into a single chip with the cooperation of chip manufacturers. Read plainly, the claim describes a board level architecture whose distinguishing feature is what lives in its memory, dressed in hardware language so that it reads as an apparatus rather than as a computer program.

Claim 1 is a “domain model computation unit”. Its CPU is configured to process the embedded data and software instructions according to the single model, and the claim adds the words that carry the weight: “without requiring data retrieval by query from an external data model”. The CPU sits between two buses and, crucially, all communication between the first bus and the second bus is through the CPU. The first bus reaches a set of internal modules. The second bus reaches an input and output unit that talks to the outside world.

The internal modules are enumerated. There is a kernel non volatile memory, a working non volatile memory, a random access memory, and an encryption and decryption unit that encrypts and decrypts data exchanged with devices external to the board. In the detailed description the kernel memory is hidden from any external access and communicates only with the CPU, and holds three things: an operating system, a model kernel that gives the unit its ability to understand the model at all, and a communications model used to synchronise with a server side copy. New model kernels arrive as encrypted binaries and can only be installed after passing through the decryption unit, which the specification presents as the reason the kernel is close to impossible to hack remotely.

The final limitation of claim 1 is the one that gives the unit its character. The working non volatile memory includes more than one domain model, each domain model being a set of nodes linked together by one or more paths all converging on one or more goals, and the goals of each domain model are different. A node in this scheme is an activity with a status and a state, links between nodes carry cause and effect logic that propagates values from one node to the next, and context is what keeps two structurally similar processes apart. The specification’s worked example is drawn from tankers, with goals like discharging a particular class of vessel sitting above more specific process nodes.

The other independent claims widen the same idea across 40 claims in total. Claim 8 splits an enterprise model across several units joined by a third bus, claim 17 adds a power management unit that tells the CPU about power status, claim 30 claims a grid of units, and claim 34 claims a multi level abstraction system whose node clusters connect to external applications through predictive pattern modules.

Key Features

  • Two buses that meet only at the processor. Internal memory sits on one bus, the outside world on the other, and nothing crosses between them except through the CPU, which turns the processor into a single mandatory checkpoint.
  • A kernel memory nothing else can see. The kernel non volatile memory communicates only with the CPU and holds the model kernel, so the code that interprets the enterprise model cannot be reached from the input and output side at all.
  • More than one domain model, each aimed somewhere different. Claim 1 requires the working memory to hold several domain models whose goals differ, and the specification says these can be executed in parallel, so one board can carry maintenance, purchasing and crewing as separate goal structures.
  • Encryption placed at the boundary. The encryption and decryption unit handles everything exchanged with external devices and every upgrade package, so security is a property of the board layout rather than something each application has to implement.
  • Designed to keep working when the link drops. Claim 7 has the random access memory support the domain models when communication with external devices is lost, and the description splits an enterprise model between a central unit and handheld satellite units so each stays useful offline for the role it was given.
  • Redundancy by redistributing models. If one unit is damaged, its domain models can be moved to surviving units, and a standby central model held on a handheld device can take over if the central processing unit fails.

Who Is Behind It

The applicant is an individual rather than a company. Dimitris Lyras is an engineer by training and part of a Greek shipping family with, by one industry profile, more than 150 years in the business. He is connected to Lyras Shipping, which sold its fleet near the top of the market in 2006 and returned with an order for long range product tankers, and he is a member of the Intertanko council. In 1996 he founded Ulysses Systems, whose Task Assistant products cover maintenance, purchasing, document management, crewing and certificates for ship managers, and whose marketing describes the platform as the knowledge map, the data model and the code a maritime enterprise needs. That is a fair summary of what claim 1 is trying to put on a board.

The maritime background shows through in ways that are easy to miss. The offline behaviour, the fragmentation of models into small packets suited to a satellite link, and the worked example about discharging a class A tanker are the concerns of someone whose users are at sea rather than at a desk.

The specification names its own predecessors. It cites US 8,571,910 and US 2014/0330616 A1, both titled “System and Method for Identifying Relevant Information for an Enterprise” and both by D. Lyras, and it takes the “Overlay” concept from them. The Overlay is described as a relevance engine rather than a search engine, one that finds cases similar to a current problem by locating similar process steps and similar proximity to a goal. This application is the hardware expression of that idea.

The Australian filing is a divisional twice over. The specification states that it is a divisional of Australian application 2024201858, which is itself a divisional of Australian application 2018276339, and it says nothing at all about priority beyond that. The published family record, rather than the Australian specification, is what establishes the rest: 2018276339 entered Australia from PCT/EP2018/063971, filed 28 May 2018, which traces back to US application 15/952,650 filed 13 April 2018 and granted as US 11,294,641, which in turn claims the benefit of US provisional application 62/512,318 filed 30 May 2017 under the same title. That makes the United States the priority country, and it means the disclosure being examined in Australia in 2026 was written nine years earlier.

Why It Matters

The bet this specification is making is that the separation of code from data, which has been the organising assumption of business computing since relational databases became standard, costs more than it is worth for a narrow class of applications. Conventional enterprise resource planning systems put the meaning of a business in a schema, the behaviour of the business in application code, and a query layer between them, and every change has to be reconciled across all three. Collapsing them into one executable model of nodes, links and goals is not a new idea in the abstract, but committing it to a board layout with a hidden kernel and a mandatory encryption boundary is a specific and unusual way to pursue it.

The performance claim deserves the scepticism any such figure invites. The specification suggests embedding the code on the chip enhances performance perhaps a thousandfold against generic storage software using SQL with separate domain processing on a separate server. That is an assertion about an architecture, not a measurement of a product.

What is more interesting is the microkernel posture. By putting the model interpreter in a memory only the CPU can address, and by requiring upgrades to arrive encrypted and be decrypted on the board, the design treats an enterprise model as something closer to firmware than to an application. The upgrade story follows from that. Because a change is expressed as a change to particular nodes, and because the links record which other nodes a value propagates to, the system can in principle tell you the blast radius of a change before you ship it. That traceability, not the silicon, is what the whole specification is actually about, and it is the argument the document is worth reading for: that for organisations whose people work in poor connectivity and whose processes are highly specific, the generic computer plus generic database plus generic application stack is a poor fit.

Related Concepts

  • System on a chip – the manufacturing endpoint the specification describes, once the discrete prototype has stabilised.
  • Semantic network – the general form of the node and link structure the domain models use.
  • Model-driven engineering – the software discipline of treating an executable model rather than source code as the primary artefact.
  • Edge computing – the pattern behind the satellite units that keep working when the central link is lost.
  • Internet of things – the interoperability problem the specification names as the main reason upgrades need to be traceable.

AU 2026202148 was published in the Australian Official Journal of Patents on 9 April 2026 and is open for public inspection. Patent applications represent inventions that are sought to be protected and do not necessarily reflect commercially available products.

Related Patents Open to Public Inspections

See related Patents open to public inspection.

Open for Public Inspection

Scalable System on a Chip

Application Number: AU 2026201978 Filed:16/03/26 | Published: 02/04/26
Disclaimer

The information presented in this article is provided for general informational and illustrative purposes only.

Content on this page may be derived from publicly available intellectual property records, including patent documentation and related materials. While reasonable care is taken in compiling and summarising this information, ATMOSS does not guarantee the accuracy, completeness, currency, or reliability of any content presented.

This article is not a substitute for reviewing the original source documents. Patent applications, specifications, claims, and related records may contain detailed technical, legal, and contextual information that is not fully represented in this summary.


ATMOSS does not provide legal, technical, or commercial advice. Users should not rely on this content for decision-making purposes.
For authoritative and up-to-date information, users should refer directly to the official records available via IP Australia and other relevant intellectual property databases. Links to these official sources are provided where applicable.


ATMOSS accepts no liability for any loss, damage, or consequences arising from the use of, or reliance on, the information contained in this article.