BE1030880B1 - Platform for real estate transactions with a distributed ledger - Google Patents

Abstract

A distributed ledger real estate transaction platform, wherein the platform includes: a database layer configured to interface with at least two government database nodes whose database is managed by a government agency; a ledger layer, where each ledger block is assigned to an associated real estate object; each ledger block has an owner; wherein the ledger layer is configured to connect to the government database nodes to request official data relating to a real estate asset; receive storage instructions from the owner as to whether or not to store the official data on the ledger block; receive actor permissions from the owner; an actor layer, comprising multiple actor nodes configured to, grant an actor access to at least some of the official data on the real estate block after the ledger layer receives an appropriate actor permission from the owner.

Description

1 BE2022/5732

Platform for real estate transactions with a distributed ledger

The present invention relates to platforms using a distributed ledger, in particular a real estate transaction platform.

The platform can, for example, be implemented in a Software as a Service (Saas) environment.

In most countries, transferring ownership of a real estate object is characterized by a complex and lengthy administrative process. A number of steps must be followed, which are set by the government to ensure and validate that the transfer of ownership is done correctly and safely. Various documents and certificates must be requested, often from different government agencies or inspection services. Each of these agencies and services use their own database, and sometimes have to visit the property before they can issue the document. Moreover, different actors often have to request the same documents, resulting in duplication of effort. If a few years later the property changes ownership again, the same process must be completed, despite the fact that many of the documents or certificates still contain the correct information.

It is the purpose of the invention to overcome one or more of the disadvantages of the prior art, or at least to provide an alternative to the prior art. In particular, it is an aim of the invention to make the flow of information and documentation in a real estate transaction more efficient.

One or more of the objects of the invention are achieved with a distributed ledger securities transaction platform, the platform comprising: a database layer configured to interface with a plurality of database nodes each comprising a database, the database -nodes include at least two government database nodes whose database is managed by a government agency; e a ledger layer, comprising multiple ledger blocks, each with a unique block code, wherein the ledger blocks are stored in a distributed ledger, wherein e each ledger block is assigned to an associated real estate object:;

2 BE2022/5732 e each ledger block has an owner; e the ledger layer is configured to e connect to the government database nodes to request official data related to a real estate object; e store a unique document code linked to the official data on the ledger block associated with the real estate object; e receive storage instructions from the owner as to whether or not to store the official data on the ledger block; e receive actor permissions from the owner; e an actor layer, comprising multiple actor nodes configured to, grant an actor access to at least some of the official data on the real estate block after the ledger layer receives an appropriate actor permission from the owner.

The invention thus relates to a platform with a distributed ledger. For example, the distributed ledger could be a blockchain. The platform can be implemented as a software system, then run on different servers. The servers may or may not be in the same location. For example, the platform may be accessible to the users (for example via a user interface) via a computer, tablet, or smart phone, for example via a web browser or a downloadable program or application. The platform may include one or more sub-platforms that allow users to interact with the platform.

The platform can preferably be used for a real estate transaction. A real estate transaction can, for example, relate to a transfer of ownership of a real estate object. The real estate object can, for example, be real estate such as a house, apartment, building land, or agricultural land.

The platform includes three layers: a database layer, a ledger layer, and an actor layer. The database layer is designed to connect to multiple database nodes. Each database node contains a database in which information is or can be stored that relates to the real estate object. The databases and the information contained therein are not necessarily managed by the platform. Even more so, at

3 BE2022/5732 preference, the database layer includes at least two government database nodes, the database of which is managed by a government agency. This could, for example, be a federal, regional or local government, which works with its own information system to manage the database. However, in embodiments it is also possible for the database layer itself to include some databases managed by the platform.

The ledger layer refers to a distributed ledger, in which multiple ledger blocks are stored. Each ledger block has a unique block code to identify the ledger block. The fact that the ledger is distributed implies that it is managed by multiple (digital) administrators.

This makes it impossible for a single administrator to add or change a ledger block without approval from the other administrators. In this way the correctness of the ledger blocks is guaranteed. Each ledger block is assigned to an associated real estate object, for example a house, apartment, building land, or agricultural land. Information stored on the ledger block therefore relates to the associated property object. Every ledger block also has an owner. For example, the owner may be the owner of the physical real estate object, although it is also possible that the owner of the physical real estate object outsources the ownership of the ledger block, for example to the person or organization he/she trusts.

The ledger layer is configured to connect, via the database layer, to the database nodes to request information related to the real estate object. In particular, the ledger layer is configured to connect to the government database nodes for official data on 1st queries. This official data can be an official document in itself, or data that is usually stated on official documents. The owner can access and view the official data in this way. The platform therefore provides the owner with the opportunity to consult official data from various databases.

When the general ledger layer receives the official data, a unique document code is generated that is linked to the official data. This unique document code is stored on the ledger block of the associated property object. The unique document code functions as a verification that the official data (specifically the official document) is genuine, as obtained from the government database node. Since the unique document code on the

4 BE2022/5732 ledger block is stored, it is guaranteed that it cannot be changed without all administrators being aware of it.

The official data (in particular the official document) is not stored on the ledger block by default. Since the ledger block is managed by multiple people, this could otherwise result in the owner's data being shared without his consent. However, the ledger layer can receive save instructions from the owner. Using these storage instructions, the owner specifies whether or not the official data should be stored on the ledger block. Therefore, if the owner wishes, he can use the platform as a repository for his official data, but the owner is not obliged to do so.

The actor layer includes multiple actor nodes. The actor is, for example, an actor in a real estate transaction, for example a real estate agent, a notary, a lender, a surveyor, an inspection body, a location planner. The actor can access the platform via the actor node. The actor can at least be enabled to access some of the data stored in a particular ledger block, for example some of the unique document codes and/or the official data. In this way, the actor gains access to data such as documents necessary for the steps that the actor must complete during the real estate transaction. It is no longer necessary for the actor to request official data from government authorities themselves, for example.

However, the actor cannot simply access the data on the ledger block. Configured the ledger layer to receive actor permissions from the owner. These actor permissions allow the owner to grant a specific actor permission to access certain data, including official data. In this way, privacy requirements can be met.

For example, the owner can give an actor access to all data on the ledger block, or select some (official) data, for example, depending on what the actor needs to do with it. If the owner has not yet stored any official data but only the unique document codes, he can of course add the official data to the ledger block. Optionally, the platform can verify at that time with the relevant database node whether the official data uploaded by the owner is correct. The actor permission can be temporary,

for example, limited to a certain period or until the actor has performed a certain action.

From the above explanation, it can be seen that the platform can provide different functions that are beneficial to different users. First, a real estate owner can request official data from different government database nodes via the platform, so that the owner does not have to do this individually from each government agency separately. Moreover, if the owner wants, he can store these official data on the ledger block.

This allows the owner if it were to use the platform as a "digital vault".

Because the unique document codes and any official data are stored in a distributed ledger, the authenticity of the documents is guaranteed. For documents or data that do not have an expiration date, this also means that they do not have to be requested again during a subsequent real estate transaction in the future on the same real estate object. The owner can also share official data with actors via the platform. The platform therefore allows efficient sharing of official data, which means that the same official data has to be requested less often and the turnaround time of a household goods transaction can be accelerated.

It will be understood that the platform may comprise one or more processing units to perform the various steps and processes. For example, the general ledger layer may include one or more processors. The platform may comprise computer-executable instructions that cause the processing units to carry out the various steps and processes. The platform may further comprise one or more memories to store data and/or (computer-executable) instructions. The platform can include various wired or wireless communication channels between different components. The platform may include one or more types of user interfaces that allow a user (e.g. actor or owner) to interact with the platform. All these types of components are well known and will not be explained in extensive detail herein. Those skilled in the art will understand from the explanation herein how to implement the invention.

In embodiments, the actor layer is configured to receive actor-provided data from the actor, where the actor-provided data relates to a planned or happening adjustment to the official data, where

6 BE2022/5732 optional, the platform is further configured to inform the government database node about the adjustment, based on the actor-provided data.

In these forms of implementation, in addition to gaining access to the official data, the actors can also provide data to the platform themselves: the so-called actor-provided data. This may relate in particular to a planned or actual adjustment to the official data. Examples of this include a new owner of the real estate object; a construction of a house on a plot of land; a renovation or addition; a new or renewed inspection certificate; a loan with the real estate object as collateral; a rental contract that relates to the real estate object. The platform can then be configured to pass this adjustment on to the government database node, so that it can adjust the official data in its database. If this adjustment is relevant to multiple government database nodes, the platform can inform each of those government database nodes. The platform therefore provides an efficient platform for these implementation forms to register the adjustment as necessary, without the actor having to inform each government agency individually.

When the adjustments have been made, this may imply that some of the official data or unique document codes stored on the ledger block are no longer current. The ledger layer can therefore be configured to request custom official data or at least custom unique document codes, depending on the owner's storage instructions, from the respective government agency. This adjustment is thus notified to all administrators of the distributed ledger. If the modified data is relevant to an actor with an active actor permission, the actor layer can be configured to notify that actor of the modification.

In embodiments, the ledger layer is configured to receive government permissions from the owner, and to access the official data using the government permissions when connecting to the government database nodes. These embodiments ensure that the platform cannot access the official data without the owner's consent, such that privacy requirements can be met. Optionally, the owner can grant a general government authorization that is valid for multiple government database nodes. The (general) government authorization can optionally be limited in time or until certain official data has been requested.

7 BE2022/5732

In embodiments, the ledger layer is further configured to retrieve database data from a database of a database node and store it on the ledger block, and the platform is configured to store this database data on the ledger block and in the ledger block. database to be adjusted based on actor-provided data. For example, if the database is managed by the platform itself instead of a government agency, the platform itself can make adjustments to the database and to the ledger block. This can, for example, be advantageous for types of data for which no database currently exists, but which are regularly needed for real estate transactions. If no database yet exists for certain data, the platform can be set up to create a database node with associated database the first time such data is provided to the platform by an owner and/or by an actor. In some cases it may also be that the respective database is managed by an external entity (e.g. other than a government agency), and then the platform is authorized to make adjustments directly to the database based on actor-provided data.

In embodiments, the distributed ledger is configured to be managed by multiple administrators, with the administrators divided into different categories with different permissions regarding what data can be managed. As explained above, management with multiple administrators is advantageous because the authenticity of the data can be guaranteed.

However, the implication of the distributed ledger is that the administrators have access to the data they need to co-manage. With a view to privacy, this may not be desirable in some cases. In these embodiments, the managers are therefore divided into categories. Depending on what type of information is relevant or not relevant or available through other means, a category of administrators can be given rights to manage certain data on the ledger blocks, or certain ledger blocks. For example, in certain cases an administrator may also be an actor, for example a notary, who legally has access to certain data outside the platform. This can then also manage the corresponding data in the distributed ledger without privacy problems.

In embodiments, the platform is configured to manage access to data from a ledger block for an actor with a smart contract. A smart contract, also called a smart contract, is a protocol to automatically execute, control or document events and actions according to the conditions

8 BE2022/5732 of a contract or an agreement. In this context, a smart contract can be used to ensure that a sequence of actions or steps in the cash transaction is automated.

In embodiments, the platform is configured to access official data from the government database nodes and manage them with a smart contract. Also in this context, a smart contract can be used to ensure that a sequence of actions or steps in the real estate transaction is automated.

In embodiments, the ledger layer is configured to receive a publish permission from the government agency to make the official data public, and configured to add the official data to the ledger block only after receiving the publish permission and/or configured to to make official data available to an actor only after receiving publication authorization. For example, the official data may contain information relating to more people than the owner. In that case, sharing this data with distributed ledger operators and/or actors could be a privacy violation. In these forms of implementation, such privacy violations are prevented, as the government agency gives the publication authorization and thus gives permission to share the official data. Optionally, the publication authorization may contain limits regarding which (categories of) persons or actors can access the official data and/or regarding a period of time during which the official data remains available.

In embodiments, the ledger layer is configured to send a renewal request to the owner when any of the official data no longer meets validity requirements. The ledger layer is further configured to send a refresh request for the respective official data to the respective government database node when a refresh confirmation is received from the owner in response to the refresh request. If a payment is due for the renewal of the official data, the platform can be configured to generate a payment request for the owner.

In these embodiments, the official data is therefore kept up to date, subject to the owner's permission. For example, the validity requirements are not possible

9 BE2022/5732 are no longer met when a validity date has expired or when adjustments have been made that require renewal of the official data. In some embodiments, the platform may be arranged to check the validity requirements based on other (official) data that is added, changed, or deleted. This can, for example, be recorded using a smart contract.

In embodiments, the ledger layer may be configured to receive owner-provided data from the owner, and add the owner-provided data to the ledger block and/or modify data on the ledger block based on the owner -provided data. Optionally, the platform is further designed to add and/or adjust one or more data in a database based on the owner-provided data. These embodiments allow the owner to add data himself. This could, for example, be data for which the owner has official documents, and/or data for which no connection to a database node is (yet) available in the platform.

In short, the distributed ledger is a blockchain, where the unique block codes of the ledger blocks are hash codes. Blockchain is currently a popular technology to implement a distributed ledger, which is suitable for the present invention. However, it is noted that the interaction with the database layer and the actor layer, as well as the stated permissions, are inventive functionalities that deviate from the known blockchain platform.

In Embodiments, the ledger layer is configured to generate a new ledger block when data on an existing ledger block is modified or added, where the new ledger block has a new block code, one where the new ledger block is linked to the existing ledger block using the block code of the existing ledger block. In these formats, a chain of ledger blocks is thus formed per vase object, whereby the ledger blocks are linked to each other by the block codes. This implementation makes it virtually impossible to change a ledger block without the other administrators noticing.

In Embodiments, the database layer includes one or more of the following government database nodes: a quay register node; an urban development node; a contamination database node.

10 BE2022/5732

The quayside register node can, for example, contain a database with patrimonial data. That database can, for example, be managed by a federal government. The patrimonial data may, for example, relate to one or more of: the name of the owner(s) of the real estate object; the rights of each owner; the nature of the real estate object, for example house, garden or land; a plot number; a year of construction of the real estate object; a plot area; a graphical representation of the plot where a real estate object is located, with the boundaries and buildings on the plot; cadastral incomes; a list of adjacent parcels.

For example, the urban planning node includes a database with urban planning data. For example, the database is managed by a provincial or municipal government. For example, the urban development data includes one or more of: permits: construction violations; pre-emption rights; allotment regulations.

The pollution database node, for example, contains a database with pollution data, for example managed by government. The contamination data may, for example, relate to soil contamination.

Different government database nodes can therefore be managed by different (types) of government agencies. Some government agencies have smaller geographic coverage than others. For government agencies with smaller geographic coverage, multiple government agencies may be relevant within the platform. For example, multiple provincial or municipal governments can manage relevant urban planning data. In that case, the platform may include multiple of the respective government agency nodes, and/or the data from multiple respective government agencies may be combined in the database of a single government agency database node.

In embodiments, the database layer includes one or more of the following database nodes: a surveyor node; one or more inspection body nodes. These nodes can contain a database of data that is not normally managed by a government agency. It is possible that the database layer connects to an external database, for example managed by a third party. However, it is also possible that the database layer includes a respective database, and that the platform manages this database.

11 BE2022/5732

The surveyor node comprises, for example, a database with surveyor data. The surveyor data relates to measurements made by a surveyor.

The inspection body node comprising one or more than one database with inspection data. For example, the inspection data may relate to one or more of: energy performance of the real estate object, asbestos data of the real estate object, a boiler or fuel oil tank installed in the real estate object, an electrical installation.

In embodiments, actor layer includes one or more of the following actor nodes: a real estate agent node; a notary node; a lender node; a surveyor node; an inspection body node; a location description node; a copper node.

For example, the real estate agent node is configured to give a real estate agent access to data to sell or rent the real estate asset. The real estate agent can, for example, present this information to potential buyers or tenants.

For example, the notary node is configured to provide a notary with access to data to provide for the transfer of ownership of the property.

For example, the lender node is configured to allow a lender to access data to grant credit related to the property.

For example, the surveyor node is configured to allow a surveyor to access surveyor data, and optionally give the surveyor permission to modify the surveyor data.

For example, the inspection body node is configured to give an inspection body access to inspection data, and optionally to give the inspection body permission to modify the inspection data, where the inspection data can, for example, relate to one or more of: energy performance of the real estate object, asbestos data of the real estate object, a boiler or fuel oil tank installed in the real estate object, an electrical installation.

For example, the site description node is configured to give a site description expert access to site description data, and optionally the

12 BE2022/5732 expert location description to give permission to adjust the location description data.

For example, the buyer node is configured to give a potential buyer access to data relevant to making a purchasing decision.

The invention further relates to a Software as a Service (Saas) application, comprising the platform according to one or more of the implementation forms described herein.

The invention further relates to a method for sharing data, wherein the method comprises a step in which use is made of the platform according to one or more of the previous embodiments described herein.

Features described in relation to the platform may be similarly applied to the process to achieve similar benefits, and vice versa, and are therefore not discussed in extensive detail. After all, the professional understands from the explanation of the platform how the corresponding steps can be implemented in a method.

Specific embodiments and examples of applications of the method will also be illustrated with reference to the figure description. It is to be understood that the invention also relates to each of those embodiments and examples.

The invention is explained below using figures. The described embodiments are only examples and include, for example, optional features. The description below will therefore not be interpreted as limiting the conclusions. In the figures:

Fig. 1: schematically illustrates an embodiment of a platform according to the invention;

Fig. 2a: Schematically illustrates a distributed ledger where all administrators manage the entire ledger;

Fig. 2b: Schematically illustrates a distributed ledger where different categories of administrators manage different data;

Fig. 2c: schematically illustrates a ledger block change;

13 BE2022/5732

Fig. 3: schematically illustrates a real estate transaction using the platform;

Fig. 1 schematically illustrates an embodiment of a platform according to the invention. Platform 1 is used for a real estate transaction. The platform includes a ledger layer 3, which is connected to a database layer 2 and an actor layer 4. The database layer 2 includes several database nodes 11-16, in this case a dock ray register node 11, a urban planning node 12, a pollution database node 13, a surveyor node 14, a first inspection body node 15 (e.g. regarding inspections regarding energy performance of a real estate object), and a second inspection body node 16 (e.g. regarding inspections regarding electrical installations of a real estate object ). In practice, it is possible that further database nodes are provided, e.g. further inspection agency nodes, e.g. with regard to inspections or data on asbestos data of the real estate object, or inspections of a boiler or fuel oil tank installed in the real estate object. Each database node 11-16 includes a respective database 11.1-16.1.

In this example, three of the database nodes 11-16 are more specifically government database nodes 11-13, namely the quayside register node 11, the urban planning node 12, and the pollution database node 13. For a government database node 11-13 , the respective database 11.1-13.1 is managed by a government agency 31-33. In this example, the database 11.1 of the quay ray register node 11 is managed by a federal government agency, e.g. in Belgium the FPS Finance. Patrimonial data relating to the real estate object are stored in the database 11.1 of the quayside register node 11. The database 12.1 of the urban planning node 12 is managed by a municipal government agency 32. Urban planning data is stored in this database 12.1.

The database 13.1 of the pollution database node 13 is managed by a regional government agency 33, for example in Flanders by the Public

Flemish Waste Company (OVAM). Contamination data is stored in this database 13.1.

Although only one urban planning node 12 is shown, it will be understood that the platform 1 is not limited to a single municipal government agency 32. In practice, it is possible for the urban planning data of multiple municipalities to be stored in a single database 12.1, and/ or it is possible

14 BE2022/5732 that platform 1 includes several urban development nodes 12. Similar principles may apply to the other government database nodes 31, 33.

The fact that databases 11.1-13.1 are managed by government agencies 31-33 implies that these databases 11.1-13.1 are not managed by platform 1 itself. The government agencies 31-33 can use their own platform to manage the database and the data in it, for example as is already done.

The surveyor node 14, the first inspection body node 15, and the second inspection body node 16 also each contain a respective database 14.1-16.1.

Surveyor data is stored in the database 14.1 of the surveyor node 14.

Data about the energy performance of the real estate object is stored in the database 15.1 of the first inspection body node 15. Data about an electrical installation in the real estate object is stored in the database 16.1 of the second inspection body node 16.

However, these databases 14.1-16.1 are not managed by any government agency.

In practice, various configurations are possible here. For example, it is possible that the database 14.1 of the surveyor node 14 is managed by an external organization 34, in this case a professional organization 34 for surveyors. In Belgium, for example, this could be the Belgian Order of Surveyors-Experts. The professional organization 34 can, for example, keep certificates and/or reports made by its members in the database 14.1, and make them available to other members when they enter into an assignment for which this is relevant, for example in the same or neighboring domain.

The databases 15.1, 16.1 of the first and second inspection body nodes 15,16 are not managed by an external organization. In such case, the platform itself can manage these databases 15.1, 16.1. The platform] can do this, for example, by storing the relevant reports or certificates in the respective database 15.1, 16.1 while using the platform 1, and thus gradually building up the database 15.1, 16.1.

The ledger layer 3 comprises a plurality of ledger blocks 5, and optionally a plurality of block processors 5a. In Fig. 1, for clarity, only one of the block processors 5a is shown, with further details and connections, but it will be appreciated that similar block processors may be provided for the other ledger blocks 5. It is also possible to provide a single block processor 5a for several or all

15 BE2022/5732 ledger blocks 5. The block processor 5a is configured to enable various actions and connections, and store selected information on the respective ledger block 5. Although not shown, it is possible that the platform 1 also includes further processing units, for example for the actor layer 4 and for the database layer 2.

Fig. 2a schematically illustrates that the ledger blocks 5 and the information stored therein are managed in a distributed ledger 80. In this figure, schematic data 51-62 is shown for one of the ledger blocks 5, but it will be understood that each ledger block 5 contains data . However, these do not have to be the same types of data each time. Fig. 20 schematically shows seven managers 71a-71g. In practice, there will usually be more administrators. Since the ledger 80 is distributed, each manager 71a-71g manages the ledger 80. In this case, all managers 71a-71g manage the entire ledger 80. Thus, each manager 71a-71g knows all the data 51-62 that is on each of the ledger blocks 5 state. This makes it impossible for a single administrator 71a-71g to manipulate any of the data 51-62 on any of the ledger blocks 5 without the knowledge of the other administrators 71a-71g. In this way, the authenticity of data 51-62 is guaranteed.

Fig. 2c schematically illustrates that, for example, a blockchain can be used as a distributed ledger. This figure schematically shows two links of a chain. Each ledger block 5 includes a unique block code 5.1 (e.g. a “hash code”), on the basis of which each ledger block 5 can be identified by the administrators 71a-71c. The ledger block 5 contains data 51, 54, and 55.

If the ledger block 5 is adjusted, in this example because data 61 is added, a new ledger block 5' is created with a new unique block code 5.1'. The previous unique block code 5.1 is also included in the new ledger block 5', such that it is clear that the new ledger block 5' is the replacement for the previous ledger block 5. All administrators 71a-71c are aware of the change. Through this mechanism of the blockchain, the authenticity of the ledger blocks 5 and the data on them is guaranteed.

As shown schematically in Fig. 1, the ledger block 5 relates to a real estate object 6, which in this example is a house 6. The house 6 is therefore the associated real estate object 6 of this specific ledger block 5. Each ledger block 5 is associated with a maximum of one real estate object 6, and each real estate object 6

16 BE2022/5732 is associated with a maximum of one active ledger block 5. As explained, it is possible that when a change is made to the ledger block 5, a new ledger block 5 is created, which is then also associated with the same real estate object 6. However, in such a case only the last ledger block 5 is considered active.

The ledger block 5 has an owner 7, who in this example is also the owner 7 of the house 6. In other cases it is possible that an owner of the house 6 allows another person to act as owner 7 of the ledger block 5, for example via an authorization.

A first advantageous application of the platform 1 allows the owner 7 to efficiently consult various data related to the house 6.

As shown schematically in Fig. 1, the ledger layer 3 can connect to database layer 2. In particular, connections can be made between the block processor 5 and the various database nodes 11-16. The database nodes 11-16 can then provide data stored in their respective databases 11.1-16.1 to the block processor 5a.

However, in the case of government database nodes 11-13, government agencies 31-33 may not simply share the data [also called “official data” in the case of government database nodes) in databases 11.1-13.1, respectively. Therefore, the owner 7 can provide a government authorization 7a to the block processor 5a. Using the government authorization 7a, the block processor 5a can obtain permission from a relevant government agency 31-33 to receive certain data from the respective database 11.1-13.1 in this manner the privacy requirements can be respected. For example, the government authorization 7a can be digital, and can be limited to certain data, and/or certain government database nodes 11-13, and/or a certain real estate object 6, and/or for a certain period of time. .

The (official) data that the owner 7 can request from the database nodes 11-16 via platform 1 are, for example, (official) documents. For example, a quay beam extract 51 can be requested from the quay beam register node 11. An urban development extract 52 can be requested from urban planning node 12.

A soil certificate 53 can be requested from the pollution database node 13. An urban development certificate 54 (e.g. a so-called PreCAD or Pre cadastre document) can be requested from the surveyor node 14. An energy performance certificate 55 can be requested from the first inspection body node 15.

17 BE2022/5732

An electrical installation inspection certificate 56 can be requested from second inspection body node 16.

The above examples all concern data that is requested and presented as (paper) documents in conventional property transactions. Initially, when implementing platform 1, (digital) documents will be used in a similar manner. However, it is possible that in the longer term the principle of documents can be dispensed with, and the (official) data will be communicated as raw data from the database nodes 11-16 to the ledger layer 3.

The owner 7 can therefore request and view various official data via the platform 1. The platform 1 provides an affordable single point of contact for the owner 7, and automatically provides the connection to, for example, the various databases 11.1-13.1 of the government agencies 11-13. It is no longer necessary for the owner 7 to separately request the relevant official data from another government agency 31-33. This saves a lot of effort and time in the real estate transaction process. Every time (official) data is requested from the database nodes 11-16, the block processor 5a creates a unique document code. The unique document code is assigned and preferably applied to the data, e.g. on the document. The unique document code is also stored on the ledger block 5. Since the ledger block 5 is managed through the distributed ledger, the authenticity of the document code stored on the ledger block 5 is guaranteed. This then allows to check the authenticity of the (official) data, e.g. the [official] document.

The [official] data is not automatically stored on the ledger block 5, but can be stored there. For this purpose, the owner can give 7 storage instructions 7b to the block processor 5a. If the owner 7 wishes and agrees, the (official) data, e.g. the [official] document, is stored on the ledger block 5. Since the ledger blocks 5 are managed by different administrators of the distributed ledger, this ensures that no privacy-sensitive data is available on the ledger block 5 without the permission of the owner 7.

A further advantageous application of the platform 1 is that the owner can store 7 (official) data, e.g. (official) documents, on the ledger block 5.

18 BE2022/5732

The platform 1 can thus be used, as it were, as a digital safe by the owner 7. Because the ledger block 5 is managed in the distributed ledger, the authenticity of the (official) data, e.g. times guaranteed.

Fig. 2a, for example, illustrates a ledger block 5 on which several data 51-62 are stored, including the quay beam extract 51, the urban development

Extract 52, the soil certificate 53, the urban development certificate 54, the energy performance certificate 55, and the electrical installation inspection certificate 56. In this example, the owner has given 7 storage instructions to store each of these documents 51-56 on the ledger block 5.

In addition, the owner 7 has stored additional data 57-62 on the ledger block 5. This can be done in various ways. In some cases, the owner 7 may himself add certain data to the ledger block 5 as owner-provided data. In other cases, the platform 1 may be configured to connect to database nodes other than those shown in Figure 1, as this figure has been kept schematic and limited for clarity.

For example, location data 57 may relate to the coordinates of the real estate object. This can be obtained, for example, from commercially available map databases. A title 58 may have been added by the owner 7, although in some cases this may also be provided by a government database node, for example when the owner no longer holds the title 58. An asbestos test 59 may have been added by the owner 7 after an inspection, or may have been supplied by an inspection body node or an actor node (see below). A pre-emption rights certificate 60 may be provided by a government database node, as in some areas certain government services have a pre-emption right. Construction data 61 may, for example, relate to construction plans and/or building permits, and may be added by the owner 7 or by an actor. Usage data 62 may, for example, relate to rental contracts, usufructs, and mortgage loans. These may have been added by the owner 7, or by a relevant actor (e.g. a lender), or a government database node (e.g. concerning usufructs)]. In the case of a rental property, the usage data 62 may also include a location description report.

19 BE2022/5732

Fig. 1 further schematically illustrates the actor layer 4, which includes several actor nodes 21-27. The actor nodes 21-27 allow an actor in a real estate transaction to interact with platform 1. An actor in this context is someone who plays a role in the real estate transaction. For example, actor nodes 21-27 may include one or more of the following nodes: a real estate agent node 21, a notary node 22, a lender node 23, a surveyor node 24, an inspection body node 25, a location description node 26, a buyer node 27. It will be understood that although the schematic representation only shows different types of actor nodes 21-27, it is possible in practice for multiple actor nodes 21-27 of the same be a type. For example, every notary can access platform 1 via its own notary node 22, and the same applies to the other types of actors.

However, the actors cannot simply access the ledger block 5 without permission from the owner 7. To grant someone permission, the owner 7 can provide an actor permission 7c to the block processor 5a. Based on the actor permission 7c, the ledger layer 3 will allow a particular actor node 21-27 to access certain data on the ledger block 5. The actor permission 7c may include restrictions, for example on what data the actor node 21 -27 gets access to it and/or for how long. It is also possible that the ledger layer 3 is configured to select which data is relevant to that actor node, based on the type of actor node 21-27.

For example, the real estate agent node 21 is configured to give a real estate agent access to the data needed to sell or rent the real estate property 6. The notary node 22 is configured to provide a notary with access to data to facilitate the transfer of ownership of the real estate object 6. The lender node 23 is configured to allow a lender to access data to grant credit related to the property. The surveyor node 24 is configured to give a surveyor access to surveyor data, such as the urban development certificate 54. The inspection body node 25 is configured to give an inspection body access to inspection data. The site description node 26, configured to allow an expert site description to access site description data, for example a site description report that is part of the usage data 62. The buyer node 27 is configured to allow a potential buyer to access data that is relevant to make a purchasing decision.

20 BE2022/5732

In some cases, the certain data may relate not only to the owner 7, but also to other persons. In that case, for privacy reasons, the actor permission 7c may be insufficient to share the data on the ledger block 5 and/or with an actor node 21-27. For example, a relevant government agency 31-33 can then provide a publication authorization to the ledger layer 3, where the ledger layer 3 is configured to only add the official data to the ledger block 5 after receiving the publication authorization and/or configured to only make the official data available to an actor node 21-27 after receiving the publication permission.

The actors who gain access to data via actor nodes 21-27 can have an active role in the real estate transaction process. This means that they take actions, often based on the data received, that influence the data. Some actors may also conduct a new investigation or inspection. The real situation is therefore changing, and data on property block 5 is therefore no longer up to date.

It is therefore provided that the actor lagag can receive actor-provided data. The actor-provided data may relate to a planned or already occurred change to the data, including the official data. Based on this actor-provided data, the relevant data is adjusted in the ledger block 5. When adjusting the data, a new ledger block 5 will be created (as explained earlier with reference to Fig. 2c).

Based on the actor-provided data, the ledger layer 3 can also inform the relevant government database node 11-13, such that the respective government agency 31-33 can adjust the data in its database 11.1-13.1. Similarly, the professional association 34 can be informed if the actor-provided data relates to data in the database 14.1 of the surveyor node 14. In the case that the database is managed by the platform 1 itself, as for example with the databases 15.1, 16.1 of the first and second inspection body node 15, 16, the platform 1 itself can adjust the data in the database 15.1, 16.1.

For example, a notary can indicate via the notary mode 22 as actor-provided data that the real estate object 6 has a new owner. The platform 1 can

21 BE2022/5732 pass on this information to the quay beam register node 11, so that the government agency 31 can adjust the patrimonial data. The platform 1 will also ensure that the previous owner 7 no longer has access to the data on the ledger block 5, since the associated real estate object 6 now has a new owner.

Other examples of actor-provided data may relate to: a new lease, which is received from a real estate agent node 21; a new mortgage loan related to the real estate object 6, which is received from the lender node 23; a new survey, which is received from surveyor node 24; a new inspection certificate, which is received from an inspection body node; a new location description, which is received from a location description node 26.

Interaction between different participants of the platform 1 can be arranged via smart contracts. For example, the smart contract can record a number of actions. For example, a smart contract may be concluded with government agencies 31-33 or with (government) database nodes 11-16, where the smart contract stipulates that the ledger layer 3 will pass on to the database node 11-16 when relevant data be changed. The smart contract may further imply that certain conditions must be met in order to implement a change. Through the smart contract, it will be checked that these conditions have been met, such that, for example, the government agency 31-33 no longer has to check this. In some cases, an automatic approval or rejection can even be implemented via the smart contract.

Similarly, a smart contract can be concluded with an actor node 21-27. For example, a smart contract can check that various conditions, such as availability and validity of data/documents, are met before a notary can perform certain steps in the real estate transaction. to carry out.

Some data may have an expiration date. It is possible to immediately request updated data via a smart contract, for example from a government database node 11-13, when the validity date has expired. Optionally, a renewal request can first be sent to the owner 7, such that the updated data is only requested after a renewal confirmation from the owner 7. It is also possible that such a renewal is only requested after proactive instructions from the owner 7,

22 BE2022/5732, for example, when the owner 7 plans a real estate transaction of the real estate object 6.

When data is changed or added, a new ledger block 5 is created (as explained with reference to Fig. 2c). In this way, all administrators are immediately informed. If the change is relevant to a (government) database node 11-16, it will also be notified immediately. If an actor node 21-27 currently has access to changed or added data via an actor permission 7c, that actor node 21-27 will also be immediately notified. This way it is guaranteed that all parties involved are working with the current data at all times.

Access to platform 1 for the different participants, such as owner 7, actors, and government agencies, can be arranged in different ways.

Without limiting the invention, this can be done, for example, via user interface on a web browser, program, or application on a computer, tablet, or smart phone. The platform 1 can be implemented as a SaaS application. The platform 1 itself may comprise one or more servers, for example with processing units to carry out certain steps. The distributed ledger is distributed across different servers of the different administrators.

Fig. 2b schematically illustrates an Embodiment in which the managers of the ledger are divided into different categories. In the figure there are two managers 720, 72b of a first category, three managers 73a, 73, 73c of the second category, four managers 74a, 74b, 74c, 74d of a third category, and two managers 750, 75b of a fourth category. displayed. However, it will be understood that in practice there may be more administrators per category. Each category of administrators has different rights regarding what data can be managed via a sub-ledger. In this example, administrators 72a-b can manage data 51-53 in subledger 81. The administrators 73a-c can manage the data 53-56 in sub-ledger 82. The administrators 74a-d can manage data 56-62 in subledger 83. The administrators 75a-b can manage the data 58-59 in subledger 84. It will be understood that Fig. 2b is only a schematic illustration, and other divisions of categories and data are possible. It will also be appreciated that although only one ledger block 5 is shown in Fig. 2b, in practice the data of each

23 BE2022/5732 ledger clock 5 in the distributed ledger is distributed in the same way between the categories.

What data each category can manage can be determined depending on the category. In practice, it is possible that a number of the managers are also actors in a real estate transaction. Certain actors anyway have access to certain data, outside of platform 1 itself, for example because of their profession. For example, a category of administrators can be those actors, and they can manage the relevant data.

Fig. 3 schematically illustrates a possible course of a real estate transaction of a real estate object, using a platform as illustrated in the previous figures. In particular, the data sharing platform is used.

The process begins with a step 200 in which an owner decides to execute the property transaction. As an example, the real estate transaction is the sale of a house. In step 201 the owner chooses a real estate agent. As an actor, the real estate agent has access to platform 1 via a real estate agent node. The owner gives the real estate agent an actor authorization 7c. This allows the real estate agent to view the data on the ledger block 5 associated with the real estate object (in this case the house).

In step 202 a valuation of the real estate object is carried out. For such a valuation, use can also be made of the platform 1. In particular, various data stored on the ledger block 5 can be used for this.

In step 203 the real estate agent checks the sales file. For example, the real estate agent will check whether all required data (documents) are present and whether their validity period has not yet expired. If certain data is missing or has expired, the action to be taken may depend on the type of document. Whenever possible, platform 1 will be used to request data from a database via a (government) database node. If necessary, the owner may provide government authorization for this. For example, if a new inspection needs to be carried out, a relevant inspection body will be contacted, optionally via an inspection body node. The inspection body can then carry out the inspection

24 BE2022/5732, and provide a renewed inspection certificate as actor-provided data to platform 1.

When the sales file is complete, the presentation to the market takes place in step 204. Unlike steps 201-203 which were performed privately, the subsequent steps are public. When presenting the market, interested parties as potential buyers are given access to the sales file. In particular, they can access data on ledger block 5. This can be done in several ways. A first option is that they can view the data via the real estate agent and thus the vasigoedmakelaar node. A second option is that they also receive actor permission 7c and access the data via a buyer node in the actor layer.

In step 205, an offer from a potential buyer is then accepted by the owner. This may of course be preceded by negotiation. After the offer is accepted, the purchasing party will sign an offer promise in step 206. This normally involves a notary, who at that time also gains access to the ledger block 5 via his notary node via an actor permission 7c.

The sales agreement is then drawn up and checked in step 207 and signed by the parties in step 208. In step 209 a check of the pre-emption rights takes place, which is preferably done via platform 1. For this purpose, platform 1 can connect to a government database node that contains a database with preemption data. If there are no pre-emption rights or if pre-emption rights are not used, the deed will be signed by the parties in step 210. In step 211 the transfer of ownership is finally registered, which again takes place via platform 1. The notary can provide this as actor-provided data via his notary node.

The platform will adjust the ledger block 5 and assign it to the new owner.

The general ledger layer will also inform the relevant government agencies, so that, for example, the database of the quay ray register node is adjusted.

It will be appreciated that in some cases the method may perform additional steps or omit steps shown in Figure 3. The steps to be taken depend, among other things, partly on local legislation and may differ depending, for example, on the location of the real estate object.

25 BE2022/5732

As required, detailed embodiments of the present invention are described herein

Invention described; However, it should be understood that the disclosed embodiments are merely an example of the invention, which can be embodied in various forms. Therefore, specific structural and functional details disclosed herein should not be construed as limiting, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art to variously apply the present invention in virtually any suitably detailed structure. Not all described objectives have to be achieved with special embodiments.

Furthermore, the terms and expressions used herein are not intended to limit the invention, but rather to provide an understandable description of the invention. The word "one" used herein means one or more than one unless otherwise stated. The terms "a multiple of" or "several" means two or more than two. The words "comprise", "contain", and "have" have an open meaning and do not exclude the absence of additional elements.

Reference numbers in the claims are not to be interpreted as limiting the invention.

The mere fact that certain technical features are described in several dependent claims still allows the possibility that a combination of these technical measures can be applied with advantage.

A single processor or other unit may perform the functions of several components mentioned in the description and claims, e.g. of processing units or control units. Any communication between components can be wired or wireless according to known methods.

The method according to the invention can be implemented as a program, for example a computer program, software application, or the like. The program can be executed using computer-readable instructions. The program may include a subroutine, a function, a procedure, an object method, an object implementation, an executable application, a source code, an object code, a shared library/dynamic loading library, and/or other set of instructions designed for execution on a computer system.

A computer program or computer-readable instructions can be stored and/or distributed on a suitable medium, such as an optical

26 BE2022/5732 storage medium or a solid-state medium that is supplied together with or as part of other hardware, but can also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems.

Claims (15)

27 BE2022/5732 CONCLUSIONS 1. A distributed ledger real estate transaction platform, the platform comprising: e a database layer configured to interface a plurality of database nodes each comprising a database, the database nodes comprising at least two government database nodes whose database is managed by a government agency; e a ledger layer, comprising multiple ledger blocks, each with a unique block code, wherein the ledger blocks are stored in a distributed ledger, wherein e each ledger block is assigned to an associated real estate object:; e each ledger block has an owner; e the ledger layer is configured to e connect to the government database nodes to request official data related to a real estate object; e store a unique document code linked to the official data on the ledger block associated with the real estate object; e receive storage instructions from the owner as to whether or not to store the official data on the ledger block; e receive actor permissions from the owner; e an actor layer, comprising multiple actor nodes configured to, grant an actor access to at least some of the official data on the real estate block after the ledger layer receives an appropriate actor permission from the owner. The platform of claim 1, wherein the actor layer is configured to receive actor-provided data from the actor, wherein the actor-provided data relates to a planned or occurred adjustment to the official data, wherein the platform is further configured to inform the government database node of the adjustment based on the actor-provided data. 28 BE2022/5732 The platform of claim 1 or claim 2, wherein the ledger layer is configured to receive government permissions from the owner, and to access the official data using the government permissions when connecting to the government database nodes. 4. The platform according to any one of the preceding claims, wherein the ledger layer is further configured to query database data from a database of a database node and store it on the ledger block, and wherein the platform is configured to adjust this database data on the ledger block and in the database based on actor-provided data. The platform according to any one of the preceding claims, wherein the distributed ledger is configured to be managed by multiple administrators, the administrators being divided into different categories with different rights regarding what data can be managed. 6. The platform according to one or more of the preceding claims, configured to manage access to data of a ledger block for an actor with a smart contract. 7. The platform according to one or more of the preceding claims, configured to manage access to official data from the database of the government database nodes with a smart contract. 8. The platform of any one of the preceding claims, wherein the ledger layer is configured to receive a publishing authorization from the government agency to make the official data public, and configured to add the official data to the ledger block only after receiving the publish permission and/or configured to make the official data available to an actor node only after receiving the publish permission. 9. The platform according to one or more of the preceding claims, wherein the distributed ledger is a blockchain, wherein the unique block codes of the ledger blocks are hash codes. The platform according to any one of the preceding claims, wherein the ledger layer is configured to generate a new ledger block when data on an existing ledger block is modified or 29 BE2022/5732 can be added, where the new general ledger block has a new block code, one where the new general ledger block is linked to the existing general ledger block by means of the block code of the existing general ledger block. 11. The platform according to one or more of the preceding claims, wherein the database layer comprises one or more of the following government database nodes: e a quay register node, comprising a database with patrimonial data, for example managed by a federal government; e an urban planning node, comprising a database with urban planning data, for example managed by a provincial or municipal government; e a pollution database node, comprising a database with pollution data, for example managed by the government. The platform according to one or more of the preceding claims, wherein the database layer comprises one or more of the following database nodes: e a surveyor node, comprising a database with surveyor data; e an inspection body node, comprising a database with inspection data, where the inspection data may, for example, relate to one or more of: energy performance of the real estate object, asbestos data of the real estate object, a boiler or fuel oil tank placed in the real estate object, electrical installation ; 13. The platform according to any one of the preceding claims, wherein the actor layer comprises one or more of the following actor nodes: e a real estate agent node, configured to provide a real estate agent with access to data to sell the real estate object or rent out; e a notary node, configured to allow a notary to access data to facilitate the transfer of ownership of the real estate object; e a lender node, configured to allow a lender to access data to grant credit related to the property; 30 BE2022/5732 e a surveyor node, configured to give a surveyor access to surveyor data, and optionally give the surveyor permission to modify the surveyor data; e an inspection body node, configured to give an inspection body access to inspection data, and optionally to give the inspection body permission to adjust the inspection data, where the inspection data can, for example, relate to one or more of: energy performance of the real estate object, asbestos data of the real estate object, a boiler or fuel oil tank installed in the real estate object, electrical installation; e a site description node, configured to allow a site description expert to access site description data, and optionally to allow the site description expert to modify the site description data; e a buyer node, configured to give a potential buyer access to data relevant to making a purchasing decision. 14. A Software as a Service (Saas) application, comprising the platform according to one or more of the preceding claims. 15. A method for sharing data, wherein the method comprises a step of using the platform according to one or more of the preceding claims.