WO2019081015A1

WO2019081015A1 - Universally named locations

Info

Publication number: WO2019081015A1
Application number: PCT/EP2017/077362
Authority: WO
Inventors: Emanuele FRANCIONI; Fulvio VENTURELLI
Original assignee: Nanto B.V.
Priority date: 2017-10-25
Filing date: 2017-10-25
Publication date: 2019-05-02
Also published as: EP3701446A1

Abstract

A method for naming locations. Geographical coordinates of a geographical location are converted into a geohash, wherein the geohash defines a cell, i.e. a square geographical area comprising the geographical location. The geohash is split in three or more geohash parts. Each geohash part is converted into a decimal number, wherein the decimal number represents an index of a word in a dictionary. For each decimal number the corresponding word is obtained from the dictionary, thereby obtaining a set of three or more words, wherein the set of words forms a unique identification of the cell. The cell may be named by registering a cell name to the cell. The method may be performed on a blockchain, such as Ethereum, and data may be stored on the blockchain.

Description

UNIVERSALLY NAMED LOCATIONS

TECHNICAL FIELD

[0001] The invention relates to a computer-implemented method for naming locations. The invention further relates to a data processing device, a computer program product and a computer-readable non-transitory storage medium related to the computer- implemented method.

BACKGROUND ART

[0002] The geographical coordinate system used for maps is typically based on latitude and longitude to represent the position of a point on the Earth's surface, and meridian and parallels to join points with the same latitude (parallels) and longitude (meridians). Latitude is the angle between the equatorial plane and the straight line that passes through the point and through the center of the Earth. Longitude is the angle east or west of a reference meridian (i.e. Greenwich) to another meridian that passes through that point.

[0003] A location address is a method to identify a destination, house or building, generally using political boundaries and street names as references. To help identification and aiding the delivery of mail, most countries use a postal code system.

[0004] The geographical systems mentioned above both have important limitations that prevent them from being thoroughly effective.

[0005] Geographic coordinates have properties of arbitrary precision at the expense of simplicity - for instance, the coordinates 41.9022033 N, 12.4554384 E indicate the entrance of St. Peter's Basilica in the Vatican City. Expressing locations in terms of geographic coordinates are hard to remember given the challenges they pose for humans in terms of readability and communicability, making it a poor choice for e.g. delivering parcels.

[0006] The choice of using location address (e.g. Piazza San Pietro, 00120 Citta del Vaticano, Vatican City) instead of the geographical location may solve the human readability problems but present several other problems: (i) unpredictability: Location addresses are unordered (knowing your current location does not help orientation); (ii) incompleteness: Most locations are left unaddressed. Even in urban areas, locations are left unmapped (e.g. in city parks, rivers or even between adjacent buildings on the same road); (iii) inconsistencies: Location Addresses are different from country to country; (iv) unreliability: Rural areas often present stale addresses of buildings; (v) inefficiency: Street names are redundant and duplicated from city to city, hence the whole address needs to be used for meaningful location resolution (i.e. Johan Huizinglaan 400 is meaningless without specifying the city or the postcode).

[0007] There is a need for an improved identification system for locations.

SUMMARY

[0008] The present invention proposes a universally named locations (UNL) technology that aims to solve the limitations of the current systems, by providing a solution that can be: (i) global: the system can work on a global scale, covering oceans, mountains, cities and rural areas; (ii) indoor: principally all walkable locations can be addressed; (iii) decentralized: The platform can be deployed using blockchain

technology, for example under the form of a Smart Contract on the Ethereum Blockchain, offering unprecedented reliability; (iv) effective: Landmarks can be precisely identified with an easy combination of three (or more) words, a OR Code or a custom keyword.

[0009] According to an aspect of the invention, a computer-implemented method is proposed for naming locations. The method can comprise converting geographical coordinates of a geographical location into a fixed length string of alphanumeric characters. The converting of the geographical coordinates can be based on a geohashing function and the fixed length string can be a geohash. The geohash can define a cell, wherein the cell can be a square geographical area comprising the geographical location. The method can further comprise splitting the geohash in three or more geohash parts. The method can further comprise converting each geohash part into a decimal number, wherein the decimal number can represent an index of a word in a dictionary. The method can further comprise obtaining for each decimal number the corresponding word from the dictionary, thereby obtaining a set of three or more words, wherein the set of words forms a unique identification of the cell.

[0010] In an embodiment, the method can further comprise receiving a further set of further words. The method can further comprise obtaining for each further word a corresponding further decimal number using the dictionary. The method can further comprise converting each further decimal number into a further geohash part. The method can further comprise merging the further geohash parts to obtain a further geohash. The method can further comprise converting the further geohash into further geographical coordinates of a further geographical location, wherein the converting of the further geohash is based on an inverse geohashing function.

[0011] In an embodiment, the method can further comprise a registration of a cell name to the cell. The method can further comprise verifying the availability of the cell for naming in a registry. The method can further comprise, if the cell is available, registering in the registry the cell name to the cell by saving the cell name together with the geohash of the cell and/or the set of words indicative the cell.

[0012] In an embodiment, the cell name can be indicated as a data string starting with an 'at' character ("@").

[0013] In an embodiment, in case the cell is not available for naming, a conflict resolution process can be performed involving multiple users to decide if the cell may be registered with the cell name.

[0014] In an embodiment, the method can further comprise receiving a further cell name. The method can further comprise obtaining a geohash or a set of words

corresponding to the further cell name from the registry. The method can further comprise converting the obtained geohash or set of words corresponding to the further cell name into further geographical coordinates.

[0015] In an embodiment, the method can further comprise a registration of a gate name to the cell. The gate name can be indicative of a human accessible other cell having the same gate name. The method can further comprise registering in the registry the gate name to the cell by saving the gate name together with the cell name.

[0016] In an embodiment, the gate name can be indicated as a data string starting with a 'hash' character ("#").

[0017] In an embodiment, the method can further comprise providing a navigation system. A destination address can be provided as a destination cell name. A navigation route via multiple cells can be determined from a starting cell name to the destination cell name using one ore more linked gate names or a gate name linked to a cell name. Herein the term linked means that the name is the same.

[0018] In an embodiment, the method can be implemented using a blockchain, such as Ethereum, and one or more of the steps of the method can be performed on the blockchain. [0019] In an embodiment, the steps of the method can be performed in a

Decentralized Smart Contract State Storage.

[0020] In an embodiment, the dictionary can be stored on the blockchain.

[0021] In an embodiment, the dictionary can be stored in a Decentralized Dictionary Storage.

[0022] In an embodiment, data from the dictionary can be retrievable from the Decentralized Dictionary Storage by the Decentralized Smart Contract State Storage.

[0023] In an embodiment, the cell names can be stored on the blockchain.

[0024] In an embodiment, the cell names can be stored in the registry on the

Decentralized Registry Storage.

[0025] In an embodiment, data from the registry can be retrievable from the

Decentralized Registry Storage by the Decentralized Smart Contract State Storage.

[0026] In an embodiment, the method may be implemented as a decentralized autonomous organization (DAO). The DAO is an organization that is run through rules encoded as computer programs, e.g. smart contracts on the Ethereum blockchain. DAO's financial transaction record and program rules are maintained on the blockchain. The general concept of a DAO is that of a virtual entity that has a certain set of members or shareholders which, e.g. with a majority (e.g. a 67% majority), have the right to spend the entity's funds and/or modify its code. As a result there is no central ownership of the UNL technology, platform and services and UNL may become a de-facto standard that may be used by anyone.

[0027] According to an aspect of the invention, a data processing device is proposed comprising a processor configured to perform one or more of the above described steps.

[0028] According to an aspect of the invention, a computer program product is proposed, implemented on a computer-readable non-transitory storage medium, the computer program product comprising computer executable instructions which, when executed by a processor, cause the processor to carry out one or more of the above described steps.

[0029] According to an aspect of the invention, a computer-readable non-transitory storage medium is proposed comprising computer executable instructions which, when executed by a processor, cause the processor to carry out one or more of the above described steps. [0030] Hereinafter, embodiments of the disclosure will be described in further detail. It should be appreciated, however, that these embodiments may not be construed as limiting the scope of protection for the present disclosure.

BRIEF DESCRIPTION OF DRAWINGS

[0031] Embodiments will now be described, by way of example only, with reference to the accompanying schematic drawings in which corresponding reference symbols indicate corresponding parts, and in which:

[0032] FIG. 1 shows an exemplary grid cell with a UNL name;

[0033] FIG. 2 shows an exemplary routing example based on UNL;

[0034] FIGs. 3-9 show exemplary time sequence diagrams of UNL processes on a blockchain based decentralized platform

[0035] The figures are meant for illustrative purposes only, and do not serve as restriction of the scope or the protection as laid down by the claims.

DESCRIPTION OF EMBODIMENTS

[0036] The invention provides for universally named locations (UNL), which may be global, decentralized, Web 3.0 powered virtual markers that univocally identify squares of land on the Earth's surface and indoor spaces, named UNL cells.

[0037] The UNL solution may have a layered structure, wherein higher layers make use of functionality provided by lower layers, similar to an open systems interconnection (OSI) model. Layer 1 may deal with the conversion of geographical coordinates into words. Layer 2 may deal with custom naming of grid cells. Layer 3 may deal with routing (e.g. indoor navigation, involving gates and linking of grid cells). Layer 4 may deal with private or institutional navigation/supply chain. Layer 5 may deal with personal locator and location-based services.

[0038] At layer 1, the default identification of UNL cells may be geohashes: a set of alphanumeric characters that describe a UNL cell in terms of its geolocation and size. Geohashes offer properties like arbitrary precision and the possibility of gradually removing characters from the end of the code to reduce size. Geohashes can be encoded into a number of convenient representations such as unique and human readable word combination or QR Code.

[0039] By limiting geohashes to 9 characters, the Earth can be divided into a grid of 4.8m UNL Cells, uniquely identifiable with a combination of three words. Note that it is possible to use more than three words, but it has been found that three words are sufficient to globally uniquely identify any UNL cell. In addition to the default identification system, the platform may support custom naming of every land square. Such, it is possible to give a square its own custom keyword, which will allow direct reverse geocoding of such words to the relevant geographic coordinates.

[0040] As an example, FIG. 1 shows how the @rookyrecords keyword is mapped to the grid tile where the entrance of the shop is located. The 4.8m indicated by the arrow is thus named with the keyword "@rookyrecords", the location of which is identifiable by the unique combination of three words "wood", "house" and "hotel". These three words may be presented in a QR Code format, such as shown in FIG. 1, to allow scanning of the address by barcode scanners.

[0041] The conversion process of a geographical address to three words starts by converting the geographical coordinates of the location to a geohash truncated to the most relevant nine alphanumeric characters. For example 41.902203N, 12.455438E is geohashed into "sr2y7kjf08z9" and truncated to "sr2y7kjf0". The truncated geohash "sr2y7kjf0" achieves a 4.8 square meter precision on the UNL grid. The resulting geohash is then split in 3 character groups "sr2", "y7k" and "jfO" and each group is converted into a decimal number by doing a custom Base32 conversion. For example "sr2" is Base32 converted into "37262", "y7k"is Base32 converted into "44336" and "jfO" is Base32 converted into "25164".

[0042] The three decimal numbers obtained with the Base32 conversion represent a word index in a preset words dictionary, e.g. containing 32767 words, which is then returned as a result.

[0043] The alphabet used in the custom Base32 conversion may be based on the following sequence: O123456789bcdefghjkmnpqrstuvwxyz'. Using this alphabet, the following function may be used to encode and decode geohash slices into a word index and vice versa, such as this JavaScript implementation: function geohashToWord (value , action) {

action == 'decode' ? (from_base=10,to_base=32 ) : (from_base=32,to_base=10); var range = O123456789bcdefghjkmnpqrstuvwxyz'.split(");

var from_range = range. slice(0, from_base);

var to_range = range. slice(0, to_base); var dec_value = value. split(").reverse().reduce(function(carry, digit, index) { return carry += from_range.indexOf (digit) * (Math .pow(from_base, index));

}, 0 );

var new_value = ";

while (dec_value > 0 ) {

new_value = to_range[dec_value % to_base] + new_value;

dec_value = (dec_value - (dec_value % to_base)) / to_base;

}

return new_value 11 0;

}

[0044] The dictionary used to mark the UNL cell with a three word combination may have a 32767 words selection, which can represent the full Base32 geohash chunk range from 000 to zzz . To build such dictionary, a list of the 100000 most used English words may be used, ordered by popularity. These words may be filtered by picking all words between 4 and 8 letters in length and filtering out any insult, curse or bad words, based on the publically available lists like https://github.com/reimertz/curse-words,

https://github.com/MauriceButler/badwords and https://github.com/LDNOOBW/List-of- Dirty-Naughty-Obscene-and-Otherwise-Bad- Words. Furthermore, words that could potentially make users feel uneasy may be removed from the list. After the filtering, the top 32767 entries may be selected from the final list. Such filtering process and build of the dictionary may be fully automated using a script.

[0045] At layer 2, the UNL platform may have the capability to allow, together with the default identifications, the possibility to give any grid cell its own custom name. All cell names are unique (like domain names). For example, the owner of the Grizzly

Records Music shop might want to give the grid cell marking the entrance of the store the name of the shop itself, for example @GrizzlyRecords, similar to the example shown in FIG. 1. When customers need to know where the store is located, all they have to do is a lookup for the keyword @GrizzlyRecords in the UNL system.

[0046] Al layer 3, the UNL platform may have the capability to have a native routing system for indoor areas, or location where an entrance must be reached before the final destination. To achieve this, a grid cell can be marked as a gate (as well as a destination). Gates (which may be marked with the hash symbol) are cells that other grid squares link to, to indicate that to reach one cell, the person must first go through that gate.

[0047] In the example of FIG. 2, the top two cell grids are named @Paul and @Rick. These two locations are final addresses, reachable directly without going through other landmarks. Considering the area below, zone I represents an office tower, with the entrance marked as #DuffTower. Let's assume we want to deliver a parcel at Jim's Desk (the grid cell marked @JimDesk). We see the location of that cell, and that the gate to get there is the cell marked #TheOffice - which is also a destination (@TheOffice) since there is probably a reception there, who can collect packages. On the cell marked

@TheOffice, we see that the gate to get there is #DuffTower. So, to reach @JimDesk I have to go first to the #DuftTower entrance, then #TheOffice, then @Jimdesk. This enables quick, human readable routing in enclosed areas and buildings. Note that in FIG. 2 the cell sizes are not drawn to scale; typically all cells are equal in size.

[0048] At layer 4, the UNL platform may offer the possibility to use the platform' s location capabilities in a private chain by using QR coded geohashes attached to the parcels instead of the usual hand written address or barcode. This procedure could ensure prompt delivery of any package, even in rural areas or zones with no physical address, like delivering a crate of wine bottles to a yacht temporarily stationed in a port, or shipping an online order to a cabin in the forest. Furthermore, logistic organizations that can monitor resources from raw material to end-user using a combination of geohashes and custom cell naming. Instead of using shelf -numbers or stockroom numbers and rows, the entire supply chain can be organized by mapping the warehouse using UNL Cells with custom naming.

[0049] At layer 5, the UNL platform may link users to a cell (possibly at every time), through a dedicated app or by detecting the presence of the user at certain UNL gates. This could enable delivering content to a person immediately without specifying a physical address. A concrete example is to have the user place an order online, and having a "Send it to Me" option together with all the addresses he currently has registered on that site. The option would send the package to the location where the user is staying now, without having him enter a new address for new places he might visit.

[0050] The UNL platform may be a decentralized Web 3.0 application without a physical owner of any grid cells. People may be able to associate a custom name to a cell by paying an associated Geotoken cost, and may be given the opportunity to renew such service every year. The owner of the custom name on a grid may also be able to: (i) Receive offers from other platform users in regards to buying the naming of that cell; (ii) Auction off the cell to sell the right of using a custom keyword on it; (iii) Release the cell in case of a change of address, and move the name to another cell. All these services may be embedded in the UNL smart contract based on Ethereum. Ethereum will be further described below.

[0051] The UNL platform may provide the ability to embed custom meta data on a cell. This can be any custom plain or encrypted data that can be attached as payload on the grid cell itself. Typical use would be, for example, to identify parking area IDs, the names of people currently living in an apartment, the cost of rental of a house, and so on.

[0052] UNL may use Ethereum Swarm in order to permanently store metadata information on the blockchain. Ethereum Swarm is a technology embedded into

Ethereum core, which enables persistent storage of data on the blockchain.

[0053] In order to move the naming of a cell to another, the user may release the cell. Releasing the cell may require the following criteria: (i) The user must own the right of naming on that cell for minimum of e.g. 6 months; (ii) The cell selected to receive the naming update must be free (otherwise there may be a conflict resolution). The operation will also move any metadata associated with the cell.

[0054] If the user selects to move the naming on a cell already claimed by someone else, the user may be required to prove they own the right to move on to that cell in order for the operation to be successful. This may be done through a conflict resolution process. To initiate such conflict resolution process, the moving user may have to provide a utility bill, not older than e.g. 1 month, to the smart contract, together with the moving request. The bill may go through a system that detects any tampering done with image

manipulation software, and it may then be forwarded to a number of (e.g. 50) platform users, which will have to confirm that the requesting user and address match. If there is community consensus, the old owner may be notified of the request, and if they do not reply within e.g. 2 weeks, they maybe refunded of any remaining time they had on the cell, and the move may take place. If they do reply, and provide their own utility bill, the community may vote on who should own the cell naming for the following e.g. two weeks, and may assign a winner afterwards. Participating in community voting and resolutions may reward members with Geotoken coins. [0055] The UNL system may advantageously be used as a next generation addressing system that unifies the precision of a geographic coordinate system to the simplicity and readability of a location address. The platform may provide unprecedented benefits to people living in rural areas, delivery men, companies involved in

transportation and logistics.

[0056] The metadata function of the platform may make it invaluable for logistics and warehouse administration. To date there is no system that will give the possibility to universally store item locations on a global scale. With UNL, it will be possible to know exactly, in a storage area, what is where.

[0057] With delivery, right now, companies have to rely on local addresses in order to deliver goods. This is highly unpractical, since addresses and geo coordinates are not linked together. Food delivery businesses have integrated clumsy and unnecessary steps into their order pipeline to help deliveries get to their clients in time. With UNL, postmen and parcel couriers will not only be able to know exactly where their destination is located, but they will also have immediate information about where to head in large buildings, thanks to the native indoor routing, such as visualized in FIG. 2, embedded in the UNL platform.

[0058] Shops and companies will have the chance to use the UNL platform as an innovative marketing tool. The UNL keyword can be integrated in websites, marketing campaigns, promotional emails, pamphlets and much more, becoming both a helpful tool for the end customer and an advertisement opportunity for the business. The extreme conciseness of the data representing the cell, allows for micro-QR encoding, an ideal choice when faced with the need to print on different media.

[0059] While road mapping has seen a dramatic improvement over the last century, drivers still face the challenge to reach their destination in rural areas, or zones with low mapping coverage, especially when having to rely on local addresses. With UNL mapping, everywhere in the world, ocean, desert, mountain or city, is universally geolocated, and can be precisely identified on any map projection.

[0060] UNL may be used for smart mobility, which includes car- sharing

organizations and mobility (card) providers which draw on modern technology to monetize on the mileage travelled by their customers rather than on a vehicle's rental like the more traditional Rental and Leasing companies. [0061] Small medium businesses may use UNL. For example plumbing, trucking, independent contractors, catering, etc. all make use of a fleet of vehicles to deliver their goods or services and their competitiveness largely depends on their ability to cut costs, increase service profitability and keep their employees productive.

[0062] UNL may be used for field service management (FSM). FSM is all about timely placing the proper employee in the right location with the appropriate tools, a complex task which requires reliable solutions capable of vehicle tracking, integration with 3rd party software (ERP, CRM, etc.), communication with field employees, data analytics.

[0063] UNL may be used for third party logistics (3PL). This very competitive and growing market is fueled by a seemingly never ending increase of parcel distribution due to e-commerce sales. Thousands of providers in ferocious competition with each other seek a competitive advantage through cutting operating costs by diversifying modes of transportation and optimizing routes as well as bettering customer experience with prompt communication and message dispatching.

[0064] Governments may use UNL. The expenses of citizens commuting, the high cost of road expansion, pollution and road safety force governments to invest into reducing congestion through dynamic congestion pricing.

[0065] Insurance Companies may use UNL. Insurance is all about measuring and calculating risk. They evaluate the level of risk and then set premium rates and coverage per the measurement in question. In motor insurance vehicle usage patterns and driver behaviors are two important risk categories.

[0066] As explained above, the UNL service may be implemented on a blockchain, such as Ethereum. Ethereum is an open-source, public, blockchain-based distributed computing platform featuring smart contract (scripting) functionality. It provides a decentralized Turing-complete virtual machine, the Ethereum Virtual Machine (EVM), which can execute scripts using an international network of public nodes. Ethereum also provides a cryptocurrency token called "Ether", which can be transferred between accounts and used to compensate participant nodes for computations performed. "Gas", an internal transaction pricing mechanism, is used to mitigate spam and allocate resources on the network.

[0067] FIGs. 3-9 show exemplary time sequence diagrams of UNL processes on a blockchain based, for example Ethereum based, decentralized platform. In FIGs. 3-9 the vertical dashed lines indicate the four communicating elements, as indicated in the top of FIG. 3.

[0068] In these diagrams the UNL Backer may be a user who interacts with the UNL platform. The UNL Backer typically owns Geocoins, used to pay for specific

transactions.

[0069] The Decentralized Smart Contract State Storage may be the Smart Contract component in the Blockchain. The Decentralized Smart Contract State Storage may hold the state and code logic for the whole platform.

[0070] The Decentralized Dictionary Storage may be the dictionary component of the UNL platform, stored in the blockchain. The Decentralized Dictionary Storage may hold the indexes and words used to represent unclaimed cells using a 3-word

representation.

[0071] The Decentralized Registry Storage may be the registry component of the UNL platform, stored in the blockchain. The Decentralized Registry Storage may hold the information about custom cell naming and metadata. Where Coordinates are indicated, this means the representation of the location of a point on the Earth's surface, in terms latitude (which the angular distance north or south from the equator of a point on the earth's surface, measured on the meridian of the point) and longitude (which is the angular distance east or west on the earth's surface, measured by the angle contained between the meridian of a particular place and some prime meridian, as that of

Greenwich, England). Where Geohash is indicated, tis means a mechanism used to encode coordinates in a lossless way into an alphanumeric string, with precision defined by the length of the sting itself.

[0072] The Decentralized Smart Contract State Storage, the Decentralized Dictionary Storage and the Decentralized Registry Storage may be implemented as smart contracts.

[0073] FIG. 3 shows an exemplary process of acquiring GeoTokens. The UNL Backer may send a request for GeoTokens to the Decentralized Smart Contract State Storage, which in return may return the requested Geotokens.

[0074] FIG. 4 shows an exemplary process of getting a geohash and/or 3 words. The UNL Backer may send its coordinates to the Decentralized Smart Contract State Storage. There the geohash and the word indices may be calculated, e.g. using the adapted Base32 function in the JavaScript shown above. The Decentralized Smart Contract State Storage may request the dictionary from the Decentralized Dictionary Storage. The Decentralized Dictionary Storage may fetch the dictionary from the Ethereum nodes and return the dictionary to the Decentralized Smart Contract State Storage. There the three words may be retrieved from the dictionary using the calculated indices. The Geohash and/or the 3 words may then be sent back to the user.

[0075] Alternatively, the dictionaries may be stored at the UNL Backer. The geohash and word indices may then be locally calculated at the UL Backer and the 3 words may be derived at the UNL Backer without involving the Ethereum network. This may be beneficial in case the UNL Backer does not have a data connection and still wants to be able to present his UNL location, e.g. in case of emergency.

[0076] FIG. 5 shows an exemplary process of registering a cell with a custom name. The UNL Backer may request a name registration by sending his coordinates to the Decentralized Smart Contract State Storage. The Decentralized Smart Contract State Storage may request a cell registry with the Decentralized Registry Storage, where the registry may be fetched from Ethereum nodes. The registry may be sent back to the smart contract, and the smart contract may check the cell availability. If the cell is available, the OK Flow may be followed, wherein the cell registry may be updated and saved in the registry. After confirmation, a Geotoken may be transferred to the corresponding smart contract wallet, and the cell registration may be confirmed to the UNL Backer. If the cell is not available, the NOT OK Flow may be followed, wherein the non- availability may be reported back to the UNL Backer.

[0077] FIG. 6 shows an exemplary process of reverse geocoding of a geohash. The UNL Backer may sent a geohash to the Decentralized Smart Contract State Storage, where the coordinates of the geohash may be calculated. The coordinates may then be sent back to the UNL Backer.

[0078] The process of FIG. 6 may alternatively be performed outside the blockchain.

[0079] FIG. 7 shows an exemplary process of reverse geocoding of three words. The UNL Backer may sent a set of three words to the Decentralized Smart Contract State Storage. The Decentralized Smart Contract State Storage may request the dictionary from the Decentralized Dictionary Storage. The Decentralized Dictionary Storage may fetch the dictionary from the Ethereum nodes and return the dictionary to the Decentralized Smart Contract State Storage. There the geohash may be calculated from the three words using the dictionary and the coordinates may be calculated from the geohash. The coordinates may be sent back the UNL Backer. [0080] FIG. 8 shows an exemplary process of reverse geocoding a custom name. The UNL Backer may sent the custom name cell to the Decentralized Smart Contract State Storage. The Decentralized Smart Contract State Storage may request the cell registry from the Decentralized Registry Storage. The Decentralized Registry Storage may fetch the registry from the Ethereum nodes and return the registry data. The Decentralized Smart Contract State Storage may retrieve the cell geohash from the registry data and calculate the coordinates from the geohash. The geohash may then be sent back to the UNL Backer.

[0081] FIG. 9 shows an exemplary process of acquiring an already claimed cell. The UNL Backer may request the acquisition of an owned cell. The request may include the geohash and the transaction request. The Decentralized Smart Contract State Storage may request the cell registry from the Decentralized Registry Storage. The Decentralized Registry Storage may fetch the registry from the Ethereum nodes and return the registry data. The Decentralized Smart Contract State Storage may retrieve the cell owner from the registry data. A conflict resolution process may then be performed, wherein community member consensus is requested, e.g. as explained above. The outcome of the conflict resolution process may be notified to all the involved parties, including the UNL Backer. If the acquisition is granted, the cell registry may be updated by sending a new cell registry to the Decentralized Registry Storage, where the registry update is saved and confirmed. The Decentralized Smart Contract State Storage may transfer a Geotoken to the corresponding Smart Contract Wallet and the cell acquisition may be confirmed to the URL Backer.

[0082] Ethereum, taken as a whole, can be viewed as a transaction-based state machine. The state can include such information as account balances, reputations, trust arrangements, data pertaining to information of the physical world; in short, anything that can currently be represented by a computer is admissible. Transactions are collated into blocks; blocks are chained together using a cryptographic hash as a means of reference. Blocks function as a journal, recording a series of transactions together with the previous block and an identifier for the final state (though do not store the final state itself - that would typically be far too big). They also punctuate the transaction series with incentives for nodes to mine. This incentivisation takes place as a state-transition function, adding value to a nominated account. [0083] Mining is the process of dedicating effort (working) to bolster one series of transactions (a block) over any other potential competitor block. It is achieved thanks to a cryptographically secure proof.

[0084] This is the basis of the blockchain paradigm, a model that forms the backbone of not only Ethereum, but all decentralized consensus-based transaction systems to date. Since the Ethereum system is decentralized and all parties have an opportunity to create a new block on some older pre-existing block, the resultant structure is a tree of blocks. In order to form a consensus as to which path, from root (the genesis block) to leaf (the block containing the most recent transactions) through this tree structure, known as the blockchain, there must be an agreed-upon scheme. If there is ever a disagreement between nodes as to which root-to-leaf path down the block tree is the 'best' blockchain, then a fork occurs. This would mean that past a given point in time (block), multiple states of the system may coexist: some nodes believing one block to contain the canonical transactions, other nodes believing some other block to be canonical, potentially containing radically different or incompatible transactions. This is to be avoided as the uncertainty that would ensue could undermine the confidence in the entire system. The scheme Ethereum uses in order to generate consensus is a simplified version of the GHOST protocol.

[0085] The canonical blockchain is a path from root to leaf through the entire block tree. In order to have consensus over which path it is, conceptually the path is identified that has had the most computation done upon it, or, the heaviest path. Clearly one factor that helps determine the heaviest path is the block number of the leaf, equivalent to the number of blocks, not counting the unmined genesis block, in the path. The longer the path, the greater the total mining effort that must have been done in order to arrive at the leaf. This is akin to existing schemes, such as that employed in Bitcoin-derived protocols. Since a block header includes the difficulty, the header alone is enough to validate the computation done. Any block contributes toward the total computation or total difficulty of a chain.

[0086] In order to incentivize computation within the network, Ethereum has been developed under the assumption that there needs to be an agreed method for transmitting value. To address this issue, Ethereum has an intrinsic currency, Ether, known also as ETH and sometimes referred to by the Old English D. The smallest sub-denomination of Ether, and thus the one in which all integer values of the currency are counted, is the Wei. One Ether is defined as being 1018 Wei. The sub-denominations of Ether are: 100 multiplier is called Wei, 10 12 multiplier is called Szabo, 1015 multiplier is called Finney, and 10 18 multiplier is called Ether.

[0087] In Ethereum, the world state (state), is a mapping between addresses (160-bit identifiers) and account states (a data structure serialized as RLP). Though typically not stored on the blockchain, it is assumed that the implementation will maintain this mapping in a modified Merkle Patricia tree, also known as trie. The trie requires a simple database backend that maintains a mapping of byte arrays to byte arrays; this underlying database is called the state database. This has a number of benefits; firstly the root node of this structure is crypto graphically dependent on all internal data and as such its hash can be used as a secure identity for the entire system state. Secondly, being an immutable data structure, it allows any previous state (whose root hash is known) to be recalled by simply altering the root hash accordingly. Since typically all such root hashes are stored in the blockchain, it is possible to trivially revert to old states.

[0088] In Ethereum, the account state comprises the following four fields: (i) Nonce: a scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account; (ii) balance: A scalar value equal to the number of Wei owned by this address; (iii) storageRoot: A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values; and (iv) codeHash: The hash of the EVM code of this account - this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after

construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval.

[0089] An Ethereum transaction is a single cryptographically-signed instruction constructed by an actor externally to the scope of Ethereum. While is assumed that the ultimate external actor will be human in nature, software tools will be used in its construction and dissemination. There are two types of transactions: those which result in message calls and those which result in the creation of new accounts with associated code (known informally as 'contract creation'). Both types specify a number of common fields: (i) nonce: A scalar value equal to the number of transactions sent by the sender; (ii) gasPrice: A scalar value equal to the number of Wei to be paid per unit of gas for all computation costs incurred as a result of the execution of this transaction; (iii) gasLimit: A scalar value equal to the maximum amount of gas that should be used in executing this transaction. This is paid up-front, before any computation is done and may not be increased later; (iv) to: The 160-bit address of the message call's recipient or, for a contract creation transaction, used here to denote the only member; (v) value: A scalar value equal to the number of Wei to be transferred to the message call's recipient or, in the case of contract creation, as an endowment to the newly created account; (vi) v, r, s: Values corresponding to the signature of the transaction and used to determine the sender of the transaction.

[0090] Additionally, a contract creation transaction contains: (i) init: An unlimited size byte array specifying the EVM-code for the account initialization procedure, 'init' is an EVM-code fragment; it returns the body, a second fragment of code that executes each time the account receives a message call (either through a transaction or due to the internal execution of code), 'init' is executed only once at account creation and gets discarded immediately thereafter. In contrast, a message call transaction contains: (i) data: An unlimited size byte array specifying the input data of the message call.

[0091] The block in Ethereum is the collection of relevant pieces of information (known as the block header ), together with information corresponding to the comprised transactions, and a set of other block headers that are known to have a parent equal to the present block's parent's parent (such blocks are known as ommers). The block header contains several pieces of information: (i) parentHash: The Keccak 256-bit hash of the parent block's header, in its entirety; (ii) ommersHash: The Keccak 256-bit hash of the ommers list portion of this block; (iii) beneficiary: The 160-bit address to which all fees collected from the successful mining of this block be transferred; (iv) stateRoot: The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalizations applied; (v) transactionsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block; (vi) receiptsRoot: The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block; (vii) logsBloom: The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list; (viii) difficulty: A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block' s difficulty level and the timestamp; (ix) number: A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero; (x) gasLimit: A scalar value equal to the current limit of gas expenditure per block; (xi) gasUsed: A scalar value equal to the total gas used in transactions in this block; (xii) timestamp: A scalar value equal to the reasonable output of Unix's time() at this block's inception; (xiii) extraData: An arbitrary byte array containing data relevant to this block. This is 32 bytes or fewer; (xiv) mixHash: A 256-bit hash which proves combined with the nonce that a sufficient amount of computation has been carried out on this block; (xv) nonce: A 64-bit hash which proves combined with the mix -hash that a sufficient amount of computation has been carried out on this block.

[0092] The other two components in the block are simply a list of ommer block headers (of the same format as above) and a series of the transactions.

[0093] In order to encode information about a transaction, it may be useful to form a zero-knowledge proof, or index and search. Hereto, a receipt of each transaction is encoded containing certain information from concerning its execution. Each receipt is placed in an index-keyed trie and the root recorded in the header. The transaction receipt is a tuple of four items comprising the post-transaction state, the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened, the set of logs created through execution of the transaction, and a Bloom filter composed from information in those logs.

[0094] The Ethereum blockchain is considered secure and a malicious node typically cannot propagate newly created blocks that would otherwise overwrite ("rewrite") history. Because the nonce must satisfy this requirement, and because its satisfaction depends on the contents of the block and in turn its composed transactions, creating new, valid, blocks is difficult and, over time, requires approximately the total compute power of the trustworthy portion of the mining peers.

[0095] In order to avoid issues of network abuse and to sidestep the inevitable questions stemming from Turing completeness, all programmable computation in Ethereum may be subject to fees. The fee schedule is specified in units of gas. Thus any given fragment of programmable computation (this includes creating contracts, making message calls, utilizing and accessing account storage and executing operations on the virtual machine) has a universally agreed cost in terms of gas. [0096] Every transaction typically has a specific amount of gas associated with it: gasLimit. This is the amount of gas which is implicitly purchased from the sender' s account balance. The purchase happens at the according gasPrice, also specified in the transaction. The transaction is considered invalid if the account balance cannot support such a purchase. It is named gasLimit since any unused gas at the end of the transaction is refunded (at the same rate of purchase) to the sender' s account. Gas does not exist outside of the execution of a transaction. Thus for accounts with trusted code associated, a relatively high gas limit may be set and left alone.

[0097] In general, Ether used to purchase gas that is not refunded is delivered to the beneficiary address, the address of an account typically under the control of the miner. Transactors are free to specify any gasPrice that they wish, however miners are free to ignore transactions as they choose. A higher gas price on a transaction will therefore cost the sender more in terms of Ether and deliver a greater value to the miner and thus will more likely be selected for inclusion by more miners. Miners, in general, will choose to advertise the minimum gas price for which they will execute transactions and transactors will be free to canvas these prices in determining what gas price to offer. Since there will be a (weighted) distribution of minimum acceptable gas prices, transactors will necessarily have a trade-off to make between lowering the gas price and maximizing the chance that their transaction will be mined in a timely manner.

[0098] The execution of a transaction defines the state transition function. It is assumed that any transactions executed first pass the initial tests of intrinsic validity. These include: (i) The transaction is well-formed RLP, with no additional trailing bytes; (ii) the transaction signature is valid; (iii) the transaction nonce is valid (equivalent to the sender account's current nonce); (iv) the gas limit is no smaller than the intrinsic gas, used by the transaction; (v) the sender account balance contains at least the cost, required in up-front payment.

[0099] The execution of a valid transaction begins with an irrevocable change made to the state: the nonce of the account of the sender, is incremented by one and the balance is reduced by part of the up-front cost. The gas available for the proceeding computation is defined. The computation, whether contract creation or a message call, results in an eventual state (which may legally be equivalent to the current state), the change to which is deterministic and never invalid: there can be no invalid transactions from this point. [00100] After the message call or contract creation is processed, the state is finalized by determining the amount to be refunded from the remaining gas, plus some allowance from the refund counter, to the sender at the original rate. The Ether for the gas is given to the miner, whose address is specified as the beneficiary of the present block.

[00101] The Ethereum execution model specifies how the system state is altered given a series of bytecode instructions and a small tuple of environmental data. This is specified through a formal model of a virtual state machine, known as the Ethereum Virtual Machine (EVM). It is a quasi-Turing-complete machine; the quasi qualification comes from the fact that the computation is intrinsically bounded through a parameter, gas, which limits the total amount of computation done. The EVM is a simple stack-based architecture. The word size of the machine (and thus size of stack item) is 256-bit. This was chosen to facilitate the Keccak-256 hash scheme and elliptic-curve computations. The memory model is a simple word-addressed byte array. The stack has a maximum size of 1024. The machine also has an independent storage model; this is similar in concept to the memory but rather than a byte array, it is a word- addressable word array. Unlike memory, which is volatile, storage is non volatile and is maintained as part of the system state. All locations in both storage and memory are well-defined initially as zero. The EVM does not follow the standard von Neumann architecture. Rather than storing program code in generally-accessible memory or storage, it is stored separately in a virtual ROM interactable only through a specialized instruction. The machine can have exceptional execution for several reasons, including stack underflows and invalid instructions. Like the out-of-gas (OOG) exception, they do not leave state changes intact. Rather, the machine halts immediately and reports the issue to the execution agent (either the transaction processor or, recursively, the spawning execution environment).

[00102] Fees (denominated in gas) for using the EVM are typically charged under three distinct circumstances, all three as prerequisite to the execution of an operation. The first and most common is the fee intrinsic to the computation of the operation. Secondly, gas may be deducted in order to form the payment for a subordinate message call or contract creation. Finally, gas may be paid due to an increase in the usage of the memory. Over an account's execution, the total fee for memory usage payable is proportional to smallest multiple of 32 bytes that are required such that all memory indices (whether for read or write) are included in the range. This is paid for on a just- in-time basis; as such, referencing an area of memory at least 32 bytes greater than any previously indexed memory will certainly result in an additional memory usage fee. Due to this fee it is highly unlikely addresses will ever go above 32-bit bounds. That said, implementations must be able to manage this eventuality. Storage fees may have a slightly nuanced behavior - to incentivize minimization of the use of storage (which corresponds directly to a larger state database on all nodes), the execution fee for an operation that clears an entry in the storage may not only be waived, a qualified refund may be given; this refund is effectively paid up-front since the initial usage of a storage location costs substantially more than normal usage.

[00103] In addition to the system state and the remaining gas for computation, there are several pieces of important information used in the execution environment that the execution agent typically must provide: (i) the address of the account which owns the code that is executing; (ii) the sender address of the transaction that originated this execution; (iii) the price of gas in the transaction that originated this execution; (iv) the byte array that is the input data to this execution. If the execution agent is a transaction, this would be the transaction data; (v) the address of the account which caused the code to be executing. If the execution agent is a transaction, this would be the transaction sender; (vi) the value, in Wei, passed to this account as part of the same procedure as execution. If the execution agent is a transaction, this would be the transaction value; (vii) the byte array that is the machine code to be executed; and (viii) the block header of the present block; (ix) the depth of the present message-call or contract-creation (i.e. the number of CALLs or CREATES being executed at present).

[00104] The EVM is thus the runtime environment for contracts, also known as smart contracts, in Ethereum. The EVM is sandboxed and also isolated from the network, filesystem or other processes of the host computer system. Typically, every Ethereum node in the network runs an EVM implementation and executes the same instructions. EVMs have been implemented in C++, Go, Haskell, Java, JavaScript, Python, Ruby, Rust, and WebAssembly.

[00105] The smart contracts are deterministic exchange mechanisms controlled by digital means that can carry out the direct transaction of value between untrusted agents. They can be used to facilitate, verify, and enforce the negotiation or performance of economically-laden procedural instructions and potentially circumvent censorship, collusion, and counter-party risk. In Ethereum, smart contracts are treated as autonomous scripts or stateful decentralized applications that are stored in the Ethereum blockchain for later execution by the EVM. Instructions embedded in Ethereum contracts are paid for in ether (or more technically "gas") and can be implemented in a variety of Turing complete scripting languages.

[00106] Smart contracts are high-level programming abstractions that are compiled down to EVM bytecode and deployed to the Ethereum blockchain for execution. They can be written in Solidity (a language library with similarities to C and JavaScript), Serpent (similar to Python), LLL (a low-level Lisp-like language), and Mutan (Go-based, but deprecated).

[00107] Ethereum may be used to create a decentralized autonomous organization (DAO), sometimes labeled a decentralized autonomous corporation (DAC). A DAO is an organization that is run through rules encoded as computer programs, i.e. smart contracts. A DAO's financial transaction record and program rules are maintained on a blockchain. The general concept of a DAO is that of a virtual entity that has a certain set of members or shareholders which, e.g. with a 67% majority, have the right to spend the entity's funds and modify its code. The members would collectively decide on how the organization should allocate its funds. Methods for allocating a DAO's funds could range from bounties, salaries to even more exotic mechanisms such as an internal currency to reward work. This essentially replicates the legal trappings of a traditional company or nonprofit but using only cryptographic blockchain technology for enforcement.

[00108] A general outline for how to code a DAO is as follows. The simplest design is simply a piece of self-modifying code that changes if e.g. two thirds of members agree on a change. Although code is theoretically immutable, one can get around this and have de- facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage. In a simple

implementation of such a DAO contract, there would be three transaction types, distinguished by the data provided in the transaction: (i) [0,i,K,V] to register a proposal with index i to change the address at storage index K to value V; (ii) [l,i] to register a vote in favor of proposal i; and (iii) [2,i] to finalize proposal i if enough votes have been made.

[00109] The contract may then have clauses for each of these. It may maintain a record of all open storage changes, along with a list of who voted for them. It may also have a list of all members. When any storage change gets to e.g. two thirds of members voting for it, a finalizing transaction may execute the change. A more sophisticated skeleton may also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for Liquid Democracy- style vote delegation (i.e. anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines A's vote). This design would allow the DAO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the "current system" specialists can easily pop in and out of existence over time as individual community members change their alignments.

[00110] An alternative model is for a decentralized corporation, where any account can have zero or more shares, and e.g. two thirds of the shares are required to make a decision. A complete skeleton may involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order- matching mechanism inside the contract). Delegation may also exist Liquid Democracy- style, generalizing the concept of a "board of directors".

[00111] Ethereum may be used to create a decentralized file storage, such as a

Decentralized Dictionary Storage or a Decentralized Registry Storage as shown in FIGs. 3-9. Ethereum contracts can allow for the development of a decentralized file storage ecosystem, where e.g. individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage. Generally, such decentralized storage contract may works as follows. First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it. One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree. When a user wants to download the data, a micropayment channel protocol (e.g. pay 1 szabo per 32 kilobytes) may be used to recover the data.

[00112] A non-limiting example of a decentralized data storage system build on Ethereum is Swarm. Swarm functions as an accounting protocol that benefits from the automatic execution of smart contracts running on the EVM. Swarm is not tied to a specific storage system and may use the Interplanetary File System (IPFS), BitTorrent, or any other distributed storage protocol. [00113] For example IPFS combines a distributed hash table, an incentivized block exchange, and a self-certifying namespace. The IPFS filesystem can be accessed in a variety of ways, including via FUSE and over HTTP. A local file can be added to the IPFS filesystem, making it available to the world. Files are identified by their hashes and are distributed using a BitTorrent-based protocol. Other users viewing the content aid in serving the content to others on the network. IPFS has a name service called IPNS, a global namespace based on Public Key Infrastructure (PKI).

[00114] Swarm defines the bzz sub-protocol running on the Ethereum network. The swarm of Swarm is the collection of nodes of the Ethereum network each of which run the bzz protocol on the same network id. Swarm nodes are also connected to an Ethereum blockchain. Nodes running the same network id are supposed to connect to the same blockchain. Such a swarm network is identified by its network id which is an arbitrary integer.

[00115] Swarm allows for upload and disappear which means that any node can just upload content to the swarm and then is allowed to go offline. As long as nodes do not drop out or become unavailable, the content will still be accessible due to the

'synchronization' procedure in which nodes continuously pass along available data between each other.

[00116] Swarm defines: (i) chunks: pieces of data (max 4K), the basic unit of storage and retrieval in the swarm; (ii) hash: cryptographic hash of data that serves as its unique identifier and address; and (iii) manifest: data structure describing collections allow for url based access to content.

[00117] Herein, content is understood very broadly in a technical sense denoting any blob of data. Swarm defines a specific identifier for a piece of content. This identifier serves as the retrieval address for the content. Identifiers need to be collision free (two different blobs of data will never map to the same identifier), deterministic (same content will always receive the same identifier), and uniformly distributed.

[00118] Since hashes can be assumed to be collision free, they are bound to one specific version of a content, i.e. Hash addressing therefore typically is immutable.

[00119] Users, however, usually use some discovery and or semantic access to data, which is implemented by e.g. the Ethereum name service (ENS). The ENS enables content retrieval based on mnemonic (or branded) names, much like the DNS of the World Wide Web, but without servers. [00120] Swarm nodes participating in the network also have their own base address (also called bzzkey) which is derived as the (keccak 256bit sha3) hash of an Ethereum address, the so called swarm base account of the node. These node addresses define a location in the same address space as the data.

[00121] When content is uploaded to swarm it is chopped up into pieces called chunks. Each chunk is accessed at the address defined by its swarm hash. The hashes of data chunks themselves are packaged into a chunk which in turn has its own hash. In this way the content gets mapped to a chunk tree. This hierarchical swarm hash construct allows for merkle proofs for chunks within a piece of content, thus providing swarm with integrity protected random access into (large) files.

[00122] Swarm may implement a strictly content addressed distributed hash table (DHT). Here 'strictly content addressed' means that the node(s) closest to the address of a chunk do not only serve information about the content but actually host the data. In other words, in order to retrieve a piece of content (as a part of a larger collection/document) a chunk may reach its destination from the uploader to the storer when storing/uploading and may also be served back to a requester when retrieving/downloading. The viability of both hinges on the assumption that any node (uploader/requester) can 'reach' any other node (storer). This assumption may be guaranteed with a special network topology (called Kademlia), which offers (very low) constant time for lookups logarithmic to the network size.

[00123] With Swamp, nodes typically cache content that they pass on at retrieval, resulting in an auto scaling elastic cloud: popular (oft-accessed) content is replicated throughout the network decreasing its retrieval latency. Caching also results in a maximum resource utilization in as much as nodes will fill their dedicated storage space with data passing through them. If capacity is reached, least accessed chunks are purged by a garbage collection process. As a consequence, unpopular content will end up getting deleted. Storage insurance mechanisms may be used to protect important content from being deleted.

[00124] Swarm content access is centered around the notion of a manifest. A manifest file describes a document collection, for example a filesystem directory, an index of a database, or a virtual server. Manifests specify paths and corresponding content hashes allowing for URL based content retrieval. Manifests can therefore define a routing table for (static) assets (including dynamic content using for instance static JavaScript). This offers the functionality of virtual hosting, storing entire directories, or web(3)sites.

[00125] One or more embodiments of the disclosure may be implemented as a computer program product for use with a computer system. The program(s) of the program product may define functions of the embodiments (including the methods described herein) and can be contained on a variety of computer-readable storage media. The computer-readable storage media may be non-transitory storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non- writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive, ROM chips or any type of solid-state non-volatile semiconductor memory) on which information may be permanently stored; and (ii) writable storage media (e.g., hard disk drive or any type of solid-state random-access semiconductor memory, flash memory) on which alterable information may be stored.

Claims

1. A computer- implemented method for naming locations, comprising:

converting geographical coordinates of a geographical location into a fixed length string of alphanumeric characters, wherein the converting of the geographical coordinates is based on a geohashing function and the fixed length string is a geohash, wherein the geohash defines a cell, wherein the cell is a square geographical area comprising the geographical location;

splitting the geohash in three or more geohash parts;

converting each geohash part into a decimal number, wherein the decimal number represents an index of a word in a dictionary; and

obtaining for each decimal number the corresponding word from the dictionary, thereby obtaining a set of three or more words, wherein the set of words forms a unique identification of the cell.

2. The method according to claim 1, further comprising:

receiving a further set of further words;

obtaining for each further word a corresponding further decimal number using the dictionary;

converting each further decimal number into a further geohash part;

merging the further geohash parts to obtain a further geohash;

converting the further geohash into further geographical coordinates of a further geographical location, wherein the converting of the further geohash is based on an inverse geohashing function.

3. The method according to claim 1 or 2, further comprising a registration of a cell name to the cell by:

verifying the availability of the cell for naming in a registry;

if the cell is available, registering in the registry the cell name to the cell by saving the cell name together with the geohash of the cell and/or the set of words indicative the cell.

4. The method according to claim 3, wherein the cell name is indicated as a data string starting with an 'at' character ("@").

5. The method according to claim 3 or 4, wherein, in case the cell is not available for naming, a conflict resolution process is performed involving multiple users to decide if the cell may be registered with the cell name.

6. The method according to any one of the claims 3-5, further comprising:

receiving a further cell name;

obtaining a geohash or a set of words corresponding to the further cell name from the registry; and

converting the obtained geohash or set of words corresponding to the further cell name into further geographical coordinates.

7. The method according to any one of the claims 3-6, further comprising a registration of a gate name to the cell, wherein the gate name is indicative of a human accessible other cell having the same gate name, the method comprising:

registering in the registry the gate name to the cell by saving the gate name together with the cell name.

8. The method according to claim 7, wherein the gate name is indicated as a data string starting with a 'hash' character ("#").

9. The method according to claim 7 or 8, further comprising providing a navigation system, wherein a destination address is provided as a destination cell name, and wherein a navigation route via multiple cells is determined from a starting cell name to the destination cell name using one ore more linked gate names or a gate name linked to a cell name.

10. The method according to any one of the preceding claims, wherein the method is implemented using a blockchain, such as Ethereum, and one or more of the steps of the method are performed on the blockchain.

11. The method according to claim 10, wherein the steps of the method are performed in a Decentralized Smart Contract State Storage.

12. The method according to claim 10 or 11, wherein the dictionary is stored on the blockchain.

13. The method according to claim 12, wherein the dictionary is stored in a Decentralized Dictionary Storage.

14. The method according to claim 11 in combination with claim 13, wherein data from the dictionary is retrievable from the Decentralized Dictionary Storage by the Decentralized Smart Contract State Storage.

15. The method according to any one of the claims 10-14, wherein the cell names are stored on the blockchain.

16. The method according to claim 15, wherein the cell names are stored in the registry on the Decentralized Registry Storage.

17. The method according to claim 11 in combination with claim 16, wherein data from the registry is retrievable from the Decentralized Registry Storage by the Decentralized Smart Contract State Storage.

18. The method according to any one of the claims 10-17, wherein the method is implemented as a decentralized autonomous organization (DAO).

19. A data processing device comprising a processor configured to perform the steps of the method according to any one of the claims 1-18.

20. A computer program product, implemented on a computer-readable non-transitory storage medium, the computer program product comprising computer executable instructions which, when executed by a processor, cause the processor to carry out the steps of the method according to any one of the claims 1-18.

21. A computer-readable non-transitory storage medium comprising computer executable instructions which, when executed by a processor, cause the processor to carry out the steps of the method according to any one of the claims 1-18.