WO2020051160A1 - Protocole de transaction spatiale - Google Patents

Protocole de transaction spatiale Download PDF

Info

Publication number
WO2020051160A1
WO2020051160A1 PCT/US2019/049398 US2019049398W WO2020051160A1 WO 2020051160 A1 WO2020051160 A1 WO 2020051160A1 US 2019049398 W US2019049398 W US 2019049398W WO 2020051160 A1 WO2020051160 A1 WO 2020051160A1
Authority
WO
WIPO (PCT)
Prior art keywords
spatial
asset
information
assets
stp
Prior art date
Application number
PCT/US2019/049398
Other languages
English (en)
Inventor
Dan Raymond MAPES
Gabriel Joseph Bradley RENE
Lewey Alec Geselowitz
Toby TREMAYNE
Original Assignee
Cyberlab Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cyberlab Llc filed Critical Cyberlab Llc
Publication of WO2020051160A1 publication Critical patent/WO2020051160A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the invention relates to the field of computer communication protocols and the exchange of spatial content.
  • 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.
  • 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.
  • STP Ses Physical Transaction Protocol
  • HTP Hyperspace Transaction Protocol
  • 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).
  • 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
  • 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.
  • 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.
  • HSTP Spatial Transaction Protocol
  • HSTP Spatial Transaction Protocol
  • 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.
  • a Hyperspace transaction protocol 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.
  • 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.
  • 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.
  • a spatial transaction protocol 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,
  • 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.
  • STP Spatial Transaction Protocol
  • a spatial quantized range query comprising
  • 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,
  • 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.
  • 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
  • a packet type comprising at least one of query, result, and transaction
  • 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.
  • 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.
  • SDS spatial domain system
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIGS. 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.
  • Figure 26 is an example of a transaction in accordance with one embodiment of the present invention. Detailed Description of the Invention
  • 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.
  • STP Spatial Transaction Protocol
  • HSTP Hyperspace Transfer Protocol
  • 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).
  • 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.
  • a network of connected information systems can be depicted by a human body.
  • AI artificial intelligence
  • AR/VR augmented reality/virtual reality
  • NLP Natural Language Processor
  • Robotics as depicted by muscles
  • Actuators IoT, etc.
  • HSTP can be seen as the perceptual groupings (assets) and spatial/dimensional relationships, along with their permissible (expected and reactionary) transactions.
  • 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.
  • 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
  • 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”
  • 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.
  • 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 protocol of the present invention 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.
  • domains are spaces that confer rights.
  • 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.
  • a global domain 200 defining the entire building and surrounding parking lot.
  • 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).
  • 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.
  • the exterior space can be defined by GPS (Global Positioning System) coordinates, while the internal space is Virtually Addressed.
  • VPS Virtual Positioning System
  • VPS Virtual Positioning System
  • 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.
  • this can be implemented by embedding reference locations - or virtual“landmarks” - into the query.
  • an asset e.g. a person
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the assets can form the nodes in the graph database, with their relationships (ontological space) defined by the edges between the nodes.
  • 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.
  • 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.
  • the spatial index is stored on an ESRI ArcGIS instance, which include very efficient geo spatial indexing and querying mechanisms.
  • the Spatial Index has the following information for each spatial asset:
  • ID - asset identifier 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 of the asset
  • 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.
  • 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:
  • 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.
  • HSTP uniquely replaces HTTP, HTML and JavaScript in the browser stack.
  • the visualization and spatial anchoring of assets and contracts are performed by means of spatial queries.
  • geo located assets this can be done in standard latitude/longitude space
  • 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.
  • the core SPACE property on each asset defines the spatial basis or“parent” asset, and spatial calculations are made relative to that asset.
  • Figure 5A shows a list of assets
  • Figure 5B shows a map scene as is common in map applications such as Google Maps.
  • 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.
  • Multidimensional quantized range queries as a basis for the network protocol
  • 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”).
  • URL Uniform Resource Locator
  • multi -dimensional refers to other attributes beyond purely spatial dimensions.
  • 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.
  • 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.
  • assets in the scene may be quantized as shown in Figure 7B to define a scene that is composed of multiple quantized elements.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • 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 defines the format of the resulting image.
  • the Maps Static API creates PNG images.
  • 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.
  • latitude ⁇ min/max/count ⁇
  • longitude ⁇ min/max/count ⁇
  • 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.
  • 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.
  • 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.
  • 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.
  • a perspective-normalization dimension in one embodiment explicitly named“1”
  • n-dimensional“perspective” projection in which nearby objects appear larger than further away objects, common in 3D perspective rendering.
  • Figure 8C 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.
  • ranges were included in order to define assets and space that have size.
  • 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.
  • 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).
  • each row can define a separate location
  • each column can define a dimension.
  • each cell in the matrix can include a range.
  • 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.
  • 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 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.
  • 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.
  • 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 ⁇ ⁇
  • the next aspect to consider in a practical application is the movement of assets and interaction with those assets.
  • the vehicles where the vehicles are defined as assets
  • 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
  • the present HSTP protocol adopts a visual approach to implementing smart contracts, as is discussed in more detail below.
  • 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.
  • CSG Consstructive Solid Geometry
  • 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.
  • the present approach 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.
  • 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.
  • traditional data entries such as tasks in the warehouse, are converted into spatial assets and contracts.
  • 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’.
  • 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.
  • 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.
  • 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.
  • 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.
  • Adapter The three components: Adapter, Spatialization, Contracting are depicted in Figure 12.
  • 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.
  • 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).
  • the application interacts with the SDK by creating "views" (spatial queries), that request assets.
  • 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.
  • asset cache is entirely in memory
  • 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.
  • 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).
  • 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.
  • a remote controller asset such an owner or space
  • 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.
  • permissions are themselves expressed as shapes, which is natively capable of defining a geospatial model that can express geospatial transactions.
  • every ID is not only a string but a series of authority endpoints (i.e. official record keepers).
  • every reference to an asset in this embodiment includes the asset’s list of authority endpoints.
  • 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.
  • spatialization can include ROUTE, which is a collection of LOCATIONS, often with separate TIMES for each location.
  • each ledger will have its own concept of currency, and every valid transaction will typically not change the total currency in the system.
  • 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.
  • 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.
  • 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).
  • 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.
  • SDK Software Development Kit
  • 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.
  • 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.
  • Hyperspace Transaction Protocol also referred to herein simply as Spatial Transaction Protocol (STP). This involves the integrating of queries, assets and transactions, as shown in Figure 14.
  • STP Spatial Transaction Protocol
  • 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.
  • 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).
  • 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.
  • 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
  • Spatial Transactions which identify assets or areas to be manipulated, and what changes to apply on them.
  • 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
  • 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).
  • 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.
  • 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.
  • 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
  • Standard supported dimensions include X, Y, Z, LAT
  • 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 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).
  • 2D location often separates the parameters of both dimension and property (x, y, width, height).
  • 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.
  • the multi -dimensional quantized range query approach of the present invention is to index by dimension first and embed key properties therein.
  • DID Distributed Identities
  • the elements may include:
  • EndPoints(s) - i.e., one or more servers which can be used for distributed consensus;
  • a standard URL (left side of Figure 17) is contrasted with a DID (right side).
  • the standard URL will be found the method, a single authority server, and the ID of the specific file on that server.
  • 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.
  • 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.
  • 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.
  • DID architecture Decentralized Identity Systems Architecture
  • 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”.
  • 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.
  • 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.
  • 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
  • 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
  • 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.
  • Figure 20 shows an asset contract, owner contract and space contract, each of which needs to be evaluated in this example.
  • the scene graphs of Figure 21 illustrate the use of a‘transform parent’ or context SPACE.
  • 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.
  • HSTP supports these transmissions by:
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • both the space and the owner 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).
  • 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.”
  • 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.
  • the ASSET may include a DISPLAY name, in different languages, useful in describing what the asset represents to human users.
  • 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.
  • a TRANSACTION would be a block requesting the changes within that block.
  • SDK o Local Ledger
  • the present invention provides a Java Script software development kit (SDK) which includes spatial calculations, ledger interfaces, and contract validation.
  • SDK Java Script software development kit
  • An example of an SDK for a data query in JavaScript is shown in Figure 24.
  • the lat/lon (latitude and longitude), range and quantization is specified, along with the selected map and water-depth data dimensions being requested.
  • FIG. 25 An example of a data query result is shown in Figure 25.
  • 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.
  • FIG 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).
  • the TRANSACTION can have a graph-oriented layout (graph database) or a relational table layout.
  • 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,
  • 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.
  • ASSET states to store ASSETS, LOCATIONS, CONTENTS, TRANSFORMS, and DISPLAYS, each with ID and Ledger value.
  • 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).
  • 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.
  • 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.
  • 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
  • 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
  • spatial assets can even conduct business with one another.
  • 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.
  • 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.
  • 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.
  • the changes are recorded on one or more ledgers used by the system.
  • 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.
  • VSS protocol native token
  • 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.
  • the assets themselves may either include relatively small pieces of content or more usually URL references to external content.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the protocol also factors in temporal and frequency dimensions (e.g. wavelength or periodicity) of spatial assets.
  • temporal and frequency dimensions e.g. wavelength or periodicity

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Finance (AREA)
  • Marketing (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Dans un protocole de transaction spatiale, des interrogations spatiales, des transactions spatiales et des contrats spatiaux sont communiqués de manière appropriée pour un mélange dynamique de registres en temps réel, à autorité unique et décentralisés. Ceci permet aux espaces et aux autorités individuels de contracter de manière interactive des transactions d'entrée, de sortie et de mouvement au sein de leurs domaines ; et à ces mécanismes d'être interrogés avec une fidélité et une utilisation de bande passante appropriées en termes de résolution.
PCT/US2019/049398 2018-09-03 2019-09-03 Protocole de transaction spatiale WO2020051160A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201862726312P 2018-09-03 2018-09-03
US62/726,312 2018-09-03

Publications (1)

Publication Number Publication Date
WO2020051160A1 true WO2020051160A1 (fr) 2020-03-12

Family

ID=69723249

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2019/049398 WO2020051160A1 (fr) 2018-09-03 2019-09-03 Protocole de transaction spatiale

Country Status (1)

Country Link
WO (1) WO2020051160A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102020215817A1 (de) 2020-12-14 2022-06-15 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Verwalten eines Dienstes in einem dezentralen Transaktionssystem
US11558344B1 (en) * 2020-09-28 2023-01-17 Unstoppable Domains Inc. Resolving blockchain domains
US11886425B2 (en) 2021-01-13 2024-01-30 Unstoppable Domains Inc. Blockchain registry scaling
EP4328781A1 (fr) * 2022-08-26 2024-02-28 Siemens Aktiengesellschaft Procédé et système pour améliorer la qualité et la précision de données d'une pluralité de jumeaux numériques interagissant dans un environnement collaboratif simulé par ordinateur sur un réseau distribué

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060085477A1 (en) * 2004-10-01 2006-04-20 Ricoh Company, Ltd. Techniques for retrieving documents using an image capture device
US20070118542A1 (en) * 2005-03-30 2007-05-24 Peter Sweeney System, Method and Computer Program for Faceted Classification Synthesis
US20120047160A1 (en) * 2010-08-17 2012-02-23 Fujitsu Limited Querying sensor data stored as binary decision diagrams

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060085477A1 (en) * 2004-10-01 2006-04-20 Ricoh Company, Ltd. Techniques for retrieving documents using an image capture device
US20070118542A1 (en) * 2005-03-30 2007-05-24 Peter Sweeney System, Method and Computer Program for Faceted Classification Synthesis
US20120047160A1 (en) * 2010-08-17 2012-02-23 Fujitsu Limited Querying sensor data stored as binary decision diagrams

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11558344B1 (en) * 2020-09-28 2023-01-17 Unstoppable Domains Inc. Resolving blockchain domains
US20230171225A1 (en) * 2020-09-28 2023-06-01 Unstoppable Domains Inc. Resolving blockchain domains
US11876774B2 (en) 2020-09-28 2024-01-16 Unstoppable Domains Inc. Resolving blockchain domains
US11985252B1 (en) 2020-09-28 2024-05-14 Unstoppable Domains Inc. Resolving and managing blockchain domains
DE102020215817A1 (de) 2020-12-14 2022-06-15 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Verwalten eines Dienstes in einem dezentralen Transaktionssystem
US11886425B2 (en) 2021-01-13 2024-01-30 Unstoppable Domains Inc. Blockchain registry scaling
EP4328781A1 (fr) * 2022-08-26 2024-02-28 Siemens Aktiengesellschaft Procédé et système pour améliorer la qualité et la précision de données d'une pluralité de jumeaux numériques interagissant dans un environnement collaboratif simulé par ordinateur sur un réseau distribué
WO2024042153A1 (fr) * 2022-08-26 2024-02-29 Siemens Aktiengesellschaft Procédé et système pour améliorer la qualité et la précision de données d'une pluralité de jumeaux numériques interagissant dans un environnement collaboratif simulé par ordinateur sur un réseau distribué

Similar Documents

Publication Publication Date Title
WO2020051160A1 (fr) Protocole de transaction spatiale
US11450123B2 (en) Analytic image format for visual computing
US11068757B2 (en) Analytic image format for visual computing
Bhattacharya et al. Coalition of 6G and blockchain in AR/VR space: Challenges and future directions
US11475176B2 (en) Method and system for automatically ordering and fulfilling architecture, design and construction product sample requests
Bhattacharya et al. Towards future internet: The metaverse perspective for diverse industrial applications
Geppert et al. Privacy preserving structure-from-motion
CA3000700A1 (fr) Procedes et systemes pour selectionner et analyser des donnees geospatiales sur un systeme de grilles globales discretes
Xie et al. Feature representation matters: End-to-end learning for reference-based image super-resolution
Yao et al. As‐global‐as‐possible stereo matching with adaptive smoothness prior
US20210090302A1 (en) Encoding Three-Dimensional Data For Processing By Capsule Neural Networks
CN116957893B (zh) 水印生成方法、装置、电子设备和计算机可读介质
US10970330B1 (en) Method of searching images using rotational gesture input
Brenner et al. Continuous generalization for small mobile displays
CN115114360A (zh) 数据对比方法、装置、计算机设备、存储介质
CA2961985A1 (fr) Production de carte personnalisee associee a des messages en temps reel et emplacement des utilisateurs concurrents
Jobst et al. Accessing spatial knowledge networks with maps
Barik et al. Investigations into the Efficacy of Open Source GIS Software
Li et al. Deep surface normal estimation on the 2-sphere with confidence guided semantic attention
Ahmad Object Recognition in 3D data using Capsules
Liu et al. An effective spherical panoramic LoD model for a mobile street view service
Fu [Retracted] Application and Analysis of RGB‐D Salient Object Detection in Photographic Camera Vision Processing
Hart Selection-Based Convolution for Irregular Images and Graph Data
Klimke et al. Web-based and mobile provisioning of virtual 3d reconstructions
Zborovskiy Representing and manipulating spatial data in interoperable systems and its industrial applications

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19857626

Country of ref document: EP

Kind code of ref document: A1