WO2020051160A1 - Spatial transaction protocol - Google Patents

Abstract

In a Spatial Transaction Protocol, spatial queries, spatial transactions, and spatial contracts are communicated in a manner suitable for a dynamic mixture of real-time, single-authority and decentralized ledgers. This allows individual spaces and authorities to interactively contract the entry, exit, and movement transactions within their domains; and for these mechanisms to be queried with resolution-appropriate fidelity and bandwidth utilization.

Description

SPATIAL TRANSACTION PROTOCOL

The present application claims priority from US provisional patent application number 62/726,312 filed Sept 3, 2018 in the name of Gabriel Rene and Toby Tremayne.

Field of the Invention

The invention relates to the field of computer communication protocols and the exchange of spatial content.

Background of the Invention

The challenge in implementing something like Industry 4.0, or controlling the movement of goods, people or traffic across land, air or sea, or validating transfer of real estate or other commodities, and documenting these events and transactions between parties, lies in the efficient querying, visualization and transactions over these objects, most vitally including validation of any changes to those objects, their locations, and their ownership.

Traditional digital communication protocols, whether for networking (e.g. TCP/IP, UDP) or transfers of content and information (such as HTTP, FTP or SMTP) typically lack even a single“spatial” dimension. In particular, they do not possess the ability to explicitly describe, query or update the specific location or position of an object within a physical or virtual space, nor include the language that relates those spatial relationships to permissions and trade contracts. The present invention achieves this through, among other things, novel applications of“smart contracting” techniques, such as the use of smart contracts not just to facilitate“commerce” in the conventional sense, but also to serve as a rule-based permissioning and

communications system. Summary of the Invention

The present invention relates generally to providing“spatial” Internet experiences to users and, more specifically, to a protocol that allows human beings and devices (including virtual entities like robots and holographic content) to interact with one another in a manner that takes into account their relative location in physical or virtual space.

Thus, according to the present invention there is provided an STP (Spatial Transaction Protocol), also referred to herein as the Hyperspace Transaction Protocol (HSTP), which can be thought of as an alternative or layer over traditional filename- based HTTP by providing for spatial querying, returning of spatial content and related information about assets, requesting changes to those assets, defining spatial permission contracts for transactions over those assets, and describing how these may be distributed and routed over a network.

The invention, thus defines a protocol enabling a decentralized consensus network for registering and transacting spatial information concerning any physical, digital or hybrid (i.e.“digital twin”) asset, comprising inter alia a cluster of graph-like databases consistently expressible in in- memory or distributed ledgers, connected via decentralized resolvers, scalable via spatial routing mechanisms, including smart contract permission standards, and assorted spatial content facilities, all organized and able to communicate via a set of spatial queries, transactions and permissions that factor in: (i) the size and shape of an asset; (ii) its geographic, celestial and/or virtual position (whether on the Earth or in relation to other related objects); (iii) its proper display resolution when reproduced digitally; (iv) any permissions that govern the behavior of the asset; and (v) in certain cases its time and frequency (either wavelength or periodicity).

HSTP uses spatial smart contracts as a versatile tool in order to achieve these tasks. This may include relating asset ownership, spatial occupancy, physical and relative location, permissions and wallet modeling; all in a manner suitable for local and distributed validation and consensus. Cross-asset smart contract side-effects (transactions that are dependant on a primary transaction) are provided as required suggestions to the user during transaction validation, so that clients can choose to apply those changes as part of the primary transaction, creating a valid overall transaction including those side-effect changes. To that end, the invention also “spatializes” contracts, allowing for efficient visual representations of all the interrelationships between contracting parties from a spatial perspective. This allows a smart contract to serve multiple functions beyond the buying/selling goods and services.

The present application defines the grammar for the protocol and the grammar for the contracts.

The HSTP includes spatial range queries that include level-of-detail quantized queries.

Thus, according to one aspect of the invention, there is provided a Spatial Transaction Protocol (Hyperspace Transaction Protocol) (HSTP), which includes packet structures for querying, defining and updating assets within a spatial range, comprising spatial quantized range queries/views defined by a range and a reference space. These packets may be sent to a server or peer-node network.

The spatial quantized range queries allow for the requesting of files in a certain area and at a particular resolution (not just a request for a specific file/asset but all content in a certain area).

HSTP also provides spatial smart contracts, i.e., not just accessing the files but also downloading the associated spatial smart contracts, which define how the assets can move/be modified, and what the permissions are so that when an asset is downloaded you know what you can do with it. Thus, according to the invention, there is provided a Hyperspace transaction protocol (HSTP) for spatial querying, and returning spatial assets and associated content payloads, and for requesting changes to those assets, comprising spatial quantized range queries for requesting files in a certain area, spatial transactions, spatial smart contracts to validate transactions that are downloaded when a file is accessed and to define what may be done with an asset, in a manner suitable for multi-party consensus ledgers.

The smart contract includes an approval expression over a transaction, which defines whether the associated holder of the contract approves of the transaction. Approval is required for transactions on the asset and from its associated owner and space contracts, and consequently approval from the asset must be calculated for transactions on assets which it owns or which are hierarchically within it’ s space.

The HSTP also operates in a cross-ledger fashion and includes a financial model. The cross-ledger contracting allows ownership and occupancy contracts to control locally and remotely instanced assets (effectively assets have their own permission contract, and reference to two other assets, the owner and space, whose contracts are also required to be validated in a complete solution; this creates a cross ledger permission system). It also provides for self-sovereign identity (user validation via anonymous credentials) and can be implemented on cloud-based and/or blockchain platforms. For example, the requester of the transaction can be confirmed by decrypting the user’s credentials or the whole transaction based on a public key of the asset which itself can be on a separate ledger. In one embodiment, a HyperLedger Fabric blockchain is used to store assets and to validate their contract by embedding the HSTP contract evaluation engine in the smart contract; this would actually allow two separate blockchains running equivalent smart contracts to enforce cross-ledger asset requirements. By building in a financial model that enables economic transactions that can be programmatic, automated and spatially bound or oriented, it also allows creators to be compensated for their work and creates a business model for creators and an incentive to create, instead of basing the business model on advertising where only the service provider benefits.

The spatial range queries may include one or more of: asset definitions, spatial location information, spatial content information, spatial view information, and, as mentioned above, can be expressed as level-of-detail quantized queries (zoom level ie. How many pixels to define the data) - hence the use of the term Spatial Quantized Range Queries.

According to the invention there is provided a spatial transaction protocol (STP) for spatial querying, returning spatial content and assets, and for requesting changes to those assets, comprising

spatial quantized range queries for requesting assets in a certain area, spatial transactions over those assets or ranges,

spatial smart contracts to validate transactions and define what may be done with an asset, and

a decentralized identity referencing mechanism to support multi-party consensus ledgers and cross-ledger contracting.

The spatial quantized range queries may include one or more of: asset definitions, spatial location information, spatial resolution information, spatial packing information, and spatial content information.

The STP may further including means for at least one of wallet modeling, and cross-ledger contracting facilitating atomic swaps.

A spatial quantized range query may include a view defined by a range and a basis space and content graph of existing visible features, that is sent to a server or peer node and specifies what a requestor would like to see, and a result (state) of that view, which is sent back by the server or peer node.

The spatial smart contracts may be expressed as an interpretable JSON expression, and provide bounded evaluation time.

Further, according to the invention, there is provided a Spatial Transaction Protocol (STP), which includes:

a spatial quantized range query, comprising

a view defined by a range and a space that is sent to a server or peer node and specifies what a requestor would like to see,

a result of that view, which is sent back to the requester, and

a transaction protocol to change the assets.

The view may include one or more of requestor information, cryptographic signature information, existing requester visible information for view estimation, and location information·

The location information may be defined in various dimensions instead of being hard coded in the STP. The dimensions may include one or more of xyz, longitude/latitude, and time.

The view, may further include a search field, and vector or profile id for prioritizing the results of the view.

The requestor information may include a signature, wherein the signature may comprise a signature by a private key of a requestor that can be validated against a public key.

The requestor information may further include means to notify the requester if the view is modified (subscription mechanism).

The result of the view may include background content, and a list of assets. Each asset may include sufficient values to contractually validate any change. Each asset may include:

An asset ID, with authority information,

an OWNER asset ID for the asset, with authority information, a SPACE asset ID for the asset, with authority information, a location,

contained content, and

a permissible transaction contract

The asset ID may include a public key and one or more consensus authorities. The location may support multiple coordinate systems, expressed as at least one of a point value and a quantized range. The location may further supports providing resolutions for each dimension of the space.

The STP may further include dimensional packing information.

The asset may further include space and time route information, and may include a wallet value of the asset. The asset may be associated with a contract which defines what can be done with the asset and with any content. The asset may further define a default contract associated with the asset, which requires that any change to an asset can only be made if the owner or asset itself is also the requester. The asset may further include a public signing key, which allows an asset to validate transactions as being requested from itself.

Still further, according to the invention, there is provided a method of managing a spatial domain, and actions within that domain, by representing the domain as an asset, wherein the asset information includes at least one of spatial location information, spatial permissioning information, and user validation.

The spatial permissioning information may include governance of permissible transactions on the asset itself, as well as on other assets within its domain. The spatial location information may include at least one coordinate system, a point value, and a range.

The asset may be a physical or virtual asset. Still further, according to the invention, there is provided a method of transmitting and storing spatial information, as interconnected assets, comprising

creating packets that include:

a packet type comprising at least one of query, result, and transaction;

at least one of target asset ID and location,

a set of asset definitions, wherein the asset definitions include at least one of identity, owner, space, location, content, contract, and wallet-value.

The location may support multiple coordinate systems, and may include a range. The location may further supports a resolution for the space.

The asset may further include route information.

Still further, according to the invention, there is provided a method of decentralized routing comprising routing of packets based on at least one of their spatial destinations, relative spatial locations, and spatial permission contract.

Still further, according to the invention, there is provided a spatial domain system (SDS) for real and virtual assets, comprising

an asset ID

an associated authentication key,

an owner ID of the asset,

a space ID of the space that the asset exists within, and a location.

The location may support multiple coordinate systems, each comprising at least one of a point value, and a range. The location may further support a resolution for the space. Still further, according to the invention, there is provided a spatial browser for interacting with a spatial network via requests, comprising

view query code defining a range and a space related to a view query, state code for viewing information received in response to a view query, and a transaction code to create or change assets and their associated attributes.

The requests may include requester information and supporting authentication material.

The location information may be defined in various dimensions and is not hard coded in the view query code.

Still further, according to the invention, there is provided a method of managing inventory tasks, comprising

defining items in inventory as assets, wherein the asset definition includes, spatial information and contracting information, that expresses tasks as permissions within temporal and spatial bounded routes.

The spatial information may further include user validation information.

The method may further comprise generating virtual assets for physical assets. The method may comprise spatially anchoring the virtual assets relative to one or more reference asset locations.

Still further, according to the invention, there is provided a method of validating the movement of goods from one location to another location, comprising

defining at least one of goods and containers housing the goods, as assets,

associating spatial information with each asset, wherein the spatial information includes an asset transaction permission contract.

The spatial transaction permission contract may further include route information. The method may further comprise associating bill of lading information with the spatial information·

The asset may include information about relative location of an asset within another asset.

A valid range of movement of the asset may be visualized as part of a view query, and may be defined in various dimensions, and is not hard coded in the view query.

The dimensions may include at least one of time, temperature, location, and pressure.

The asset may include at least one of a signature, public key, and biometric information.

The signature may include a cryptographic signature of a requester that can be validated against a public key.

Still further, according to the invention, there is provided a method of providing an authenticated checkout for goods sold to purchasers by a store, comprising

defining the goods or groups of goods, purchasers, and the store as assets, and

associating spatial information with each asset, wherein the asset information includes an asset transaction permission contract.

The method may further comprise capturing at least one of user validation information, and payment information, and may comprise generating a view of the assets.

The method may comprise locating the assets relative to one or more references based on the spatial information.

Still further, according to the invention, there is provided a method of managing traffic to enable collaboration between vehicles, comprising

associating spatial information with each vehicle, wherein the vehicles, roads and nearby entities are defined as assets and the spatial information includes a spatial permission contract communicating one vehicle’s responses to physical and digital signals from other assets.

The vehicle may be a land, airborne or waterborne vehicle.

The spatial information may further include spatial content information, comprising at least one of visualization models, collision estimation models, and routing models. The spatial information may include one or more coordinate systems, defined and aligned by a scene graph of visual recognition feature points.

The communicated spatial information may vary relative to the resolution of a requesting view query of a particular communication.

Brief Description of the Drawings

Figure 1 is a view of a human body analogy to a network;

Figure 2 shows the concept of nested domains;

Figure 3 is a depiction showing nesting and spatial domain localization;

Figure 4 is a depiction of a graph database as known in the art;

Figures 5A-5C show various view query types;

Figures 6A-6D show implementation examples of visual tracking in accordance with the invention;

Figures 7A-7C depict one implementation of quantized media in accordance with the present invention;

Figure 8 A and 7B depict the handling of bounds and rotations in the prior art; Figure 8C depicts the handling of rotations and bounds in the protocol of the present invention;

Figures 9A-9C shows visual depictions of various contract clauses in accordance with the invention;

Figure 10 shows a flow chart depicting the logic in one embodiment of a transaction generation and validation in accordance with the invention; Figure 11 shows one example of HSTP integration in a warehouse application in accordance with the invention;

Figure 12 visually depicts HSTP host integrations in accordance with one embodiment of the invention;

Figure 13 shows on implementation of HSTP app and SDK layers in accordance with the invention;

Figure 14 is a depiction of one embodiment of HSTP protocol packets in accordance with the present invention;

Figure 15 is a depiction of the primary properties of an asset in accordance with the invention;

Figure 16 examples of different methods of defining location and dimensions;

Figure 17 is a depiction of DIDs in accordance with one embodiment of the invention, compared to URLs;

Figure 18 is a flow diagram of the DID architecture and credential proof flow;

Figure 19 is a depiction of the relationship between transactions, contracts and validation, in accordance with one embodiment of the invention;

Figure 20 is a depiction of contract validation in accordance with one embodiment of the invention;

Figure 21 is a depiction of the handling of the movement of assets in accordance with one embodiment of the invention;

Figure 22 is an overview of one embodiment of an HSTP packet in accordance with the invention;

Figure 23 shows JSON grammar for HSTP in accordance with one embodiment of the invention;

Figure 24 is an example of a data query in accordance with one embodiment of the present invention;

Figure 25 is an example of a data request result in accordance with one embodiment of the present invention, and

Figure 26 is an example of a transaction in accordance with one embodiment of the present invention. Detailed Description of the Invention

The challenge in implementing something like Industry 4.0, or controlling the movement of goods, or managing the flow of land, air or sea traffic, lies in the efficient visualization and spatially defining of objects, and the contractual validation of any changes to the objects, their location, or their ownership.

As mentioned above, the present invention provides a Spatial Transaction Protocol (STP), also referred to herein as Hyperspace Transaction Protocol, or Hyperspace Transfer Protocol (HSTP), providing for spatial querying, the returning of spatial content and information about assets, and requesting changes to those assets, all via the use of spatial contracts.

Further, spatial content may, in the case of moving or frequently-changing assets, include spatial content information, comprising at least one of visualization models, collision estimation models, and spatial routing models. Spatial routing is the approach by which individual communication packets can be routed from source to intended destination through a physical or virtual network using the target physical address rather than the traditional IP address. These spatial routing mechanisms can be significantly more efficient than IP based mechanisms when the map of IPs is not well understood, as happens in dynamic scenarios, and allow each step to be spatially contracted (i.e. a well behaved router can stop a bad actor sending packets to an unauthorized endpoint).

At its heart, the protocol allows for the creation, implementation, and maintenance of a spatial network or spatial web that registers and catalogs various spatial assets in a“spatial index” stored using a combination of traditional and graph databases and/or one or more distributed ledgers (typically blockchain-based). It also includes a set of proprietary commands and procedures for users to create, transfer, manipulate and store various spatial assets. As a simple broad analogy, referring to Figure 1 , a network of connected information systems can be depicted by a human body. This includes various information inputs and processing systems, e.g., AI (artificial intelligence) (as depicted by the brain), AR/VR (augmented reality/virtual reality)(as depicted by the eyes), NLP (Natural Language Processor) (as depicted by the mouth), Robotics (as depicted by muscles), Actuators , IoT, etc.. If these define a distributed network of information, then the protocol of the present invention (HSTP - also referred to in the inset to Figure 1 as VERSES) can be thought of as the signaling interconnect and permissioning system between all of these information inputs. While the Internet is often analogized as the nervous system that connects all communications, it really is limited to the wires and high-level flow of communication data. In contrast, HSTP can be seen as the perceptual groupings (assets) and spatial/dimensional relationships, along with their permissible (expected and reactionary) transactions. In this analogy, the HSTP would be a neural construct analogous to the processing of acetylcholine that is released by nerve cells (nodes in a network) to send signals to other cells under certain multi-dimensional input conditions.

Just as acetylcholine acts as a neurotransmitter or chemical that motor neurons of the nervous system release in order to activate muscles in the human body, so HSTP of the present invention acts as the signaling and logic control that keeps track of assets and relates them spatially to each other, acting as arbiter in allowing or disallowing transactions, such as movement of assets in a new space.

Reality can be viewed as comprising three elemental spaces: spatial, semantic, and ontological. If we want to define and capture assets for querying and

manipulation, we need to define the spatial space (where an asset is located, e.g., in a conference room); the semantic space (which defines the meaning defined by words, e.g., the meaning of“John’s laptop”,“Our lab”,“Building at 236 Greenwood Blvd, Los Angeles, CA”; and ontological space (the relationship between assets, e.g., the space defined by the room, the chairs and table in the room, etc., and the rules defining how the various assets interact or relate to one another, e.g. This is John’s chair, which is at the head of the table, in front of the drawing board.

In any spatial transaction we need to know the Who, What, Where, When and How, as is illustrated in Figure 3, and discussed further below. The Who (owners of assets, and requesters), the What (which defines the assets involved in the transaction), and the Where (which defines the spatial space) may be captured in any suitable database, e.g. graph database, which may be centralized or distributed over multiple nodes. The When is a time dimension that can be associated with the assets. The How defines the terms of the transaction and is based on the ontological space.

The protocol of the present invention (HSTP) defines how to bring the various data items together through queries and testing the terms of the transaction against the rules to determine a pass/fail.

In this application, we will also refer to domains, which are spaces that confer rights. Thus, space per se can be thought of simply as a region. Once you add rules that govern that space, e.g.,“you may not bring food into a certain room in a building”, then the building and the room are considered domains and subdomains, respectively, as depicted in Figure 2.

As shown in Figure 2, in this example, we have a global domain 200 defining the entire building and surrounding parking lot. Within that global domain, we have two sub-domains 202, 204 as defined by the parking lot and the building itself. We could have further sub-domains within sub-domains, e.g., rooms within the building. Thus, this allows a hierarchy of domains to be defined, i.e., domains nested within other domains, each with its own rules. For instance, strangers may park in the parking lot 202 but cannot enter the building 204 without permission. They may be able to take beverages into the building but certain rooms within the building may be off-limits to food and beverages. In the above context, an owner can be an asset and included in a database, just like any other asset (where assets also include domains). Furthermore, ownership can be a parameter associated with an asset, which further defines the asset in ontological space, e.g. a laptop in a particular office may belong to John Smith and may not be removed from the office without John Smith’s permission (where John has ownership and is a parameter on the laptop asset).

The aspect of nested spatial references can better be understood by again considering Figure 3

A Spatial Domain may be volumetric and may have geo coordinates expressed as a range. An internal space may use X, Y, Z coordinates, while an exterior space may be defined by a Physical Address. Thus, in this embodiment, the exterior space can be defined by GPS (Global Positioning System) coordinates, while the internal space is Virtually Addressed. We could refer to it as VPS (Virtual Positioning System) (a combination of XYZ coordinates + real-time point coordinates) to determine a point in space in which the Hyperspace Link is anchored, or is anchored to a Smart Asset or object. This is also why Spatial Domains are holonic or nested. It allows an address or link to be associated, for example, with an object spatially inside a vault on the lOlst floor of the Empire State building, or allows the object to be placed floating in mid-air 100 ft above the building or anywhere else for that matter.

In one embodiment, this can be implemented by embedding reference locations - or virtual“landmarks” - into the query. By way of example, an asset (e.g. a person) may have sofa 3 feet to the right of where he/she is standing, and a window 2 feet above that sofa. These reference points can then be used to estimate the user’ s current spatial reference frame, which can then be aligned to other reference frames (e.g. a room can be within a house, but it is also in a city, a country, and on Planet Earth, the Milky Way Galaxy and so on). The protocol also keeps a reference frames in“alignment” where changes in relative positions can be updated and manipulated across multiple levels simultaneously, just as they are in physical reality. Using the house example above, if a person in the house walks next door to the neighbors’ dwelling, he/she is now in a completely different reference frame with respect to the original house, yet the differences in other reference frames (e.g. current city, country and/or planet) likely have not changed all that much. Each would need an incremental change that would be reflected as matters of degree, which the current invention tracks and synchronizes in real-time.

For purposes of this invention, the term“asset” includes both“spaces” (such as rooms in a physical building or a virtual castle in a video game) as well as people, objects and information found within these spaces.

Spatial assets comprise two types:

A“digital twin” of a real-world, physical object, location, or person, such as a virtual representation of a real-life building or“avatar” of a human being. The “digital twin” stays in“sync” between the virtual and real worlds through sensory, manual, simulation or oracle-based input mechanisms.

The second type corresponds to a purely digital object, like those created for video games and movies that do not necessarily have a real-world counterpart.

Furthermore, spatial assets exist within a Spatial Index of assets, and can reference other assets on the same index or on other spatial indices or graph- like databases of spatial assets, thus creating a cross-authority spatial network. Spatial Indices range from optimized spatial configurations found in GIS applications, to simple adapters over traditional databases or even in-memory file systems. Well behaved spatial indices, i.e. those adhering to the HSTP protocol and contracting standards, will validate all incoming and out-going transactions and queries to respect the contracts provided on assets. This can also be facilitated via consensus mechanisms. Each asset is given a unique identifier, along with its own specific properties such as location, contract, content, etc. and often provides provenance or historical tracking via blockchain type transaction chain hashing.

In a graph database, as shown in the example of Figure 4, the various nodes 400 define the concepts in the network, e.g. the various people and interests. The edges 402 represent the semantic relationships between the nodes/concepts. In a spatial solution, the assets can form the nodes in the graph database, with their relationships (ontological space) defined by the edges between the nodes. In one embodiment the Neo4j graph database is used to store assets as nodes, with their properties existing as links between the nodes, and when a node asset is queried all related links as expressed as properties in the resulting HSTP asset definition. In another embodiment the spatial index is expressed in a relational database indexed by asset id and with simply a JSON blob as its current state, although this limits efficient indexing. In yet another embodiment the spatial index is stored on an ESRI ArcGIS instance, which include very efficient geo spatial indexing and querying mechanisms. In one embodiment the Spatial Index has the following information for each spatial asset:

ID - asset identifier (DID); including a uniquely identifying string across one or more authorities (with a consensus style being required for multiple authorities, generally ONE/MOST/ALL), as well as public -key encryption information, etc.

SPACE and OWNER - DID’s of the asset’s SPACE and OWNER, defaults to the asset itself; defines who owns the asset and in which space it exists. Any transactions on an asset will be validated against the contracts of the owner and space. Note that the space and owner may be on separate ledgers in which case the full DID of the asset must be specified.

LOCATION - one or more dimensions, preferably including range and resolution, and optionally with a transform/bounds of any inner content.

Standard supported dimensions include X, Y, Z, LAT, LON, ALT, and TIME, as well as custom dimensions being deeply supported; such as TEMP or PR for temperature and pressure.

CONTRACT - an expression that defines the validity of any transaction within its scope, both spatially and with respect to ownership. See Contracts section below.

WALLETYALUE - positive scalar value representing the wallet value of this asset, automatically contracted to maintain a total sum across a given ledger. CONTENT - optional directory of named content types, usually for application-specific content.

This information is stored in the Spatial Index to serve as a profile for the asset it describes. Together, these characteristics help describe and track the asset’s behavior and status over its lifecycle.

Spatial Web Stack

In one embodiment, the spatial web stack includes at least five layers: starting from the bottom with transport layers between spatial endpoints (either client-to-cloud or peer-to-peer connections) upon which distributed identity networks can be built to establish the specific network of spaces and authorities. These are communicated between by means of HSTP messages (queries, results, transactions). These may be organized into scene graphs (as discussed further with respect to Figure 21) and include spatial indices to allow them to be viewed and managed within a spatial browser:

In one embodiment, our spatial browser runs on both both smart-phones and wearable-smart- glasses, and includes features for identifying it’s current location, searching for nearby spatial content, loading that content, menus for creating or loading remote content, as well as loading specialized content types such as for warehouse operations. This spatial browser is able to create new scenes of content, such as photographs or points of interest, as well as associate spatial contracts (tasks, permission, etc.) to those areas.

Of note that our STP uniquely combines the communications and layout or markup language which are traditionally separated into different protocols such as HTTP and HTML. Traditionally HTTP was used to request and upload files, while HTML was used for layout. Somewhat unexpectedly upon development, because our content is inherently spatial, there is no need for a separate layout system.

Additionally, the concept of scripting, generally associated with yet another language JavaScript, is replaced with our spatial contracting language which covers permissions and thus implicitly allowable and required interactions, removing the need for scripting. In this way HSTP uniquely replaces HTTP, HTML and JavaScript in the browser stack.

Spatial Contract Economy

It is important to note that spatial contracts become a primary means of communication, not just permissioning, again a unique concept. Many existing messages such as“let’s meet then”, or“deliver this to there”, etc. are likely to be expressed as space-time shapes rather than simple text, both for professional contracting but also for casual communications purposes. Furthermore, HSTP explicitly supports“token wallets” on assets, allowing spatial contracts to act as bridges into commercial/cryptographic exchange mechanisms, or more commonly into banking and traditional finance systems.

According to the present invention, the visualization and spatial anchoring of assets and contracts are performed by means of spatial queries. For geo located assets this can be done in standard latitude/longitude space, while for augmented reality assets the anchoring will be with respect to known visible assets, spatializing those assets by relating them to a hierarchical spatial map, and then inferring the viewer position by their relative location to the viewer with respect to the map (in one embodiment, the viewer can see a particular barcode, query where that barcode is on the map, and then infer where they are on the map based on where the barcode is relative to the viewer themselves). The industry standard concept of“scene graphs” is used to enable the expression of assets being placed relative to each other, in such a way that moving the basis or“parent” object automatically moves the related or “child” object. In one embodiment the core SPACE property on each asset defines the spatial basis or“parent” asset, and spatial calculations are made relative to that asset.

If we consider query types, they may take the form of lists of assets, or maps combining raster and vector imaging. These are traditional ways of describing or depicting something. Figure 5A, for instance shows a list of assets, while Figure 5B shows a map scene as is common in map applications such as Google Maps.

However, in order to deal with physical or virtual assets that we wish to interact with, e.g. move from one place to another, we have to define those assets (which may comprise spaces and objects in the spaces) by localizing them in 3D space and with respect to time. This involves localized queries in which a reference scene is provided in the query (such as relative location of one or more barcodes as described above), and then a localized scene is returned which relates the barcodes and the viewer to a known map space, showing all the various spatial assets currently in that selected space. The process is shown in Figure 5C.

In order to visualize the assets, a view of the space and objects is created, such as by using sensors to locate and position the assets in relation to the surroundings as part of a view query. For example, Figure 6 shows how HSTP can be used to query camera images (Fig 6A), receive back quantized pixels from the camera (Fig 6B), ran machine vision-based object identification results on those images (Fig 6C), and create asset updates from the object identifications (Fig 6D) as part of separate transactions making up a spatial processing arrangement, which itself can be contractually defined.

Since an important aspect of the present invention is that of multidimensional quantized range queries, it is worth looking at this in more detail and contrast it with the current prior art.

Multidimensional quantized range queries as a basis for the network protocol

If we were to specify the location of a point, we could do so by using a 2D or 3D coordinate system that would exactly define the location of the point. However, when dealing with assets in the form of objects and spaces, the assets occupy an area (i.e. in the case of a human being, the area would be roughly 2-3 feet wide by a foot deep). That occupied area is itself relative to other areas, and the present protocol (HSTP) keeps track of this through the use of ranges. Thus, within HSTP, the “location” of an asset is viewed as a combination of a set of multi-faceted quantized ranges, as well as the spaces within which those values exist. This forms both a “scene-hierarchy,” and allows for multiple dimensions to be expressed within those scene elements. The scene-hierarchy can also be used with different coordinate systems (e.g., x,y; longitude/latitude) and also including dynamic coordinate systems in the form of moving scene graphs. The addressability of the location is then expressed in the form of a multidimensional, quantized domain name or Uniform Resource Locator (“URL”).

For purposes of HSTP, the term“multi -dimensional” refers to other attributes beyond purely spatial dimensions. Thus, not only x, y but literally any range of data - including time, temperature, light, pressure, dampness, or other dimensional ranges as may be captured by sensors - can be expressed in the form of a searchable spatial domain name.

The term“quantized” is used herein to signify the ability to maintain image integrity as a user zooms in or out. Thus, the number of pixels of an image is adjusted to maintain image integrity, as may be seen through a variety of different devices, including cameras, smartphones, tablets, or even augmented or virtual Reality glasses. Referring to Figure 7A, a scene may be depicted as a pixelated scene or quantized view (pixel/raster quantization) providing for adaptable scene integrity depending on the amount of detail required, e.g., the zoom level. Similarly, assets in the scene may be quantized as shown in Figure 7B to define a scene that is composed of multiple quantized elements. In the present invention, queries include the query range and quantization level (resolution) in the various dimensions, thus defining the quantity and packing of resulting information, as depicted by the representation of Figure 1C. This allows a packet to be“bounded” in terms of size based on the quantization required; the bounded size being a function of the number of quantized units, multiplied by the number of requested dimensions. In one embodiment a 2D map query specifies both a range in latitude and longitude, as well as the pixel counts in each dimension, and the dimensions to be queried (such as color and altitude), the resulting data count is then the product of the number of latitude and longitude pixels with the number of requested dimensions. The packing of these pixels is also defined within the location, for example the image dimensions X and Y common implicitly based on the packing of color data, can be defined explicitly by expressing the “packing” relationship between index and implied location (generally the packing X=(index% width), and Y=floor(index/width) is assumed for 2D bitmap data). In order to understand the concept of ranges as used in the present protocol, it is important to contrast it with prior art solutions. One commonly-known example would be online maps in 2D, such as those used in Google Maps, which query the range (in latitude/longitude), as well as the pixels/quantization per dimension.

Normally this is organized by“latitude =A, longitude =B, zoom=C”. For example, Google Maps’ Static API defines map images using URL parameters, which impact the location, size, and resolution of the image, as described below and in the link:

Location Parameters

• center (required if markers not present ) defines the center of the map, equidistant from all edges of the map. This parameter takes a location as either a comma-separated (latitude, longitude } pair (e.g. "40.714728,- 73.998672") or a string address (e.g. "city hall, new’ york, ny") identifying a unique location on the face of the earth. For more information,

see Locations below.

* zoom (required if markers not present) defines the zoo level of the map, which determines the magnification level of th map. This parameter lakes a numerical value corresponding to the zoom level of the region desired. Map Parameters

* size (required j defines the rectangular dimensions of the map image. This parameter takes a string of the

form {horizonta1_vakre} r{ver†ical__value] . For example, 500x400 defines a map 500 pixels wide by 400 pixels high. Maps smaller than 180 pixels in width will display a reduced-size Google logo. This parameter is affected by the scale parameter, described belo w; the final output size is the product of the size and scale values.

* scale (optional) affects the number of pixels that are

returned scale-2 returns twice as many pixels as scale- 1 while retaining the same coverage area and level of detail (i.e. the contents of the map don't change ). This is useful when developing for high-resolution displays, or when generating a map for printing. The default value is 1. Accepted values are 2 and 4.

• format ( optional ) defines the format of the resulting image. By default, the Maps Static API creates PNG images. There are several possible formats including GIF, JPEG and PNG types. Which format you use depends on how you intend to present the image. JPEG typically provides greater compression, while GIF and PNG provide greater detail.

In Google Maps Static API, properties such as zoom, or range affect a key point representation. In contrast, in the present invention ranges are defined as part of each dimension, such as“latitude = {min/max/count}, longitude ={min/max/count}.” Thus, all information about latitude is stored in one place under that dimension’s name, while all information about longitude is stored in another. In this way, both the minimum and maximum for each parameter is stored as part of that parameter, boosting efficiency.

For example:

“MIN/MAX” in one embodiment, is defined as“SELECT * FROM Assets WHERE ((lat>=bound.lat.min)&&(lat <= bound.lat.max) && (lon >= bound.lon.min) && (lon <= bound.lon.max))”.

In the case of large and highly complex dataset charts, such as“heat maps,” the present protocol can be used to define a specific domain range, and then break that range up into quantized or discrete sections (or“chunks”) for sorting or aggregation. Common quantizations are the pixels in a map request, or the bars in a bar chart. Common aggregations are max, average, or sum; sum is often used to count items in an area, while average is common for demographic information. HSTP Rotated Transforms:

Rotation is often a source of miscommunication between platforms and can greatly complicate intersection and other calculations. Traditionally rotation has been expressed as an independent property next to position. This, however, makes it difficult to include additional dimensions. At a low-level 3D rotation is almost always expressed as a 4x4 matrix for GPU implementation. To avoid these complications and to provide a more efficient mapping to database architectures the present invention uses the linear algebra approach to multi -di ensional matrix rotation, rather than hardcoding a specific number of dimensions as discussed further below with respect to Figures 8A-C.

In traditional linear algebra N*M matrices, either the rows or columns (depending on transposition) define a vector dot product from the input vector to a single output dimension. We separate out these vectors and define them specifically per dimension, which makes the translation of these complex constructs fairly trivial into a SQL SELECT statement as a weighted sum (thus achieving pixel accurate rotated projection of large datasets directly within a traditional querying language) Furthermore, we unify these approaches by defining a perspective-normalization dimension (in one embodiment explicitly named“1”) whose inputs are normalized to ensure that it’s value is 1, to enable expression of an n-dimensional“perspective” projection, in which nearby objects appear larger than further away objects, common in 3D perspective rendering. In a common example of perspective rendering, the viewer is looking down a long road lined with tall poles. Let us say the top of these poles are at [2,4,6], [2,4,10], [2,4,16], etc. (2 meters to the right, 4 meters up, 6/10/16 meters down the road), we might define a simple perspective such that

{x:{x: l },y:{y: l ],“l”:{x:0,y:0,z:l } }, which when normalized would put the locations at [2/6, 4/6], [2/10,4/10] and [2/16,4/16] in 2D space once projected, which implies that the further poles would be smaller in 2D space. This perspective-dependant spatial content, where the scene is specifically rendered to match a specific viewpoint, and then streamed as query results, can greatly reduce the processing needed to interpret results on the client-side, putting more detail up close rather than further away, and allowing better“re-projection” or range of movement near the queried view location. This is depicted in Figure 8C, which contrasts the HSTP multi-dimensional matrix notation (with its grouped matrix weights and axis bounds for each dimension), with prior art HTML (Figure 8A), where the axes and bounds are separated, making it difficult to express in a traditional database. Figure 8B shows OpenGL 4x4 matrix notation, which is difficult to extend because it is locked to 3D, and doesn’t support additional dimensions.

In the above description, ranges were included in order to define assets and space that have size. However, in the case of queries, range also serves as a filter focusing the query on a certain span of data, e.g., using quantized range queries in charting/bucketing/etc., to select both the time range to be considered, as well as at which scale that range should be bucketed or grouped into say minutes, hours or days. By including the ranges at the protocol level as described in these important use cases, it becomes drastically more efficient to process and route queries to appropriate data and is not locked to specific dimensions as found in numerous GIS and 3D

technologies.

Even though multidimensional queries per se are known in the art, e.g., SQL, GraphQL and many other database technologies, which have range filters and quantization/bucketing mechanics, they don’t have a network protocol where network identity is merged with the data range. Instead, those prior art solutions have the data range separate from the network identity.

There are significant advantages to the approach of the present invention. By merging matrix weights and quantized axis bounds with each dimension and using this in the query to request data in a view, we can define the amount of and source of data, because we provide the quantization/bucketing size. This allows us to define the location of an asset in the result, often implicitly, such as within image data where the location information is implicit in the pixel location. In the case of a transaction, it allows us to define both the implicit target identity and the updated state location. According to one aspect of the present invention, the spatial range is included in the packet header. This avoids the need for an explicit id, thus allowing packets to be routed to“where” they need to go, not“who” they need to go to (packets being mostly queries, results, and transactions).

In practice, the various dimensions may be captured in a matrix of rows and columns. Each row can define a separate location, and each column can define a dimension. In keeping with the concept of a range, each cell in the matrix can include a range.

One of the benefits of multi-dimensional quantized range queries is in the bounding of the data to ensure that bandwidth constraints are not exceeded. Thus, in the present invention, spatialization includes not only ASSET/CONTENT

LOCATIONS (output spans, which can be presented in any one of multiple dimensions) but also includes bounded VIEW LOCATIONS (input spans), such as Longitude -180: 180, and Latitude -90:90, or X -1: 1, Y 1:1, or using any other 3D coordinate system with bounded ranges. By providing for ranges, instead of being limited to points, it allows for INSIDE, TOUCHING and OUTSIDE to be evaluated contractually; in much the same way that two bricks are easier to knock together than two pin tips, the ranges simplify the calculation. LOCATIONS which are defined purely as points are either INSIDE or OUTSIDE. This syntax also allows a more flexible mechanism of expressing space in any required number of dimensions. Thus, TIME can also become a ranged dimension.

The benefits of quantized ranges are discussed in more detail below.

Quantized ranges to ensure that network bandwidth is well-bounded In general, the packet size has a memory complexity that is the product of the resolution of each quantized dimension, with the count of explicit axes; stated another way: max_size has 0( product( each_quantized_axis’s_resolution ) * count_of( each_explicit_axis ) ).

The approach of the present invention allows one to query how many pixels wide and how many pixels high - thus you know the total number of pixels and no more is necessary to send.

For example, in a stereo 3D scenario, such as medical imaging over an MRI, the number of Z layers that you need for best effect could be expressed as the Z resolution, next to the normal X and Y resolution (this way you get a 3d MRI image that is tuned to your device resolution).

The network bandwidth bounding using quantized ranges is implemented on the client side, in one embodiment, by checking how many pixels we need in order to show the data before requesting it, to make sure we optimize for the ideal amount. On the server side, we know how many pixels are to be delivered, and we can divide up the work ahead of time based purely on the query before even touching the backing data.

This allows the estimated bounds to be ascertained ahead of time.

A simple example to explain the benefits of the present invention over the prior art is demonstrated by considering electronic maps, and the process of zooming in and out. In prior art applications, specifically those with hard-coded zoom levels, some of the zooms tend to fade out because they are set to the wrong resolution, even if they are still in range. In contrast, because the present invention supports multi dimensional quantized domain/range queries, we can estimate based on the request (without touching the data), how big the query results should be. The concept of ranges also applies to time. According to the present invention, time is considered just another linear dimension, which is often bounded (this week), and quantized (consider this week as 7 days, or this day as 24 hours).

For example, a meeting on a digital calendar is often shown as a geometric range in time. Some meeting systems will only allow meetings during that range, which can be contractually represented as a geometric range intersection. The property“can meet” being boolean can also be represented as a“0 to 1” range with a quantization of 2. So, the final contract could be either simply:

{INSIDE: {TIME: {MIN: l0am,MAX: 1 lam} }

Or, it could be seen as

{ROUTE: [

{ TIME: { MAX: 10am } ,C ANMEET: { VALUE: FALSE } }

{TIME: {MIN: l0am,MAX: 1 lam} ,C ANMEET: {VALUE: TRUE} }

{TIME:{ MIN : 11 am } ,C ANMEET : { VALUE: FALSE } }

The next aspect to consider in a practical application is the movement of assets and interaction with those assets. For example, in the case of the movement of vehicles (where the vehicles are defined as assets), it is desirable to avoid collisions between vehicles; collisions being defined as touching or overlapping spatial ranges.

Any interaction with assets can be reduced to a set of transactions, the valid ranges of which make up a spatial contract, used to validate each transaction. The present protocol thus includes spatial constraint clauses, several examples of which are depicted in Figure 9A-9C.

It will be noted that Figure 9C includes an asset’s ownership as one of the parameters or dimensions. In this case, there is a change of ownership, which may also entail a change in wallet value. This, therefore, provides a simplistic

visualization of a contract being executed as part of a change of ownership of an asset. Thus, the present HSTP protocol adopts a visual approach to implementing smart contracts, as is discussed in more detail below.

Expression of“Smart contracts” as multi-dimensional geometric operations to define a permission language

In prior art applications, smart contracts are generally expressed in

computational form (ETH, ChainCode, etc.). Thus, geometric permissions (geo fences, trigger volumes, etc.) are often just used as triggers and as part of tests but aren’t generalized to encompass a full contracting language.

In one implementation of the present invention, the core contracting language is a series of CSG (Constructive Solid Geometry) operations that create a bounding shape, parts of which must be either full, partly filled, or not at all occupied.

The kernel of the HSTP SDK (Software Development Kit) is really the contract evaluation engine, where every transaction in a contract is validated by all associated contracts. Each contract is a tree of geometric operations, the results of which must be true.

This approach makes for a more concise execution language with bounds on the maximum computation time for the geometric intersection. By way of a simple example: If one were trying to determine whether two objects were touching, one being a cube, and the other a dodecahedron. By knowing how many facets/dimensions each had, without knowing anything more, one could estimate how many math operations at most you’d have to do to tell whether they were touching or not. It, therefore, seeks to optimize the length of time to evaluate a contract.

This approach also allows for visually expressing the bounds. For instance, we could at worst put in a progress bar with a pretty good estimate of how far along we are, and ideally, it’s so tight that it executes virtually instantly. In contrast, when considering prior art solutions like Ethereum there is no support for these sorts of computational bounds. Thus, it may take such a long time to complete a calculation that it simply“runs out of gas” and the transaction fails. Thus a complex but valid operations may very well fail.

The present approach, on the other hand, is geometrically and mathematically airtight (good for security), and this mathematical simplification makes it easier to express homomorphically (zero-knowledge-proof way, in which you run an algorithm over encrypted data to get an unencrypted result), as discussed below.

Homomorphic Encryption:

The multi-dimensional ranges adopted in the present protocol also provide for another aspect of the present invention: that of using homomorphic encryption to provide spatial proof of being within certain ranges without giving away where in those range the actual value are.

Homomorphic analysis is a recent innovation where an algorithm can be ran over encrypted data and get back an encrypted result (and sometimes an unencrypted result). It was first invented to figure out how email could be stored in encrypted form on the cloud, while still allowing it to be searched.

The present protocol extends this concept to use homomorphic encryption for things like age, to prove that a user is 18 years old, but without letting the prover see how old the user actually is. This is performed by doing range comparisons without giving away the original value. Because we express most things as multi dimensional range comparisons, we can provide spatial proof of being within certain ranges without giving away where in those ranges we are. The Process of Spatial Querying, Visualization and Interaction is shown in Figure 10.

The spatial interaction starts with the collection of visible elements to form a contextual spatial query. This query is then aligned with a spatial domain server, for instance via approximate GPS coordinates, and the client is then sent a response including one or more spatial servers for exact visual alignment, for instance based on computer-vision recognition and alignment of known features. The server generates a scene based on the spatial query, which is sent back to the client and presented to the user. The user then has the option of interacting with the scene via transactions, which are validated locally before being sent back to the authority server for closure.

The visualization of a contract can best be described with respect to a warehouse example. Inventory is converted into spatial assets and the task of picking an item and moving it from point A to point B is a spatial contract. As a first step, traditional data entries, such as tasks in the warehouse, are converted into spatial assets and contracts. In one embodiment the contracts are visualized simply as text diagrams, but is a more important embodiment the contracts are visualized by drawing arrows between where the user is, and where they need to find the item, and then arrows between the item and the box it should be placed in. The items and goal shapes specified in the contract can thus be visualized, converting“put item into box” into highlights around the item and the box, and showing the relationship between them until that relationship is“inside of’.

In one embodiment an HSTP adapter assists in the conversion process. The HSTP adapter converts traditional data entries, such as tasks in a warehouse, dynamically into spatial assets and contracts. Specifically, the adapter receives HSTP queries, translates those into database queries, and then translates the results back into HSTP asset representation. This assetization process includes both spatialization (adding spatial information) as well as contracting where the object API is translated into valid asset transactions. In one embodiment this adapter is written as a Node.js instance with both HTTP/HSTP endpoints and database querying functionality. This allows numerous HSTP clients to directly interact with and complete existing workflows.

In Figure 11, a user in a warehouse sees existing tasks as spatial assets and contracts. This involves three main components:

Adapter: Firstly, existing database entries are mapped into general assets that reference the source table, id and authority. This is depicted in Figure 1 as asset information obtained from the Warehouse database, including ID=Table/ROW_ID, and CONTENT =RO W_D AT A.

Spatialization: Secondly the assets are spatialized by relating those assets to a map (as depicted by“map” in this example), but also by allowing users to orient themselves by estimating their view based on visible assets (this view triangulation is a key component to spatialization, especially in high visual redundancy areas such as warehouses).

Contracting: Lastly any existing object methods or API interactions with the data are translated into a set of valid HSTP transactions and then combined into a single contract that specifies all viable interactions. For example, in this case, the task of putting a particular item in a box and putting the box in a truck, is visually presented to the user via virtual reality glasses and spatially mapped into the environment on a 1 : 1 scale.

In this way the client application is provided with a simple visual menu of actions (step lin Figure 11) based on Adapter conversions from database query to view query (step 2 in Figure 11) as is discussed in more detail below with respect to Figure 12, to allow the user to visually be guided to the asset in question (step 3 in Figure 11), allowing validation locally of most of the interactions, and automatic completion of a given task, based on spatial interactions. The automatic completion is in the sense that the user need not press a“task complete” button, but rather could simply place the item into the correct location, and a tertiary camera or other tracking system can register this movement, and make the task as completed.

The three components: Adapter, Spatialization, Contracting are depicted in Figure 12. In the Adapter component, the HSTP Adapter interacts between the HSTP Client and the Host Server/Database to take Spatial View Queries and convert them into Database Queries and converts the resulting DB Objects back into Spatial Assets. During Spatialization, the Asset Location is queried based on the Object ID. Other View IDs and features can also be used to provide for view location triangulation discussed above (also referred to here as VIEW LOCATION).

Finally, during Contracting, Object Methods are translated into permissible transactions that will make up a Contract.

Most HSTP clients or endpoints will follow a fairly common design pattern, that is also found in the present invention’s SDKs for JavaScript and Unity, and is depicted in Figure 13.

The application interacts with the SDK by creating "views" (spatial queries), that request assets. In one embodiment, the SDK also supports creating visual elements to match these assets (models, lists, controls, etc.) which the user can then interact with, and which automatically translates task-based database entries into visual operations/transactions for validation and sharing.

Central to the design pattern is the“local ledger” or "Asset Cache" which holds all locally known assets, usually from multiple different ledgers. Contract validation pulls from this cache to get previous asset states, owner states, contracts, etc. and also stored queried assets into this cache for use in later transactions.

Commonly, and in one embodiment the asset cache is entirely in memory, in another embodiment the in-memory cache is also backed up by a local storage mechanism, this pair of solutions is common in web browser which cache images, pages and related media.

Below the asset cache, views often result in external connections to external servers. These connections can be either direct HSTP connections, adapter connections (which include other protocols), or consensus connections that broadcast or query multiple endpoints to form consensus across them. The resulting queried assets are then stored into the asset cache. This achieves cross-ledger 'right to reference' by requiring all changes to be validated by the ASSET, OWNER and SPACE contracts. For instance, moving an object between spaces (changing the“SPACE” property) requires the old space, new space, owner, and asset to all be validated contractually. Thus, there are typically between 3 and 5 contracts evaluated per asset change (the asset itself, old space, old owner, new space, new owner). If the owner/space exists on a separate ledger, a full implementation must request the asset's current state (excluding content, but including location) to define a spatial domain, which is sufficient to ensure that the contract is validated. Local application of changes, which all contracts accept are acceptable, although not authoritative until the asset's ledger has confirmed the change.

Since cross-ledger contracting is another important aspect of the present invention, it is discussed here in more detail.

Cross-ledger contracting

According to one aspect of the present invention, multiple assets (which may include the SPACE and the OWNER) have to sign off on any transaction on a particular asset, and those“remote” assets need not be on the same server as the asset being modified. This act of approval from remote assets can be done using a copy of the remote asset, which includes its CONTRACT or approval expression, by simply evaluating that approval expression over the transaction in question, and thus don’t require sending a message to or modifying the remote asset itself. The authoritative server must of course be provided with any transaction on an asset to update the authoritative copy of that asset (by definition), but the approval of a remote controller asset (such an owner or space) would not result in a change to that remote asset and thus is not needed, allowing the transaction be fully validated using only a copy of the remote asset; which facilitates systems such as blockchain where read access is significantly faster than write access. For an example of remote approval, sales regulations in a particular State may define permissible transactions for specific retail operations in that State, but may not require that all such transactions be registered with the government. Specifically, they may restrict who can buy alcohol, even if the government doesn’t ever get a record of the transaction; this enables privacy models such as GDPR while still providing a means of validating transactions either for moral or legal auditing reasons. This also allows more efficient validated trading without having to get written approval, yet still be bounded by official regulations; the approval being expressed as a valid range of transactions.

In another example, you may want to put rules into an online profile, such as for a child, that do not allow that profile to accept messages from outside parties.

The same applies to rules of a game. It allows a game to exist on one ledger that considers rules written in the profile of the user on another ledger.

In contrast, while prior art decentralized systems such as W3C DID are designed to support decentralized systems, they don’t have a permission model.

Similarly, prior art permission models assume that all actors are on the same backing ledger and don’t support cross-ledger contracting. Even some routing engines like Mulesoft, which support a permission model that acts across servers are themselves limited. They don’t expose the permission model, thus a client may unsuccessfully attempt a failed transaction.

In HSTP, we expose the permission model so that the client can check for compliance without having to attempt a failed transaction. Also, in the present protocol permissions are themselves expressed as shapes, which is natively capable of defining a geospatial model that can express geospatial transactions.

In order to implement cross-ledger contracting, one embodiment of the present protocol provides that every ID is not only a string but a series of authority endpoints (i.e. official record keepers). Thus, every reference to an asset in this embodiment includes the asset’s list of authority endpoints.

This allows for ID comparisons for things like“did the owner request/approve of the change”, etc.

Thus, contract evaluation requires both the changes to be made ("TO"), as well as the previous official state of the asset ("FROM", excluding content). Contracts also support the concept of variables, allowing future parties / locations / prices to be validated.

In order to support the movement of assets, e.g., in transportation scenarios, spatialization can include ROUTE, which is a collection of LOCATIONS, often with separate TIMES for each location.

Connections between ledgers should utilize secure signing, assisted by the public key of the asset, to ensure that the "REQUESTER" is actually who they say they are. However, since the HSTP protocol is intended for in-memory, peer-to-peer and cloud scenarios, the actual encryption method is left to the secure transmission layer. Nevertheless, once the requester has been validated, all requests must first pass known asset contracts for the request to be executed, and the format for sending failed contract transactions back to the sender is provided in the above protocol, including missing assets, specific contractual clause failures, suggested or required alterations and side-effects, etc. (see <HSTP_PACKET>.RESULT in Figure 23 of the full schema).

It will be appreciated that each ledger will have its own concept of currency, and every valid transaction will typically not change the total currency in the system. For trades between ledgers, an exchange service must be utilized, that operates assets on both ledgers. Another benefit of the cross-ledger model of the present invention relates to latency. When it comes to distributed consensus mechanisms, their inherent nature requires connecting to and coordinating between multiple points to gain consensus on what could be drawn from a single authority (their strengths being that there isn’t a single authority). But they will almost by definition incur deeper latency than other single authority mechanisms. In contrast, by using cross-ledger contracting to keep slow- changing assets/contracts on a distributed server, and faster changing assets on a traditional server, it allows the user to achieve the best of both worlds. One example involves a quickly movable asset updated via peer-to-peer communications, managed by a cloud instance, but bounded by a spatial contract kept on a real-estate blockchain; specifically two people talking (peers), while one is holding a cup owned by the restaurant (represented on the cloud), while they are in the restaurant (whose rules are published on a blockchain). In this example the secondary peer can get the update of the cup moving and validate it, before the official cloud representation of the cup is updated, and can check that their peer is allowed to move the cup as long as it stays within the restaurant, as defined by a rule on the blockchain, all via extremely fast peer to peer communications. This mixture is suitable for common business scenarios while maintaining the most critical assets in a non-single-authority model.

A key feature of HSTP is the ability to both collaborate and exchange on a purely peer-to-peer basis. For this reason the Software Development Kit (SDK) of the present invention includes the ability for any node to itself be a spatial server, capable of answering basic HSTP requests, including simple rendering tasks, allowing local multi-user scenarios to be efficiently created and managed, with clear mechanisms by which to integrate or authorize transactions.

Practical applications of the visualization aspect of the protocol

- Means of visualizing contracts.

- Means of using computer vision to automatically complete contracts. - Means of visualizing large data sets and complex permissions across low bandwidth scenarios.

A contract may include one or more compliance triggers, which can be depicted visually, to limit the movement of goods or people into or out of certain spaces. In one embodiment the visual depiction literally shows the goal bounds, so that users in a warehouse operation know where to get items from, or where to put them in a warehouse.

Another example would involve the movement of people leaving an airport security area. There may be a clearly marked line that can only legally be crossed in one direction, thereby defining one example of a valid range of movement of an asset. This approach provides for visual contract validation, primarily through geometric intersections that allows multidimensional ranges and classes of object properties to be defined, thereby allowing a user to visually see the contract terms and ensure compliance in space-time.

Visualization can also serve as an input method to define the tasks to be performed in a contract. For example, a manager can be presented with a visual depiction of a warehouse on a touch-sensitive screen, which then allows the manager to point and say“move that” (geometry bounded reference)“to there” (geometric bounds). This could generate the contract, which completes when that item is moved to the correct location.

HSTP Protocol

As discussed above, in order to implement the present invention, one aspect includes a Hyperspace Transaction Protocol (HSTP), also referred to herein simply as Spatial Transaction Protocol (STP). This involves the integrating of queries, assets and transactions, as shown in Figure 14.

There are three fundamental and related message types within a spatial communication protocol:

• VIEW - a query which defines the requested viewable area as depicted by the first block in Figure 14. This is missing from purely filename-based protocols like HTTP. Hyperspace range queries of the present invention allow the viewer to specify the area and time within which they wish to view assets. Almost all online- mapping systems are based on range queries, albeit not in a standardized nor multi-dimensional manner.

• RESULT/STATE - the result of a view or transaction which provides the identity, spatial contents and interaction contracts/permissions of related assets, as depicted by the second block in Figure 14.

• TRANSACTION - an expression of an update to the state of one or more assets, in a manner that allows efficient validation against any related contracts, as depicted by the third block in Figure 14. In particular, spatial contracts often include validation of both value-bounds as well as right-to- reference constraints (i.e. permission is only given to move the object within certain spaces, and moving it into another space requires additional permissions).

Thus HSTP Protocol Packets, include Spatial View Queries that define temporal and spatial bounds for the expected results; Spatial Results, which contain individually identifiable assets with their own content payloads, as well as content specific to the query, such as a background map, and Spatial Transactions, which identify assets or areas to be manipulated, and what changes to apply on them. Considering the asset in more detail, the primary asset properties are depicted in Figure 15. These include the location information, which may also include route information, and content information. In order to facilitate economic transactions, a wallet is included.

A Contract in the present context is an expression that defines the validity of any transaction within its scope, both spatially and with respect to ownership. DIDs (Distributed Identities) are provided for the asset itself, as well as for its associated SPACE and OWNER assets, including authority endpoints and public key information for each. (DIDS or Distributed Identities are discussed in greater detail below).

The Wallet-Value is a positive scalar value representing the wallet value of an asset, which is automatically ensured to maintain total sum across a particular ledger.

The Asset depicted in Figure 15, from left to right shows LOCATION: where the asset is; and in some instances includes a ROUTE. It also includes CONTENT (data payload). The CONTRACT is the permissions expression, while the

WALLETVALUE defines the per-authority held currency value. SPACE and OWNER DIDS are references to other assets forming spatial and ownership hierarchy. PUBLIC KEY allows signed messages to be authenticated as originating from the asset itself. CONTENT specifies a directory of named content elements may be included, usually for application-specific content. In one embodiment, in order to identify a Content element, it is provided with a Content ID that is unique within a particular asset, along with one or more of a location for that content element (relative to the asset), visualization information, and external resource indicators such as images or 3d meshes. In one embodiment the content is addressed by the quantization information described in the asset’ s location (for instance if the content is pixel data, the location may describe the relative width and height of the image). Asset or Content Location - includes one or more dimensions each with a position, preferably including range and resolution, and optionally with a

transform/bounds of any inner content, quantization (count) and linear result arrangement (packing). Standard supported dimensions include X, Y, Z, LAT

(latitude), LON (longitude), ALT (altitude), and TIME, as well as custom dimensions such as TEMP (temperature) and PR (pressure). Additionally, a transform may be found on each dimension which converts from child coordinates to another dimension for rotation, scaling and general input selection/weighting.

The location comparison is illustrated in Figure 16.

The location comparisons of Figure 16 include 2D and 3D location representations, which are known in the art, and contrasts these with multi dimensional quantized range query approach of the present invention, as depicted in the third block (right-hand block). In systems such as HTML, 2D location often separates the parameters of both dimension and property (x, y, width, height). In common 3D engines the dimensions are grouped but are hardcoded to 3D dimensions, and still separate out resolution, scale, bounds, and other deeply related dimensional properties. In contrast, the multi -dimensional quantized range query approach of the present invention is to index by dimension first and embed key properties therein.

Distributed Identities (DID) are analogous to URLs but include discreetly referenceable elements needed for distributed communications. This is illustrated in Figure 17.

The elements may include:

• Asset ID - identifier of a specific asset on the ledger endpoint;

• EndPoints(s) - i.e., one or more servers which can be used for distributed consensus;

• Cryptographic Keys - for authenticated communication purposes • Service Endpoints - specifying which protocol and/or version to utilize;

• Nonce - a one-time user connection challenge results.

Referring to Figure 17, a standard URL (left side of Figure 17) is contrasted with a DID (right side). In the standard URL will be found the method, a single authority server, and the ID of the specific file on that server. In the DID will be found a similar ID of a specific asset, but critically it allows a plurality of endpoints over which consensus can be formed on the state of that asset. This is a fundamental concept required of decentralized consensus mechanisms such as blockchain, and also allows lightweight local consensus networks to form rapidly. The JSON nature of a DID also allows public keys, service endpoints, and other critical information to be embedded in this DID document.

This allows for semi-autonomous and secure interactions, by allowing users, spaces, assets and IoT devices each to have their own DID. In one embodiment, assets with the same authority endpoints are aggregated into a single connection, to creating a single web call requesting multiple different assets, and reducing communication overhead. In one embodiment, user permission is explicitly requested before establishing the connection, thus reducing the chance of exploitive or tracking assets which can leak user browsing information; much like how many email clients will not automatically download referenced images, as the downloading of those images is used to track when the email is opened, and thus making that step optional increases the privacy controls that the user has available to them.

A Decentralized Identity Systems Architecture (DID architecture) and credential proof flow is shown in Figure 18.

The DID architecture facilitates redundancy, resiliency and privacy in the technology infrastructure and organizational governance models. Multiple standards bodies and“governments” are supported through“stewards” to define and register “schemas” that can be used by“issuers” to provide“claims” to“holders” who can then use these to provide“proofs” to“verifiers”.

In a decentralized identity architecture, a network steward defines regulatory standards bodies, a standards body then defines schemas (or tag format) for specific objects (such as license types or location formats), an issuer follows those schemas providing individual credential to holders, who then prove those credentials, including source of issuance to a verifier in response to a challenge/opportunity request.

Since a practical implementation of a protocol such as HSTP entails the manipulation of assets, it is worth looking at the relationship between transactions, contracts and validation. This is illustrated in Figure 19.

HSTP Spatial Contracts are defined as expressions that given a transaction, return whether that transaction is valid or is not, primarily by intersection of the transaction with the valid contracted range. They are specifically designed for ease of visualizing, ease of spatial expression, and most critically for real-time evaluation, where their performance is a function of the number of contract operations, multiplied by the number of related dimensions.

Thus, a Spatial Contract is a multi-dimensional extension of the Smart Contract concept: defining who and in which ways a requester may interact with an asset in space. From a user’ s perspective, a spatial contract is defined as having geographic, virtual and temporal bounds which are inherently visualizable, and which can include the trade requirements for financial and other economic

transactions. Formally, we can define a spatial contract as a binary expression over a spatial transaction, including the previous and requested state of any referenced assets, that returns true if and only if the transaction is valid relative to these previous and next states. Contracts can be evaluated either with respect to the asset that contains them or with respect to assets which they own, or which are spatially registered within them (i.e. spaces/owners can have contracts that affect all assets which they contain/own). For example, purchasing an item for sale, requires approval from the item, the owner of the item, and the store or space in which it is located.

Each transaction comes in the form of a new asset update wishing to be set, preferably signed or authorized by the private key of that transaction’s

“REQUESTER” asset. Each asset update references a“TARGET” asset, and implicitly references the previous and future owner and space assets of that asset (usually three and at most five assets whose contracts must be evaluated for approval of the transaction). All these referenced assets must provide approval for the transaction, either via their own contracts or via a default contract. This cross- validation can be done very quickly, requiring at most five asset contracts as mentioned above, and there are strong halting restrictions (such as no looping or outside calls) imposed on the contract, thus achieving a model that could be used for local simulation with little overhead compared to traditional Turing-complete virtual machine approaches. Once all contracts have been evaluated and assuming all accept the request, the change is written to the ledger.

This idea of having separate contract evaluations is illustrated in Figure 20, which shows an asset contract, owner contract and space contract, each of which needs to be evaluated in this example.

Transactions are validated by both the ASSET as well as the asset’s OWNER and SPACE. This mechanism lends itself well to modelling real world contract evaluation, being affected by both product, seller and the legal jurisdiction within which the transaction occurred. Note that all contracts are evaluated with respect to which asset owns them, and can tell between a transaction modifying themselves or simply an asset referencing them. This also allows“right to reference” as assets can now allow or refuse others to reference them as either owner or space. One example of a contract may entail the movement of an asset. Certain rules have therefore been included to handle the movement of assets within assets and overlapping assets, as shown in Figure 21.

The scene graphs of Figure 21 illustrate the use of a‘transform parent’ or context SPACE. By moving the parent space, the children implicitly move with that parent space. Any spatial operations such as intersection will be achieved by establishing a common space, projecting both assets into that space, and then calculating the intersection.

Quantization was discussed above with respect to resolution. However, it also applies in the context of time. In the case of real-time communications, such as Media Streaming, it is important to support high-speed, low-latency and non-reliable transactions, such as UDP (as opposed to TCP). In one embodiment, HSTP supports these transmissions by:

• Marking the transactions as non-reliable, allowing the lower level transport layers to exclude packet ordering, etc. and send as fast as possible;

• The“time” and“resolution” properties in a spatial query can be used to adjust the quantization and thus the quantity of data being requested, both in the spatial and temporal domains.

For example, in spatial audio streaming, a user could adjust both the spatial quantization of an environment to increase detail as they approach, as well as increase the temporal resolution or frequency for more fluid movements.

HSTP is illustrated by the overview shown in Figures 22, and in more detail in the HSTP grammar of Figures 23. In broad terms, as shown in the overview of Figure 22, an HSTP packet includes a query with a VIEW and a RESULT defining an asset visually, and a TRANSACTION forming part of a visual smart contract involving the asset.

The HSTP grammar shown in Figures 23 can be expressed as JSON data - i.e., expressed as objects that can be sent over digital communication channels.

The VIEW may include a REQUESTER (the person requesting to see something), a VIEWOF (what they are looking at), and a LOCATION (which may be in various dimensions e.g. xyz, longitude/latitude, time etc, each one of which is respected as a dimension to be queried). Dimension names are not hardcoded, thereby providing greater flexibility: open in time and space.

The VIEW may further include a SEARCH that allows a requester to prioritize the results they get back from a server, e.g. by distance, price, route etc.

The REQUESTOR may include a signature - signed by a private key of the requestor and validated against a public key.

The REQUESTOR may further include LISTENON in a request, to notify the requester if a view is modified.

The STATE sent back by a server includes CONTENT (eg background) and a list of ASSETS (each asset has enough values associated with it to contractually validate any change.)

The ASSET may include:

an ID,

an OWNER (who owns it),

a SPACE with an ID and Ledger String, and a LOCATION (where does it exist in space - which supports any coordinate system, and also supports a point (value) and a range (min and max), and resolution for the SPACE.

The LOCATION can have multiple dimensions with bounded ranges.

The ASSET, typically also includes a ROUTE. Thus, LOCATION specifies where an asset currently is, while ROUTE defines where the asset wants to go, which is valuable for example in shipping, e.g., can use ROUTE to verify that asset is on the route and once validated, the LOCATION is allowed to change.

By defining both the space and the owner as part of the HSTP, it allows them to exist on separate ledgers (separate from the asset itself). Thus, the SPACE can for instance be on a blockchain and verified by the blockchain, while the OWNER can be verified by biometric validation, and the asset respects both instances but exists on a separate platform e.g. cloud-based for real-time interaction.

The ASSET may further include a WALLETVALUE, and the ASSET may be associated with a CONTRACT which defines what can be done with an asset and with any CONTENT.

The ASSET may include a default CONTRACT that is associated with it, e.g., “If I am not the owner the change can be made, but if I am the owner it can be made only if I’m also the REQUESTER.”

For example, an ASSET may comprise a spatial region on a map defined as being owned by a particular party. The CONTENT may be a spatially anchored 3D model or photograph, e.g., a floating text, logo or website over the space. The ASSET may include a PUBLICSIGNINGKEY which allows an asset to act for itself - so it may validate that a change came from the asset itself. This is common in HTTPS web authentication where a private key is kept by the server, and used to sign packets as coming from them during the initial connection handshake. Also, the ASSET may include a DISPLAY name, in different languages, useful in describing what the asset represents to human users.

As discussed above, TRANSACTIONS allow a REQUESTER to make changes to ASSETS. Each transactional change can include multiple steps that may have different REQUESTERS - but they can be stored in one block and processed as one block. Thus, a TRANSACTION would be a block requesting the changes within that block.

To make a change to an asset, that asset, the space, and the owner all have to agree. This achieves a right to reference. In a simple example: I cannot put a for sale sign on your property even though I own the sign (the asset). So, in this example, even though ASSET and OWNER agree, they cannot perform the change since they don’t control the SPACE.

A detailed overview of the major components within a full ledger implementation are shown below:

• Application/Host

o User/System Interfaces

Configures Views / Auto-Registers Assets Presents Assets

Interacts with Assets

Configures External Connections

o Local Ledger (SDK) Functionality

View Management Requester Identification

Retrieves Assets

Core Properties

Contents

Data payload

UI Elements

Transaction Helper APIs

Known Asset Cache

Indexed by ID, LEDGER/AUTH and VIEW

Asset Version and View Subscription Tracking Local/Temp Asset Tag Management

View-based Reference Counting

Contract Validation Kernel

Collects Referenced Assets (must be Cached) Contract Expression Evaluation

Can Apply Transactions Once Validated

Connections

External Services/Endpoints

Identity Validation (via Asset Cache Public-Keys) Data Adaptation when required

Consensus Mechanics

Encryption Tools

Hashing and Signing with Private Keys

Verification of Public Key Signatures/Hashes Nonce/Key-Pair Generation

Offer/Claim/Schema/Credential Processing

In support of the HSTP, the present invention provides a Java Script software development kit (SDK) which includes spatial calculations, ledger interfaces, and contract validation. An example of an SDK for a data query in JavaScript is shown in Figure 24.

In this example, the lat/lon (latitude and longitude), range and quantization is specified, along with the selected map and water-depth data dimensions being requested.

An example of a data query result is shown in Figure 25. In this example, a very small 3x3 packed background map content element is returned, along with two assets on that map representing a large rock and small boat in integer range.

Figure 26 shows an example of a transaction in which a requester“MyCaptain” is updating the location of“MyBoat”. Note that authentication of this requester is outside of the scope of this packet and presumed to be via HTTPS or via an encrypted HSTPS packet (HSTP being HSTP Secured, which is a binary encrypted wrapping of an HSTP packet, see HSTPS_BUFFER in Figure 23, the full schema definition).

Contract Grammar:

The TRANSACTION can have a graph-oriented layout (graph database) or a relational table layout.

Thus, the contract grammar can be done in JavaScript, but in a preferred embodiment, a graph-oriented back-end is used, with JSON for transmission. This allows for easy visualization of the transaction by having CONTRACT,

EXPRESSION, LOCATION, PROPERTY.

In another embodiment a relational database table structure is used for storing ASSET states, to store ASSETS, LOCATIONS, CONTENTS, TRANSFORMS, and DISPLAYS, each with ID and Ledger value. As mentioned above, ranges provided for in HSTP, allow for the location to be specified: INSIDE, OUTSIDE, TOUCHING (e.g., you are allowed to move an asset even if you don’t own it as long as you move it only INSIDE a space).

By specifying the details of a contract and a wallet, a buyer can execute the contract without re-validation by a seller provided the transaction is in conformity with the contract terms. For example, there might be an item of a certain price owned by a certain owner, that is on a ledger. Similarly, there might be another asset: a wallet, with an owner (requester), and a wallet value, also on a ledger. No changes are allowed between the two assets since they define two assets in the transaction.

In the present application, the core protocol is independent of server implementation. This is a critical topic for the ecosystem, and conceptually ensures efficient computation and through connected implementations across in-memory, peer-2-peer, cloud, and distributed consensus networks.

Spatial Domain Server

A top-level domain system, such as the Internet’s DNS .com/etc. system for string-based names is deeply valuable as a starting point for spatial browsing and can act as a trusted source for fundamental spatial ownership, which is an important topic in political sovereignty.

One aspect of the present invention is a“Spatial Domain Server” to provide location-based looking up of spatial asset and ownership information in this regard, which is critical to both spatial content retrieval, but also spatial transaction validation, whereby the rules for particular areas can be described as spatial permissions in their associated assets. Laws, codes of conduct and economic opportunities can thus be digitally expressed and enforced. Spatial assets, which typically are either virtual or have a geographic location, are usually organized into spatial domains that serve as resource-locator function in much the same way as relative file paths do on an intranet (e.g.

\\CompanyServer\HumanResources\EmployeePerformanceReviews) or domain names do (e.g., http://www.myDomain.com) in the Internet’s HTTP-based DNS (domain name system). The present Spatial Domain Service helps resolve spatial locations against one or more smart asset domains on a centrally managed Spatial Index. Content can then be accessed by inputting these“spatial domains” into a “spatial browser” that could serve as the primary user interface for most human users, in much the same way that IP addresses provided by the DNS server can be used to query individual pages. Machines (e.g. intelligent agents) can also use spatial domains to locate content in a similar manner.

Within the protocol, spatial assets can even conduct business with one another. Specifically,“spatial contracts” can be created and implemented between any two or more entities within the ecosystem, be they human or machine-based.

The spatial contract model is based on an extension of the smart contract concept typically associated with cryptocurrencies (most notably Ethereum), namely as sets of permission expressions, which may be backed by a blockchain ledger and/or internal testability systems that compartmentalize sets of behaviors within each Space or Asset and allows them to interact with other spaces or assets.

To illustrate, in one embodiment: each transaction comes in the form of a new asset update to be applied, preferably signed or authorized by the private key of a known spatial asset in order to provide authentication. This update request to an asset includes a reference to the asset to be changed, along with information concerning the future authority and space for that asset if appropriate. It can be combined with a copy of the asset’ s previous state, with references to its previous authority and space. All referenced assets, such as owners and spaces, are then cached along with their respective contracts, which are then asked to validate the request. In one embodiment, this cross-validation can be done very quickly, as the architecture only allows at most five (5) possible contracts to be validated per asset transaction (the asset, it’s former and next space, and it’s former and next owner), along with strong halting restrictions (i.e. no looping or outside function calls), thus achieving a model with little overhead compared to non-validated updates, while still benefiting from increased security. Once all changes and related contracts on the proposed transactions have been evaluated and approved, the changes are recorded on one or more ledgers used by the system. In summary, transactions express changes to assets, while contracts express the validation of those changes; once all validations have been acquired, a ledger is authorized to officially apply those changes.

The Spatial Domain Service may also include a protocol native token (VSS), which is associated with this common spatial domain server, thereby facilitating a new generation of spatial contracting and trade mechanisms.

The indexing of assets based on location rather than filename was discussed above. The core of any spatial server is the ability not only to return assets based on identifiers, but more importantly to efficiently find and prioritize assets which fit within a specific spatial query, which is referred to herein as a“spatial index”. This may be implemented using numerous mechanisms, from simple SQL indexes to graph-based databases, as well as interfaces to widely adopted and standard spatial indexing services such as ESRI’s ArcGIS Cloud and Open Street Maps which deliver enterprise quality spatial indexing.

When it comes to traditional content that needs to be transmitted, the assets themselves may either include relatively small pieces of content or more usually URL references to external content. For purposes of the present application, the standards for this content generally follow MIME guidelines, while making use of spatial transforms to place these pieces of content into appropriate locations (when in 3D viewers). The following formats are supported in our current spatial browser implementation, but could be extended in future:

• Image: JPEG, PNG, GIF - displayed in local coordinates to the asset and using a spatial unit plane, with option to face the viewer.

• Video: MP4, AVI, HLS, H.264, H.265. Video format support will depend on partner platform choices.

• Text: Plain-Text, Embedded HTML, URL-Link: Generally shown as a string, with or without basic formatting, or as an optional link for a user to go further.

• 3D File Formats: OBJ(+ mtl), GLTF (OpenGL Transport Format), USDZ (Apple/Pixar), Three.js JSON scene format. It will be appreciated that support may be extended to other formats.

• GIS Formats: GEOJson, KML, Shapefile. It will be appreciated that others can be supported if need be, but these should be supported across browsers, and have natural world coordinates for spatialization.

The final result of a quantized range query over a scene graph is commonly in the form of one or more rendered samples, often visual images, but also sometimes as collision/sensor data (such as an IoT (Internet of Things) device asking for a spatial model of its surroundings). For this reason, the query protocol is effectively equivalent to a rendering query where the final image/volumetric resolution and even temporal resolution can be specified.

End-users may access the system in a number of ways, including: smart phones, tablets, goggles, such as those used in virtual reality applications like the Oculus Rift or HTC Vive; smart glasses, heads-up-displays such Google’s“Glass”, etc. Within the wearable unit, a“Spatial Operating System” (“Reality OS”) centered around the aforementioned“spatial browser” will display both real and virtual smart assets according to their respective scenegraphs and the user’ s current viewing preferences. In one embodiment, users can then view, edit, download and upload information and multimedia content within any space using the virtual (or augmented) reality style graphical user interface that serves as their“window” to the integrated physical and virtual world. Smart contract capabilities will then be integrated into the system, allowing for spatial assets to be the subject of rule-based commercial activity (i.e. smart contracts) whether involving the exchange of money, goods, services or information.

Potential applications for the invented protocol will be readily apparent to those reasonably skilled in the art. For example, a“spatial web-enabled” supply chain could be represented in systems and/or geographically to view the movement of people and assets through“smart spaces,” creating a linked chain of transactions that can be tracked according to their specific positions, without requiring explicit paperwork, as visually tracked assets and automatically complete their required transactions.

The entire workflow can be run as a simulation showing the estimated pools, gates, sinks (i.e. areas for potential efficiency gains) and other efficiency/throughput impacting mechanisms in the supply economy, and allowing the user to adjust tunable settings and amounts to visualize the results across the entire chain. In fact, entire business processes and workflows can be viewed using the Spatial Index, allowing for the tracking of objects, information, people and virtually any other workflow element across any given geographic, celestial and/or virtual area. One example would be in the visualizing and handling of real-estate transactions.

In alternative embodiments, the protocol also factors in temporal and frequency dimensions (e.g. wavelength or periodicity) of spatial assets. It should be noted that both the foregoing embodiment and any other listed embodiments are intended for illustration purposes only. They should not be deemed exclusive of any additional modes of use known or to be developed in the future.

Claims

CLAIMS What is claimed is:

1. A spatial transaction protocol (STP) for spatial querying, returning spatial content and assets, and for requesting changes to those assets, comprising spatial quantized range queries for requesting assets in a certain area, spatial transactions over those assets or ranges,

spatial smart contracts to validate transactions and define what may be done with an asset, and

a decentralized identity referencing mechanism to support multi-party consensus ledgers and cross-ledger contracting.

2. An STP of claim 1, wherein spatial quantized range queries include one or more of: asset definitions, spatial location information, spatial resolution information, spatial packing information, and spatial content information.

3. An STP of claim 1, further including means for at least one of wallet

modeling, and cross-ledger contracting facilitating atomic swaps.

4. An STP of claim 1, wherein a spatial quantized range query includes a view defined by a range and a basis space and content graph of existing visible features, that is sent to a server or peer node and specifies what a requestor would like to see, and a result (state) of that view, which is sent back by the server or peer node.

5. An STP of claim 1, wherein the spatial smart contracts are expressed as an interpretable JSON expression, and provide bounded evaluation time.

6. A Spatial Transaction Protocol (STP), which includes:

a spatial quantized range query, comprising

a view defined by a range and a space that is sent to a server or peer node and specifies what a requestor would like to see,

a result of that view, which is sent back to the requester, and a transaction protocol to change the assets.

7. An STP of claim 6, wherein the view includes one or more of requestor information, cryptographic signature information, existing requester visible information for view estimation, and location information.

8. An STP of claim 7, wherein the location information is defined in various dimensions and is not hard coded in the STP.

9. An STP of claim 8, wherein the dimensions include one or more of xyz, longitude/latitude, and time.

10. An STP of claim 9, wherein the view, further includes a search field, and vector or profile id for prioritizing the results of the view.

11. An STP of Claim 7, wherein the requestor information includes a signature.

12. An STP of claim 11, wherein the signature comprises a signature by a private key of a requestor that can be validated against a public key.

13. An STP of claim 7, wherein the requestor information further includes means to notify the requester if the view is modified (subscription mechanism).

14. An STP of claim 10, wherein the result of the view includes:

background content, and a list of assets.

15. An STP of claim 14, wherein each asset includes sufficient values to

contractually validate any change.

16. An STP of claim 15, wherein the asset may include

An asset ID, with authority information,

an OWNER asset ID for the asset, with authority information,

a SPACE asset ID for the asset, with authority information,

a location,

contained content, and

a permissible transaction contract

17. An STP of claim 16, wherein the asset ID includes a public key and one or more consensus authorities.

18. An STP of claim 16, wherein the location supports multiple coordinate systems, expressed as at least one of a point value and a quantized range.

19. An STP of claim 18, wherein the location further supports providing

resolutions for each dimension of the space.

20. An STP of claim 7, where the STP further includes dimensional packing information.

21. An STP of Claim 16, wherein the asset further includes space and time route information.

22. An STP of Claim 16, wherein the asset further includes a wallet value of the asset.

23. An STP of Claim 16, wherein the asset is associated with a contract which defines what can be done with the asset and with any content.

24. An STP of Claim 23, wherein the asset further defines a default contract associated with the asset, which requires that any change to an asset can only be made if the owner or asset itself is also the requester.

25. An STP of Claim 16, wherein the ASSET further includes a public signing key, which allows an asset to validate transactions as being requested from itself.

26. A method of managing a spatial domain, and actions within that domain, by representing the domain as an asset, wherein the asset information includes at least one of spatial location information, spatial permissioning information, and user validation.

27. A method of claim 26, wherein spatial permissioning information includes governance of permissible transactions on the asset itself, as well as on other assets within its domain.

28. A method of claim 26, wherein the spatial location information includes at least one coordinate system, a point value, and a range.

29. A method of claim 26, wherein the asset is a physical or virtual asset.

30. A method of transmitting and storing spatial information, as interconnected assets, comprising creating packets that include:

a packet type comprising at least one of query, result, and transaction;

at least one of target asset ID and location,

a set of asset definitions, wherein the asset definitions include at least one of identity, owner, space, location, content, contract, and wallet- value.

31. A method of claim 30, wherein the location supports multiple coordinate systems.

32. A method of claim 31, wherein location includes a range.

33. A method of claim 32, wherein the location further supports a resolution for the space.

34. A method of Claim 33, wherein the asset further includes route information.

35. A method of decentralized routing comprising routing of packets based on at least one of their spatial destinations, relative spatial locations, and spatial permission contract.

36. A spatial domain system (SDS) for real and virtual assets, comprising

an asset ID

an associated authentication key,

an owner ID of the asset,

a space ID of the space that the asset exists within, and

a location.

37. An SDS of claim 36, wherein the location supports multiple coordinate systems, each comprising at least one of a point value, and a range.

38. An SDS of claim 36, wherein the location further supports a resolution for the space.

39. A spatial browser for interacting with a spatial network via requests,

comprising

view query code defining a range and a space related to a view query,

state code for viewing information received in response to a view query, and a transaction code to create or change assets and their associated attributes.

40. A spatial browser of claim 39, wherein the requests include requester information and supporting authentication material.

41. A spatial browser of claim 40, wherein the location information is defined in various dimensions and is not hard coded in the view query code.

42. A method of managing inventory tasks, comprising

defining items in inventory as assets, wherein the asset definition includes, spatial information and contracting information, that expresses tasks as permissions within temporal and spatial bounded routes.

43. A method of claim 42, wherein the spatial information further includes user validation information.

44. A method of claim 43, further comprising generating virtual assets for physical assets.

45. A method of claim 44, comprising spatially anchoring the virtual assets relative to one or more reference asset locations.

46. A method of validating the movement of goods from one location to another location, comprising

defining at least one of goods and containers housing the goods, as assets,

associating spatial information with each asset, wherein the spatial information includes an asset transaction permission contract.

47. A method of Claim 46, wherein spatial transaction permission contract further includes route information.

48. A method of claim 46, further comprising associating bill of lading

information with the spatial information.

49. A method of claim 46, wherein the asset includes information about relative location of an asset within another asset.

50. A method of claim 46, wherein a valid range of movement of the asset is visualized as part of a view query, and may be defined in various dimensions, and is not hard coded in the view query.

51. A method of claim 50, wherein the dimensions include at least one of time, temperature, location, and pressure.

52. A method of claim 46, wherein the asset includes at least one of a signature, public key, and biometric information.

53. A method of claim 52, wherein the signature includes a cryptographic

signature of a requester that can be validated against a public key.

54. A method of providing an authenticated checkout for goods sold to

purchasers by a store, comprising

defining the goods or groups of goods, purchasers, and the store as assets, and associating spatial information with each asset, wherein the asset information includes an asset transaction permission contract.

55. A method of claim 54, further comprising capturing at least one of user validation information, and payment information.

56. A method of claim 54, further comprising generating a view of the assets.

57. A method of claim 56, comprising locating the assets relative to one or more references based on the spatial information.

58. A method of managing traffic to enable collaboration between vehicles, comprising

associating spatial information with each vehicle, wherein the vehicles, roads and nearby entities are defined as assets and the spatial information includes a spatial permission contract communicating one vehicle’s responses to physical and digital signals from other assets.

59. A method of claim 58, wherein the vehicle is a land, airborne or waterborne vehicle.

60. A method of claim 58, wherein the spatial information, further includes spatial content information, comprising at least one of visualization models, collision estimation models, and routing models.

61. A method of claim 60, wherein the spatial information includes one or more coordinate systems, defined and aligned by a scene graph of visual recognition feature points.

62. A method of claim 58, wherein the communicated spatial information varies relative to the resolution of a requesting view query of a particular communication.