US20190335300A1 - Methods and systems for generating maps corresponding to physical spaces, devices, and/or users - Google Patents
Methods and systems for generating maps corresponding to physical spaces, devices, and/or users Download PDFInfo
- Publication number
- US20190335300A1 US20190335300A1 US15/964,751 US201815964751A US2019335300A1 US 20190335300 A1 US20190335300 A1 US 20190335300A1 US 201815964751 A US201815964751 A US 201815964751A US 2019335300 A1 US2019335300 A1 US 2019335300A1
- Authority
- US
- United States
- Prior art keywords
- node
- map
- nodes
- area
- physical space
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/029—Location-based management or tracking services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
- G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
- G01C21/20—Instruments for performing navigational calculations
- G01C21/206—Instruments for performing navigational calculations specially adapted for indoor navigation
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
- G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
- G01C21/38—Electronic maps specially adapted for navigation; Updating thereof
- G01C21/3804—Creation or updating of map data
- G01C21/3833—Creation or updating of map data characterised by the source of data
- G01C21/3841—Data obtained from two or more sources, e.g. probe vehicles
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
- G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
- G01C21/38—Electronic maps specially adapted for navigation; Updating thereof
- G01C21/3863—Structures of map data
- G01C21/387—Organisation of map data, e.g. version management or database structures
- G01C21/3878—Hierarchical structures, e.g. layering
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/021—Services related to particular areas, e.g. point of interest [POI] services, venue services or geofences
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/02—Services making use of location information
- H04W4/023—Services making use of location information using mutual or relative location information between multiple location based services [LBS] targets or of distance thresholds
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/33—Services specially adapted for particular environments, situations or purposes for indoor environments, e.g. buildings
Definitions
- Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, accounting, etc.) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data.
- tasks e.g., word processing, scheduling, accounting, etc.
- IoT devices are network-connected devices that are placed in many physical spaces to enable people to interact with and gather information about their environment.
- offices or homes may include numerous IoT devices that can be used to control locks, to manage indoor climate and receive climate information, to manage lighting and receive lighting information, to open and close doors, to perform cleaning functions, to control audio and/or video equipment, to provide voice interaction, to provide security and monitoring capabilities, etc.
- IoT devices can process and generate vast amounts of information.
- IoT devices are not limited to use in structures such as offices or homes.
- IoT devices may be used to track any manner of physical items (including, for example, animals such as livestock or pets), to monitor health of people or animals, and so forth.
- IoT devices As IoT devices proliferate, it is becoming increasingly difficult to manage the devices and their users, and to process the data they generate. Notably, it may often be difficult to intuitively manage and group such devices (e.g., based on physical space or synergistic functionality), to efficiently control these devices (including controlling user access), to efficiently access data associated with these devices and/or to efficiently visualize live sensor data associated with these devices in relation to a physical space.
- managing IoT devices could involve storing large amounts of data associated with the physical environment in which they exist (e.g., buildings with their floors, rooms, room types, objects the rooms, etc.).
- large numbers of devices may also result in enormous amounts of generated data (e.g., sensor data) that may be difficult to manage and access, and to link to the physical environment.
- IoT-related data generally includes first data that is relatively static (e.g., data relating to the physical environment in which the IoT devices exist), and data that is more dynamic (e.g., sensor data generated by the IoT devices, themselves).
- the inventors have invented a multi-database environment for storing such data.
- the multi-database environment can include one or more first data structures (e.g., one or more graphs) that store relatively static information in the form of a topology of the physical environment in which the IoT devices exist, including storing references to the devices themselves and users associated with spaces in the physical environment and/or with devices.
- the first data structure(s) are configured to facilitate queries that can quickly identify physical spaces, users, and/or IoT device(s) within physical spaces—regardless of the size of the topology; quick queries could mean a tradeoff that operations updating the first data structure(s) is comparatively expensive.
- the first data structure may also include map data corresponding to a particular node of the first data structure, wherein the map data is associated with at least a portion of a map corresponding to the given node. As such, the map data may be used to generate the portion of the map corresponding to the given node.
- the multi-database environment can also include one or more second data structures that store relatively dynamic information, such as sensor data generated by the IoT devices.
- the second data structure(s) are configured to efficiently store constantly changing data, and to provide quick access to data generated by an IoT device once that device has been identified using the first data structure(s).
- This constantly changing data may also be provided to a map generation component, such that the constantly changing data can then be displayed at a generated map corresponding to the physical space associated with the first data structure.
- methods, systems, and computer program products may include embodiments that access a hierarchical graph defining a topology of a physical space and comprising a plurality of nodes.
- the plurality of nodes of the hierarchical graph may comprise a top node for the physical space and a plurality of other nodes coupled, through zero or more intermediate nodes, to the top node of the physical space.
- one or more of the plurality of nodes may comprise an area node or a sub-area node that each represent an area or sub-area within the physical space.
- one or more of the plurality of nodes may also comprise a device node that each represent a device located within the physical space. Each device may be configured to provide data or receive control signals.
- Embodiments may further include, for a particular node of the plurality of nodes, generating map data corresponding to the particular node.
- the generated map data may be associated with generating at least a portion of a map corresponding to the particular node.
- the generated map data corresponding to the particular node may be stored within the hierarchical graph.
- hierarchical graphs corresponding to a physical space may be utilized to generate maps displaying live (i.e., real-time or very close to real-time) sensor data.
- map data e.g., Binary Large Objects (BLOB's)
- BLOB's Binary Large Objects
- the map data corresponding to each node may then be linked such that a positioning of each entity (i.e., area, sub-area, device, and/or sensor) in relation to each other within the map may be properly rendered.
- Live sensor data may then be provided for display at the map via the live sensor database (i.e., the data store 271 ).
- map data types e.g., BLOB types
- a different type of map e.g., wayfinding map, HVAC map, and so forth
- map data types may be generated for any given node, such that multiple types of maps associated with a given physical space may be generated from a hierarchical graph corresponding to the given physical space.
- various types of custom maps associated with a given space that are configured to illustrate live sensor data may be stored and generated.
- already-created maps of various formats e.g., GEOJSON, .DWG, and so forth
- a hierarchical graph of nodes corresponding to the same given physical space may also be linked to a hierarchical graph of nodes corresponding to the same given physical space.
- the hierarchical graph may also have access to a database of live sensor data, which may then allow for rendering such live sensor data at the already-created map.
- FIG. 1 illustrates an example computer architecture that facilitates operation of the principles described herein.
- FIG. 2 illustrates an example environment for providing access to sensor data from devices within a physical space.
- FIG. 3 illustrates an example hierarchical graph associated with a physical space.
- FIG. 4 illustrates an example hierarchical graph associated with a physical space and devices associated with areas or sub-areas of the physical space.
- FIG. 5 illustrates a flowchart of a method for providing access to sensor data from devices within a physical space.
- FIG. 6 illustrates a more specific embodiment of a map association and generation engine.
- FIG. 7 illustrates an example of a map corresponding to a physical space.
- FIG. 8 illustrates a flowchart of a method for generating a map based on nodes of a hierarchical graph that is configured to provide access to sensor data from devices within a physical space
- IoT Internet of Things
- challenges associated with managing the devices, including challenges in managing a representation of the devices as they relate to their physical environment, challenges with handling the vast amounts of data generated by the devices, and challenges with managing user access to the devices and user access rights for associating devices with spaces.
- a large organization may own several campuses in different geographical locations. Each of these campuses could be made of a large number of buildings, each of which could have many floors. Each of these floors, in turn could have a large number of physical spaces (e.g., conference rooms, offices, common areas, laboratories, etc.). Each of these physical spaces could include a number of objects, such as desks, chairs, lab equipment, etc.
- Each of these physical spaces and/or objects in the physical spaces could be associated with a number of IoT devices, each of which could include a number of sensors other data-generating hardware.
- Prior approaches have failed to efficiently represent these physical spaces and IoT devices, while providing efficient access to the data generated by the IoT devices. Additionally, prior approaches have failed to provide efficient mechanisms for managing user access as it relates to devices (e.g., user access rights for accessing sensor data and/or user access rights for managing the devices themselves), and/or for managing user access as it relates to physical spaces (e.g., for managing the layout of spaces including their sub-spaces, for managing adding/removing/managing devices in spaces, etc.). For instance, for a large organization, placing all of this data in a single hierarchical graph could result in a graph that is very large both in terms of depth and breadth—and which would require expensive graph traversal operations every time sensor data needs to be updated or accessed.
- the multi-database environment can include one or more first data structures (e.g., one or more graphs) that store relatively static information in the form of a topology of the physical environment in which the IoT devices exist, including storing references to the devices themselves.
- the first data structure(s) are configured to facilitate queries that can quickly identify physical spaces, users, and/or IoT device(s) within physical spaces—regardless of the size of the topology; quick queries could mean a tradeoff that operations updating the first data structure(s) is comparatively expensive.
- the multi-database environment can also include one or more second data structures that store relatively dynamic information, such as sensor data generated by the IoT devices.
- the second data structure(s) are configured to efficiently store constantly changing data, and to provide quick access to data generated by an IoT device once that device has been identified using the first data structure(s). Users may be managed within the first data structure(s) (e.g., as user nodes associated with device nodes and/or with nodes relating to physical spaces) and/or within the second data structure(s).
- the first data structure may also include map data corresponding to a particular node of the first data structure, wherein the map data is associated with at least a portion of a map corresponding to the given node. As such, the map data may be used to generate the portion of the map corresponding to the given node.
- the multi-database environment can also include one or more second data structures that store relatively dynamic information, such as sensor data generated by the IoT devices.
- the second data structure(s) are configured to efficiently store constantly changing data, and to provide quick access to data generated by an IoT device once that device has been identified using the first data structure(s).
- This constantly changing data may also be provided to a map generation component, such that the constantly changing data can then be displayed at a generated map corresponding to the physical space associated with the first data structure.
- FIG. 1 Some introductory discussion of a computing system will be described with respect to FIG. 1 . Then, providing access to sensor data from devices within a physical space and generating maps corresponding to the physical space, consistent with the multi-database environment introduced above, will be described with respect to FIGS. 2 through 7 .
- Computing systems are now increasingly taking a wide variety of forms.
- Computing systems may, for example, be handheld devices, appliances, laptop computers, desktop computers, mainframes, distributed computing systems, datacenters, or even devices that have not conventionally been considered a computing system, such as wearables (e.g., glasses).
- the term “computing system” is defined broadly as including any device or system (or combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by a processor.
- the memory may take any form and may depend on the nature and form of the computing system.
- a computing system may be distributed over a network environment and may include multiple constituent computing systems.
- a computing system 100 typically includes at least one hardware processing unit 102 and memory 104 .
- the memory 104 may be physical system memory, which may be volatile, non-volatile, or some combination of the two.
- the term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well.
- the computing system 100 also has thereon multiple structures often referred to as an “executable component”.
- the memory 104 of the computing system 100 is illustrated as including executable component 106 .
- executable component is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof.
- the structure of an executable component may include software objects, routines, methods, and so forth, that may be executed on the computing system, whether such an executable component exists in the heap of a computing system, or whether the executable component exists on computer-readable storage media.
- the structure of the executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by a processor thread), the computing system is caused to perform a function.
- Such structure may be computer-readable directly by the processors (as is the case if the executable component were binary).
- the structure may be structured to be interpretable and/or compiled (whether in a single stage or in multiple stages) so as to generate such binary that is directly interpretable by the processors.
- executable component is also well understood by one of ordinary skill as including structures that are implemented exclusively or near-exclusively in hardware, such as within a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. Accordingly, the term “executable component” is a term for a structure that is well understood by those of ordinary skill in the art of computing, whether implemented in software, hardware, or a combination. In this description, the terms “component”, “service”, “engine”, “module”, “control”, or the like may also be used. As used in this description and in the case, these terms (whether expressed with or without a modifying clause) are also intended to be synonymous with the term “executable component”, and thus also have a structure that is well understood by those of ordinary skill in the art of computing.
- FPGA field programmable gate array
- ASIC application specific integrated circuit
- embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors (of the associated computing system that performs the act) direct the operation of the computing system in response to having executed computer-executable instructions that constitute an executable component.
- processors of the associated computing system that performs the act
- Such computer-executable instructions may be embodied on one or more computer-readable media that form a computer program product.
- An example of such an operation involves the manipulation of data.
- the computer-executable instructions may be stored in the memory 104 of the computing system 100 .
- Computing system 100 may also contain communication channels 108 that allow the computing system 100 to communicate with other computing systems over, for example, network 110 .
- the computing system 100 includes a user interface 112 for use in interfacing with a user.
- the user interface 112 may include output mechanisms 112 A as well as input mechanisms 112 B.
- output mechanisms 112 A might include, for instance, speakers, displays, tactile output, holograms and so forth.
- Examples of input mechanisms 112 B might include, for instance, microphones, touchscreens, holograms, cameras, keyboards, mouse of other pointer input, sensors of any type, and so forth.
- Embodiments described herein may comprise or utilize a special purpose or general-purpose computing system including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below.
- Embodiments described herein also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures.
- Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computing system.
- Computer-readable media that store computer-executable instructions are physical storage media.
- Computer-readable media that carry computer-executable instructions are transmission media.
- embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: storage media and transmission media.
- Computer-readable storage media includes NAND flash memory or other flash memory, RAM, DRAM, SRAM, ROM, EEPROM, CD-ROM or other optical disk storage, solid-state disk storage, magnetic disk storage or other storage devices, or any other physical and tangible storage medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computing system.
- a “network” is defined as one or more data links that enable the transport of electronic data between computing systems and/or modules and/or other electronic devices.
- a network or another communications connection can include a network and/or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computing system. Combinations of the above should also be included within the scope of computer-readable media.
- program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to storage media (or vice versa).
- computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computing system RAM and/or to less volatile storage media at a computing system.
- a network interface module e.g., a “NIC”
- storage media can be included in computing system components that also (or even primarily) utilize transmission media.
- Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general purpose computing system, special purpose computing system, or special purpose processing device to perform a certain function or group of functions. Alternatively, or in addition, the computer-executable instructions may configure the computing system to perform a certain function or group of functions.
- the computer executable instructions may be, for example, binaries or even instructions that undergo some translation (such as compilation) before direct execution by the processors, such as intermediate format instructions such as assembly language, or even source code.
- computing system configurations may be virtually any type of device including (but most certainly not limited to) smart luggage, smart clothing, smart jewelry, smart drinking bottles, smart skate boards, smart golf clubs, smart toys, smart brewing machines, smart wallets, smart home and business automation gear, smart appliances, smart furniture, etc.
- the invention may also be practiced in distributed system environments where local and remote computing systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks.
- program modules may be located in both local and remote memory storage devices.
- Cloud computing environments may be distributed, although this is not required. When distributed, cloud computing environments may be distributed internationally within an organization and/or have components possessed across multiple organizations.
- cloud computing is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of “cloud computing” is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.
- an IoT device can include any device that is connected to a network (whether that be a personal area network, local area network, wide area network, and/or the Internet) and that interacts with a physical environment (whether that be to control or influence some aspect of a physical environment, and/or to receive sensor data from a physical environment).
- a network whether that be a personal area network, local area network, wide area network, and/or the Internet
- references to IoT devices herein should be interpreted broadly to include vast categories of devices, regardless of how those devices may be named or marketed. From a computing perspective, IoT devices may range from fairly complex (e.g., such as being embodied on a general-purpose computer system), to fairly simple (e.g., such as being embodied within a special-purpose microcontroller environment).
- FIG. 2 illustrates an example environment 200 for providing access to sensor data from devices within a physical space.
- the environment 200 includes a user computer system 202 A.
- the user computer system 202 A may be embodied, for example, by computer system 100 , as described with respect to FIG. 1 .
- the user computer system 202 A may comprise any type of computer system that is configured to communicate with, and utilize the functionality of, a server computer system 210 , which is described later.
- the user computer system 202 A may comprise a desktop computer, a laptop computer, a tablet, a smartphone, and so forth.
- the ellipses 202 B represents that any number of user computer systems may communicate with, and utilize the functionality of, the server computer system 210 .
- the server computer system 210 is configured to receive, store, and provide access to sensor data from devices (such as IoT devices) located within physical spaces (e.g., a room within a building), as further described herein.
- devices such as IoT devices located within physical spaces (e.g., a room within a building), as further described herein.
- the server computer system 210 may be embodied, for example, by computer system 100 , as described with respect to FIG. 1 .
- the server computer system 210 may comprise any type of computer system, including any combination of hardware and/or software that is configured to provide access to sensor data from devices located within particular physical spaces.
- the server computer system 210 may include various engines, functional blocks, and components, including (as examples) a graph engine 220 , a property store 230 , a rules and permissions store 240 , a map association and generation engine 250 , a tenant and resource rules store 260 , and a data analysis engine 270 , each of which may also include additional engines, functional blocks, and components (e.g., an object type store 221 within the graph engine 220 ).
- the various engines, components, and/or functional blocks of the server computer system 210 may be implemented on a single computer system, or may be implemented as a distributed computer system that includes elements resident in a cloud environment, and/or that implement aspects of cloud computing (i.e., at least one of the various illustrated engines may be implemented locally, while at least one other engine may be implemented remotely).
- the various engines, functional blocks, and/or components of the server computer system 210 may be implemented as software, hardware, or a combination of software and hardware.
- the configuration of the server computer system 210 illustrated in FIG. 2 is shown only for exemplary purposes.
- the server computer system 210 may include more or less than the engines, functional blocks, and/or components illustrated in FIG. 2 .
- the ellipses 261 represent that any number of engines, functional blocks, and/or components may be utilized within the server computer system.
- the various engines of the server computer system 210 may access and/or utilize a processor and memory, such as the processor 102 and the memory 104 of FIG. 1 , as needed, to perform their various functions.
- the server computer system 210 includes the graph engine 220 , the property store 230 , the rules and permissions store 240 , the map association and generation engine 250 , the tenant and resource rules store 260 , and the data analysis engine 270 .
- the graph engine 220 may be configured to generate, store, and/or manage one or more hierarchical graphs (e.g., hierarchical graph 310 of FIG. 3 ) that defines a topology of areas and sub-areas of a physical space.
- FIG. 3 illustrates a hierarchical graph 310 that includes a topology of nodes associated with a physical space comprising “building 1” (e.g., building node 302 ).
- the hierarchical graph 310 also represents areas and sub-areas of “building 1,” such as different floors (i.e., floor node 304 A, floor node 304 B, and floor node 304 C, all of which are sub-nodes of building node 302 ), as well as different rooms (i.e., conference room node 306 A, conference room node 306 B, conference room node 306 C, and office node 306 D) associated with each floor.
- each of the room nodes 306 A- 306 A could be associated with additional sub-nodes representing physical objects in the rooms, such as desks, chairs, tales, computer, lab equipment, etc.
- any node in the hierarchical graph 310 could be associated with devices/sensors and/or users.
- the various room nodes i.e., the conference room node 306 A and the office node 306 D
- the room nodes and/or the device/sensor nodes may be associated with user nodes.
- FIG. 4 shows a related graph 410 , that includes device nodes 420 A and 420 B and sensor nodes 422 A- 422 C. While only seven nodes associated with areas/sub-areas are illustrated in FIG.
- the ellipses 308 represents that any number of nodes that are associated with areas/sub-areas and devices/sensors may be utilized when practicing the principles described herein (whether those nodes be added or deleted in a horizontal direction (breadth) or a vertical direction (depth)).
- the topology of the graph may be continuously modified via adding or deleting nodes of the graph (in a horizontal direction or vertical direction). For instance, using the example of FIG. 3 , a number of additional building nodes associated with different buildings than building 1 (corresponding to building node 302 ), each of which additional buildings may include additional nodes corresponding to floors, rooms, and so forth, may also be included within the graph 310 .
- the hierarchical graph 310 may be stored within a relational database, though any type of database could be used. Additionally, regardless of the type of graph used, the full paths in the graph for each given node may be stored as metadata in the node to increase the performance and efficiency of querying the hierarchical graph 310 . In this way, identification (e.g., via a query) of any ancestral node or child node (i.e., children nodes, grandchildren nodes, great-grandchildren nodes, and so on) of a given node may be performed in an order of one operation (i.e., an O(1) operation).
- a query that requests each node having a path that starts with “building1/floor3” may identify conference room 3 and office 1 (i.e., corresponding to conference room node 306 C and office node 306 D, respectively) as being children of the floor node 304 C in an O(1) operation.
- the graph may be quickly and efficiently traversed to identify nodes and relationships between nodes within the graph than traditional traversing of graphs. By storing primarily static information in the graph, however, the need to generate/store these paths can be relatively infrequent.
- the graph engine 220 includes various components that may comprise any combination of appropriate hardware and/or software, including an object type store 221 , an update engine 222 , and a query engine 223 .
- the ellipses 224 represents that any number of components may be included with the graph engine 220 (i.e., more or less than the components illustrated within the graph engine 220 ).
- the object type store 221 comprises a data store of node object types that can be selected to create additional nodes within the graph 310 .
- any number of object types associated with areas/sub-areas of physical spaces may be used within the graph 310 , including but not limited to organizations (e.g., businesses), geographic regions (e.g., continents, countries, states, cities, counties, and so forth), types of areas (e.g., buildings, farms, houses, apartments, conference rooms, offices, bathrooms, breakrooms, study areas, desks, chairs, and so forth), types of devices (e.g., thermostat, projector, paper towel dispenser, television, computer, and so forth), types of sensors (e.g., thermocouple, thermistor, humidity sensor, CO 2 sensor, Geiger counter), and so forth. Additionally, the object type store 221 may be extensible.
- the update engine 222 may be configured to update the hierarchical graph 310 with any changes made to the graph. For instance, the update engine 222 may update the graph with additional nodes, update the graph with less nodes (e.g., deleted nodes), update nodes with new or modified properties, update nodes with new or modified paths, and perform any other operations associated with modifying or updating the graph.
- the update engine 222 may update the graph with additional nodes, update the graph with less nodes (e.g., deleted nodes), update nodes with new or modified properties, update nodes with new or modified paths, and perform any other operations associated with modifying or updating the graph.
- the query engine 223 may be configured to allow for performing queries to the hierarchical graph 310 .
- the query engine 223 may be configured to receive queries, generate query plans, build responses to queries, and/or perform any other operations associated with receiving and responding to queries of the hierarchical graph 310 .
- the server computer system 210 further includes data analysis engine 270 .
- the data analysis engine 270 may be configured to receive, gather, manage, and process data received from devices/sensors located within a physical space (associated with the hierarchical graph that defines the topology of the physical space).
- FIG. 2 illustrates various devices and sensors located within a physical space 280 .
- the physical space 280 comprises various areas and sub-areas, including area/sub-area 281 A, area/sub-area 281 B, and area/sub-area 281 C.
- Each of the sub-areas includes a single device having a single sensor (i.e., area/sub-area 281 A includes device 290 A having sensor 291 A, area/sub-area 281 B includes device 290 B having sensor 291 B, and area/sub-area 281 C includes device 290 C having sensor 291 C).
- area/sub-area 281 A includes device 290 A having sensor 291 A
- area/sub-area 281 B includes device 290 B having sensor 291 B
- area/sub-area 281 C includes device 290 C having sensor 291 C.
- the ellipses 290 represents that there may be any number of areas/sub-areas within the physical space 280 , each of the areas/sub-areas including any number of devices having any number of sensors (including zero devices/sensors).
- the devices and sensors may include any type of devices/sensors, including but not limited to devices/sensors associated with detecting temperature, CO 2 , light, pressure, toxic chemicals, humidity, and so forth.
- the combination of the devices 290 (i.e., the device 290 A through the device 290 C) and the sensors 291 (i.e., the sensor 291 A through the sensor 291 C) may be configured to capture sensor data (e.g., changes in temperature) and send the captured data to the data analysis engine 270 .
- the sensors may provide data to the data analysis engine 270 periodically and/or continuously.
- the data analysis engine 270 may receive, gather, manage, and process real-time or near real-time data received from the sensors.
- the sensors may actively push data to the data analysis engine 270 , or may only provide it upon request.
- the data analysis engine 270 may then be configured to receive, gather, manage, and process data received from such devices/sensors.
- the data analysis engine 270 may include a data store 271 that is configured to organize, store, and allow access to received sensor data.
- the data store 271 may comprise any type of data store that is configured to manage dynamic, frequently changing data such as sensor data, and that provides quick and efficient performance.
- the data store 271 may comprise a key-value database.
- the data store 271 may comprise a REDISTM CACHE. While the data store 271 may store some data permanently, the data store 271 only store some data temporarily.
- the data analysis engine 270 may processes large quantities of data, making it infeasible and/or undesirable to store it permanently.
- Data associated with a particular device e.g., sensor data
- the data analysis engine 270 further includes a query engine 272 .
- the query engine 272 may be configured to allow for performing queries to the data store 271 .
- the query engine 272 may be configured to receive queries, generate query plans, build responses to queries, and/or perform any other operations associated with receiving and responding to queries of the data store 271 .
- FIG. 4 illustrates an environment 400 including hierarchical graph 410 comprising area/sub-area nodes, as well as device/sensor nodes that are each associated with one or more area/sub-area nodes.
- the conference room node 306 A is associated with device node 420 A (having a corresponding sensor node 422 A) and the office node 306 D is associated with the device node 420 B (having two corresponding sensor nodes, the sensor node 422 B and the sensor node 422 C).
- FIG. 4 includes a representation of an actual physical space 402 (associated with building 1) that corresponds to the building node 302 .
- the physical space 402 also comprises conference room 406 A (associated with conference room 1 and corresponding to the conference room node 306 A) that includes the actual physical device 440 A having the sensor 442 A, as well as office 406 D (associated with office 1 and corresponding to the office node 306 D) that includes the actual physical device 440 B having both the sensor 442 B and the sensor 442 C.
- the device 440 A may correspond to a thermostat that includes a thermocouple (i.e., the sensor 442 A) for measuring temperature. Such temperature measurements may then be sent to the data analysis engine for managing, storing, and processing the received sensor data.
- user nodes may be included within the hierarchical graph 410 as being associated with one or more area/sub-area nodes (though they could additionally, or alternatively, be associated with sensor/device nodes).
- FIG. 4 shows the user node 430 being associated with the office node 306 D.
- the user 1 i.e., corresponding to the user node 330
- user node 430 could be used to control a user's access to office node 306 D, including, for example, the user's ability to modify office node 306 D, to attached nodes to office node 306 D, remove nodes from office node 306 D, or modify nodes that are already attached to office node 306 D, etc.
- associating user node 430 with office node 306 D applies the user node's permissions to all nodes hierarchically below office node 306 D in hierarchical graph 410 . Similar application of access rights could apply when associating a user node with a sensor/device node.
- data and/or metadata associated with the node may be stored in the hierarchical graph (e.g., the hierarchical graph 310 or the hierarchical graph 410 ), the data store 271 of the data analysis engine 270 , or any other appropriate location associated with the server computer system 210 .
- the server computer system 210 further includes property store 230 , rules and permissions store 240 , map association and generation engine 250 , and tenant and resource store 260 .
- the property store 230 may comprise a data store that includes properties associated with nodes of the hierarchical graph 310 . For instance, particular properties may automatically be associated with particular object types (i.e., node types), as well as children of such object types. In a more particular example, a property associated with occupancy of a chair within a room may propagate to the room itself (i.e., showing that the room is occupied).
- the property store may also be extensible, such that properties may be created and associated with any given node, and potentially associated with ancestral or children nodes of the given node.
- the rules and permissions store 240 may include various rules and permissions associated with particular roles assigned to users. For instance, based on a particular role (e.g., an administrator) assigned to a user, the user may have access to perform various operations, including adding/deleting nodes, modifying nodes, accessing/modifying functionality of various devices (e.g., locking doors), and so forth.
- the rules/permissions stored in the rules and permissions store 240 may be applied to various nodes in the hierarchical graph, whether those be area/sub-area nodes, sensor/device nodes, or user nodes.
- the rules/permissions stored in the rules and permissions store 240 may additionally, or alternatively, be applied data in the data store 271 .
- user nodes that are associated with nodes in the graph (e.g., areas or devices/sensors) grant corresponding users access to the associated node, and user rules/permissions associated with those user nodes are managed in the rules and permissions store 240 .
- the map association and generation engine 250 may be configured to perform numerous functions with respect to associating maps with the hierarchical graph (and devices providing data to the data store), and/or generating the hierarchical graph, itself. For instance, the map association and generation engine 250 may be able to generate the hierarchal graph 300 based on user input and/or based on a map. In another example, the map association and generation engine 250 may be able to link nodes of the hierarchical graph to locations or devices included within a map. In yet another example, the map association and generation engine 250 may further be able to generate a map based on information included within the hierarchical graph corresponding to nodes of the hierarchical graph.
- the tenant and resource rules store 260 may include rules associated with how resources, permissions, properties, and so forth are to be handled for each given entity (e.g., tenant) that utilizes the hierarchical graph.
- the ellipses 261 represent that the server computer system 210 may include any number of components (i.e., whether more or less) than the components illustrated within the server computer system in FIG. 2 .
- the graph engine 220 and the data analysis engine 270 include corresponding query engines (i.e., the query engine 223 and the query engine 272 , respectively)
- an overarching query engine may be included within the physical analytics computer system that allows for querying both the graph engine 220 and the data analysis engine 270 .
- a user may be able to generate queries that can traverse the hierarchical graph (e.g., the hierarchical graph 410 ) to identify one or more devices associated with a particular area/sub-area of the hierarchical graph, as well as current (or previous) sensor data associated with the one or more devices via the data store 271 and the data analysis engine 270 .
- the hierarchical graph e.g., the hierarchical graph 410
- FIG. 5 illustrates a flowchart of a method 500 for providing access to sensor data from devices within a physical space.
- the method 500 is described with frequent reference to the environments of FIGS. 2-4 .
- the method 500 includes identifying one or more areas and one or more sub-areas of the physical space (Act 502 ).
- the building 402 , the conference room 406 A, and/or the office 406 D of FIG. 4 may be identified by the map association and generation engine 250 .
- the method 500 further includes, based on the one or more identified areas and the one or more identified sub-areas, generating a hierarchical graph that describes a topology of the physical space (Act 504 ).
- the hierarchical graph 410 may be generated by the map association and generation engine 250 .
- Generating the hierarchical graph further includes generating a node for each of the one or more identified areas and each of the one or more identified sub-areas (Act 506 ).
- the hierarchical graph 410 includes various nodes based on an identification of areas/sub-areas associated with the building 402 .
- Generating the hierarchical graph also includes generating a device node for each of one or more devices located within the physical space (Act 508 ). For instance, an identification of the device 440 A and the device 440 B may result in generating the device node 420 A and the device node 420 B, respectively.
- Generating the device node for each of one or more devices located within the physical space further includes, for a particular one of the one or more areas or the one or more sub-areas, identifying a particular device associated with the particular area or the particular sub-area (Act 510 ).
- the particular device may include one or more sensors that generate data. For example, the device 440 A may be identified, as well as the sensor 442 A.
- Generating the device node for each of one or more devices located within the physical space further includes, for a particular one of the one or more areas or the one or more sub-areas, generating a particular device node within the hierarchical graph that is associated with the particular device (Act 512 ).
- the particular device node may be a sub-node of a particular node that was generated for the particular area or the particular sub-area.
- the device node 420 A may be generated in response to identifying the device 440 A, and may further be associated with a particular area/sub-area node (i.e., the device node 420 A being associated with the conference room node 306 A). Additionally, any sensors associated with the device 440 A may be identified, including the sensor 422 A.
- the method 500 further includes generating a database that stores at least sensor data for the one or more devices located within the physical space (Act 514 ).
- the database may be associated with, but separate from, the hierarchical graph.
- the data store 271 may be generated for managing, storing, and accessing received sensor data.
- the method 500 may further include providing sensor data for the particular device (Act 516 ).
- data from the sensor 442 A of device 440 A may be provided to the data store 271 .
- the sensor 442 A may be configured to measure CO 2 levels, which measurements may be provided by the device 440 A (or by another device capable of communicating with the device 440 A) to the data store 271 (and ultimately, the data analysis engine 270 ).
- Providing sensor data for the particular device may also include using the hierarchical graph to identify the particular device within the particular area or the particular sub-area (Act 518 ). For example, a query provided to the server computer system 210 (and perhaps directly to the graph engine 220 ) may request an identification of each device (and therefore each device node) associated with a particular area/sub-area (and therefore the particular area/sub-area node corresponding to the particular area/sub-area).
- Providing sensor data for the particular device may further include, based on having identified the particular device using the hierarchical graph, using the database to identify sensor data corresponding to the particular device (Act 520 ). For instance, upon identifying the device/device nodes (and the corresponding sensors/sensor nodes), sensor data associated with the devices/sensors may then be identified within the data store 271 .
- the principles described herein may allow for logically organizing devices (e.g., Internet of Things (IoT) devices) within physical spaces (or areas/sub-areas of physical spaces), and associating users with devices and/or spaces, thus allowing for intuitive organization and control of a plurality of devices, efficient use of such devices, and granular control of user access rights to devices and/or spaces. For instance, each device associated with a particular area/sub-area (e.g., on a particular floor of a building or a particular room) may be easily shut off or placed in a reduced power state, as location-based groupings of devices are automatically created.
- IoT Internet of Things
- relatively static physical space data e.g., data regarding floors and rooms of a building
- user access data may be placed in a reliable graph (e.g., a relational database)
- a reliable graph e.g., a relational database
- more dynamic sensor data may be managed in a more dynamic database (e.g., a key-value database such as a REDIS CACHE).
- the reliability of a hierarchical graph may be supplemented with quickness/efficiency by computing and storing paths associated with each node upfront when adding/removing/modifying nodes in the graph. Computing and storing the paths may then allow for performing queries with respect to ancestral nodes or child nodes of any given node in an O(1) operation.
- the hierarchical graph and the dynamic database may then be linked such that sensor data stored at the dynamic database may be quickly accessed when querying nodes associated with an area/sub-area within the hierarchical graph.
- storing the hierarchical graph and the dynamic database within an improved computer system may improve the speed and efficiency of the computer system with respect to traversing the hierarchical graph in response to queries, building responses to queries (e.g., surfacing live sensor data associated with a particular area or sub-area of a physical space corresponding to the hierarchical graph), and so forth.
- FIG. 6 illustrates a more detailed example of the map association and generation engine 250 of FIG. 2 .
- the map association and generation engine 250 includes both a map association engine 660 and a map generation engine 670 .
- ellipses 680 illustrates that the map association and generation engine 250 may include more or less than the components (e.g., the map association engine 660 , the map accessibility engine 661 , and so forth) shown in FIG. 6 .
- the map association engine 660 may be configured to link entities (e.g., areas, sub-areas, devices, sensors, and so forth) illustrated within a map of a physical space to nodes of a hierarchical graph that corresponds to the physical space. As illustrated, the map association engine 660 includes both a map accessibility engine 661 and a linking engine 662 . The map association engine 660 may be capable of accessing a map associated with a physical space for which a hierarchical map has been created.
- entities e.g., areas, sub-areas, devices, sensors, and so forth
- FIG. 7 illustrates a map 700 that comprises various areas and sub-areas, including a team room 701 , a team room 702 , an office 703 , a bathroom 704 , an office 705 , an office 706 , an office 707 , a conference room 708 , a conference room 709 , a conference room 710 , an office 711 , an office 712 , an office 713 , an office 714 , an office 715 , an office 716 , a team room 717 , an office 718 , an office 719 , a conference room 720 , a team room 721 , a set of stairs 722 , an office 723 , and a hallway 724 .
- the map 700 may also include locations of devices and/or sensors within areas and sub-areas of the map.
- Such a map may comprise any file or data format, including but not limited to GEOJSON, portable document format (PDF), DWG, scalable vector graphics (SVG), etc.
- a file/data format includes structured data, which can be used by the map association engine 660 to create identifiers for any given entity (e.g., area, sub-area, device, sensor, and so forth) illustrated within the map.
- Such embodiments may also allow for adding metadata to entities in addition to these entity identifiers.
- the linking engine 662 may be configured to generate a tag for any given entity within a map (e.g., the team room 701 ) that defines a link between the entity and a corresponding node of a hierarchical graph that is associated with the same entity.
- an identifier associated with both the office 703 within the map 700 and the office node 306 D may be the same.
- such an identifier may be “Office 1,” though it could be any form of identifier including, for example, a globally-unique identifier (GUID).
- linking between a hierarchical graph and a map may be at least partially performed automatically using heuristics and/or machine learning. For instance, links may be automatically generated between a node of a hierarchical graph and an entity of a map when the node and the entity are determined to have the same, or a similar, identifier.
- the linking engine 662 may also generate a tag for the corresponding node in the hierarchical graph that defines the link between the node and the corresponding entity of the map.
- each area node and sub-area node may also be linked to devices and/or sensors located within the corresponding area or sub-area (e.g., a room) of the physical space corresponding to the hierarchical graph of nodes.
- the hierarchical graph of nodes may have access to, whether pulling sensor data or receiving sensor data from, the live sensor data being gathered in the data store 271 . In this way, linking may then allow for providing live data to a rendered view of a map (e.g., the map 700 ).
- a rendering of the room within a rendered map of the physical space may indicate that the room is occupied. For instance, within the rendered version of the map, a color of the room may change (e.g., from red to green), an occupied symbol may appear, text stating “Occupied” may be illustrated, and so forth.
- the map association and generation engine also includes the map generation engine 670 .
- the map generation engine 670 includes a Binary Large Object (BLOB) type store 671 , a BLOB type extensibility engine 672 , and a linking engine 673 .
- the map generation engine 670 may be configured to generate a map based on data stored within a hierarchical graph that corresponds to a physical space.
- each given node of such a hierarchical graph (e.g., the hierarchical graph 310 ) may include data associated with rendering a portion of a map that corresponds to the given node.
- an office node may include data associated with rendering the office corresponding to the node as part of a map.
- such data may comprise a Binary Large Object (BLOB), such as a corresponding portion of structured data (e.g., GEOJSON, PDF, DWG, SVG), etc.) usable to visually render a map.
- BLOB Binary Large Object
- each given node of a hierarchical graph may include a BLOB that comprises sufficient data for rendering at least a portion of a map associated with an entity (e.g., area, sub-area, device, sensor, and so forth) that corresponds to the given node.
- the map generation engine 670 includes a BLOB type store 671 .
- the BLOB type store 671 may include various types and subtypes of BLOB's, including area BLOB's, sub-area BLOB's, device BLOB's, and sensor BLOB's. Each of these BLOB types may include information related to a corresponding entity (e.g., area, device, sensor), including an identifier of the entity, properties associated with the entity, a location of the entity (e.g., Global Positioning System (GPS) coordinates), rules associated with the entity, and so forth.
- GPS Global Positioning System
- the BLOB type store 671 may include BLOB types associated with generating at least a portion of a map associated with an area, sub-area, device, or sensor, as well as an associated subtype of BLOB that corresponds to a type of map to be generated.
- the BLOB type store may include BLOB types associated with generating a wayfinding map (e.g., a wayfinding floor map); an electrical grid map; a water and sewer map; a heating, ventilation, and air conditioning (HVAC) map; a satellite map; and so forth.
- Each type of BLOB may be formatted to generate at least a portion of a particular type of map corresponding to a particular area, sub-area, device, or sensor.
- each given node of a hierarchical graph may include a BLOB that can be used to generate a portion of a map that corresponds to the area, sub-area, device, or sensor corresponding to the given node.
- each node may include multiple different associated BLOB types.
- a given area node e.g., an office node
- a given area node e.g., an office node
- a wayfinding map BLOB type associated with the given area
- HVAC map BLOB type associated with the given area
- a water and sewer map BLOB type associated with the given area.
- each BLOB associated with a particular node may be stored, along with the node, in a corresponding hierarchical graph of the particular node
- the map generation engine 250 also includes the BLOB type extensibility engine 672 .
- the BLOB type extensibility engine may allow for creating any type of BLOB. For instance, a user may desire to generate a hierarchical graph for a unique type of physical space, and thus create additional BLOB types corresponding to the unique physical space.
- the map generation engine 250 includes a linking engine 673 .
- the linking engine may be configured to link each area node, sub-area node, device node, device node, sensor node, and user node, such that a full map (e.g., the map 700 ) may be generated that includes the relative positioning of each area, sub-area, device, and sensor in relation to each other.
- a full map e.g., the map 700
- such linking may comprise including linking information within each BLOB associated with each node, such that relative positioning of each area, sub-area, device, and/or sensor may be determined in relation to each other.
- live sensor data may also be provided to a rendered version of the map (e.g., occupancy of a room based on generated sensor data within the room).
- the hierarchical graph may also have access to live sensor data stored at the data store 271 .
- queries may be continually or periodically performed to determine a current status of each device or sensor located within in any given area or sub-area.
- sensor data may displayed at the rendered map and/or any corresponding changes to the map may be made.
- a rule may be created that includes changing an occupancy status of a room when motion is detected within a room (e.g., changing a color of the room within the map to demonstrate current occupancy).
- a rendering of the map may also display various levels of granularity based on a zoom level when viewing the rendered map. For instance, when zooming in, the map may show details such as temperature, users within a given area, and so forth, while when zooming out, the map may show less granular details such as simply whether or not a room is occupied.
- FIG. 8 illustrates a flowchart of a method 800 for generating a map based on nodes of a hierarchical graph that is configured to provide access to sensor data from devices within a physical space.
- the method 800 is described with frequent reference to the environments of FIGS. 2-7 .
- the method 800 includes accessing a hierarchical graph that defines a topology of a physical space and comprises a plurality of nodes (Act 810 ).
- the plurality of nodes of the hierarchical graph may comprise a top node for the physical space and a plurality of other nodes coupled, through zero or more intermediate nodes, to the top node of the physical space.
- One or more of the plurality of nodes may comprise an area node or a sub-area node, wherein each area node and sub-area node represents an area or sub-area within the physical space.
- One or more of the plurality of nodes also may comprise a device node, wherein each device node represents a device located within the physical space and is configured to provide data or receive control signals.
- the hierarchical graph 310 of FIG. 3 that defines a topology of a physical space and includes a plurality of nodes may be accessed by the map association and generation engine 250 .
- the method 800 further includes, for a particular node of the plurality of nodes, generating map data corresponding to the particular node (Act 820 ).
- the generated map data is associated with generating at least a portion of a map corresponding to the particular node.
- the map generation engine 670 may generate a BLOB associated with a particular node of the hierarchical graph 310 that is formatted for generating a portion of a map associated with an area, sub-area, device, and/or sensor corresponding to the particular node.
- the method 800 further includes, for a particular node of the plurality of nodes, storing the generated map data corresponding to the particular node within the hierarchical graph (Act 830 ).
- the generated BLOB may be stored at the hierarchical graph 310 .
- the stored BLOB associated with the particular node may then be used to generate the portion of the map corresponding to the particular node, as further described herein.
- hierarchical graphs corresponding to a physical space may be utilized to generate maps displaying live (i.e., real-time or very close to real-time) sensor data.
- BLOB's that include data for rendering at least a portion of a map may be generated for each given area node, sub-area node, device node, and/or sensor node of a hierarchical graph corresponding to a physical space.
- the BLOB's corresponding to each node may then be linked such that a positioning of each entity (i.e., area, sub-area, device, and/or sensor) in relation to each other within the map may be properly rendered.
- Live sensor data may then be provided for display at the map via the live sensor database (i.e., the data store 271 ).
- multiple BLOB types that are each associated with a different type of map may be generated for any given node, such that multiple types of maps associated with a given physical space may be generated from a hierarchical graph corresponding to the given physical space.
- various types of custom maps associated with a given space that are configured to illustrate live sensor data may be stored and generated.
- already-created maps of various formats e.g., GEOJSON, PDF, DWG, SVG, and so forth
- a hierarchical graph of nodes corresponding to the same given physical space may also be linked to a hierarchical graph of nodes corresponding to the same given physical space.
- the hierarchical graph may also have access to a database of live sensor data, which may then allow for rendering such live sensor data at the already-created map.
Landscapes
- Engineering & Computer Science (AREA)
- Radar, Positioning & Navigation (AREA)
- Remote Sensing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Automation & Control Theory (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- User Interface Of Digital Computer (AREA)
Abstract
Description
- Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, accounting, etc.) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data.
- As computing systems have become cheaper and smaller, they have begun to proliferate to almost all areas of life. For example, Internet of Things (IoT) devices are network-connected devices that are placed in many physical spaces to enable people to interact with and gather information about their environment. For example, offices or homes may include numerous IoT devices that can be used to control locks, to manage indoor climate and receive climate information, to manage lighting and receive lighting information, to open and close doors, to perform cleaning functions, to control audio and/or video equipment, to provide voice interaction, to provide security and monitoring capabilities, etc. As such, IoT devices can process and generate vast amounts of information. Notably, IoT devices are not limited to use in structures such as offices or homes. For example, IoT devices may be used to track any manner of physical items (including, for example, animals such as livestock or pets), to monitor health of people or animals, and so forth.
- As IoT devices proliferate, it is becoming increasingly difficult to manage the devices and their users, and to process the data they generate. Notably, it may often be difficult to intuitively manage and group such devices (e.g., based on physical space or synergistic functionality), to efficiently control these devices (including controlling user access), to efficiently access data associated with these devices and/or to efficiently visualize live sensor data associated with these devices in relation to a physical space. For example, managing IoT devices could involve storing large amounts of data associated with the physical environment in which they exist (e.g., buildings with their floors, rooms, room types, objects the rooms, etc.). Similarly, large numbers of devices may also result in enormous amounts of generated data (e.g., sensor data) that may be difficult to manage and access, and to link to the physical environment.
- At least some embodiments described herein relate to methods, systems, and computer program products for managing physical spaces, associated devices, and users, including providing access to sensor data from devices within a physical space. The embodiments are built on the observation by the inventors that IoT-related data generally includes first data that is relatively static (e.g., data relating to the physical environment in which the IoT devices exist), and data that is more dynamic (e.g., sensor data generated by the IoT devices, themselves).
- In view of this recognition, the inventors have invented a multi-database environment for storing such data. In particular, the multi-database environment can include one or more first data structures (e.g., one or more graphs) that store relatively static information in the form of a topology of the physical environment in which the IoT devices exist, including storing references to the devices themselves and users associated with spaces in the physical environment and/or with devices. The first data structure(s) are configured to facilitate queries that can quickly identify physical spaces, users, and/or IoT device(s) within physical spaces—regardless of the size of the topology; quick queries could mean a tradeoff that operations updating the first data structure(s) is comparatively expensive.
- The first data structure may also include map data corresponding to a particular node of the first data structure, wherein the map data is associated with at least a portion of a map corresponding to the given node. As such, the map data may be used to generate the portion of the map corresponding to the given node. The multi-database environment can also include one or more second data structures that store relatively dynamic information, such as sensor data generated by the IoT devices. The second data structure(s) are configured to efficiently store constantly changing data, and to provide quick access to data generated by an IoT device once that device has been identified using the first data structure(s). This constantly changing data may also be provided to a map generation component, such that the constantly changing data can then be displayed at a generated map corresponding to the physical space associated with the first data structure.
- For example, methods, systems, and computer program products may include embodiments that access a hierarchical graph defining a topology of a physical space and comprising a plurality of nodes. The plurality of nodes of the hierarchical graph may comprise a top node for the physical space and a plurality of other nodes coupled, through zero or more intermediate nodes, to the top node of the physical space. Additionally, one or more of the plurality of nodes may comprise an area node or a sub-area node that each represent an area or sub-area within the physical space. Furthermore, one or more of the plurality of nodes may also comprise a device node that each represent a device located within the physical space. Each device may be configured to provide data or receive control signals.
- Embodiments may further include, for a particular node of the plurality of nodes, generating map data corresponding to the particular node. The generated map data may be associated with generating at least a portion of a map corresponding to the particular node. The generated map data corresponding to the particular node may be stored within the hierarchical graph.
- Accordingly, hierarchical graphs corresponding to a physical space may be utilized to generate maps displaying live (i.e., real-time or very close to real-time) sensor data. In particular, map data (e.g., Binary Large Objects (BLOB's)) that includes data for rendering at least a portion of a map may be generated for each given area node, sub-area node, device node, and/or sensor node of a hierarchical graph corresponding to a physical space. The map data corresponding to each node may then be linked such that a positioning of each entity (i.e., area, sub-area, device, and/or sensor) in relation to each other within the map may be properly rendered. Live sensor data may then be provided for display at the map via the live sensor database (i.e., the data store 271).
- Additionally, multiple map data types (e.g., BLOB types) that are each associated with a different type of map (e.g., wayfinding map, HVAC map, and so forth) may be generated for any given node, such that multiple types of maps associated with a given physical space may be generated from a hierarchical graph corresponding to the given physical space. In this way, various types of custom maps associated with a given space that are configured to illustrate live sensor data may be stored and generated.
- Furthermore, already-created maps of various formats (e.g., GEOJSON, .DWG, and so forth) corresponding to a given physical space may also be linked to a hierarchical graph of nodes corresponding to the same given physical space. As further described herein, the hierarchical graph may also have access to a database of live sensor data, which may then allow for rendering such live sensor data at the already-created map.
- This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
- In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
-
FIG. 1 illustrates an example computer architecture that facilitates operation of the principles described herein. -
FIG. 2 illustrates an example environment for providing access to sensor data from devices within a physical space. -
FIG. 3 illustrates an example hierarchical graph associated with a physical space. -
FIG. 4 illustrates an example hierarchical graph associated with a physical space and devices associated with areas or sub-areas of the physical space. -
FIG. 5 illustrates a flowchart of a method for providing access to sensor data from devices within a physical space. -
FIG. 6 illustrates a more specific embodiment of a map association and generation engine. -
FIG. 7 illustrates an example of a map corresponding to a physical space. -
FIG. 8 illustrates a flowchart of a method for generating a map based on nodes of a hierarchical graph that is configured to provide access to sensor data from devices within a physical space - In the realm of Internet of Things (IoT) devices, there are unique challenges associated with managing the devices, including challenges in managing a representation of the devices as they relate to their physical environment, challenges with handling the vast amounts of data generated by the devices, and challenges with managing user access to the devices and user access rights for associating devices with spaces. For instance, a large organization may own several campuses in different geographical locations. Each of these campuses could be made of a large number of buildings, each of which could have many floors. Each of these floors, in turn could have a large number of physical spaces (e.g., conference rooms, offices, common areas, laboratories, etc.). Each of these physical spaces could include a number of objects, such as desks, chairs, lab equipment, etc. Each of these physical spaces and/or objects in the physical spaces could be associated with a number of IoT devices, each of which could include a number of sensors other data-generating hardware. Prior approaches have failed to efficiently represent these physical spaces and IoT devices, while providing efficient access to the data generated by the IoT devices. Additionally, prior approaches have failed to provide efficient mechanisms for managing user access as it relates to devices (e.g., user access rights for accessing sensor data and/or user access rights for managing the devices themselves), and/or for managing user access as it relates to physical spaces (e.g., for managing the layout of spaces including their sub-spaces, for managing adding/removing/managing devices in spaces, etc.). For instance, for a large organization, placing all of this data in a single hierarchical graph could result in a graph that is very large both in terms of depth and breadth—and which would require expensive graph traversal operations every time sensor data needs to be updated or accessed.
- In view of this recognition, the inventors have invented a multi-database environment for storing such data. In particular, the multi-database environment can include one or more first data structures (e.g., one or more graphs) that store relatively static information in the form of a topology of the physical environment in which the IoT devices exist, including storing references to the devices themselves. The first data structure(s) are configured to facilitate queries that can quickly identify physical spaces, users, and/or IoT device(s) within physical spaces—regardless of the size of the topology; quick queries could mean a tradeoff that operations updating the first data structure(s) is comparatively expensive. The multi-database environment can also include one or more second data structures that store relatively dynamic information, such as sensor data generated by the IoT devices. The second data structure(s) are configured to efficiently store constantly changing data, and to provide quick access to data generated by an IoT device once that device has been identified using the first data structure(s). Users may be managed within the first data structure(s) (e.g., as user nodes associated with device nodes and/or with nodes relating to physical spaces) and/or within the second data structure(s).
- The first data structure may also include map data corresponding to a particular node of the first data structure, wherein the map data is associated with at least a portion of a map corresponding to the given node. As such, the map data may be used to generate the portion of the map corresponding to the given node. The multi-database environment can also include one or more second data structures that store relatively dynamic information, such as sensor data generated by the IoT devices. The second data structure(s) are configured to efficiently store constantly changing data, and to provide quick access to data generated by an IoT device once that device has been identified using the first data structure(s). This constantly changing data may also be provided to a map generation component, such that the constantly changing data can then be displayed at a generated map corresponding to the physical space associated with the first data structure.
- Some introductory discussion of a computing system will be described with respect to
FIG. 1 . Then, providing access to sensor data from devices within a physical space and generating maps corresponding to the physical space, consistent with the multi-database environment introduced above, will be described with respect toFIGS. 2 through 7 . - Computing systems are now increasingly taking a wide variety of forms. Computing systems may, for example, be handheld devices, appliances, laptop computers, desktop computers, mainframes, distributed computing systems, datacenters, or even devices that have not conventionally been considered a computing system, such as wearables (e.g., glasses). In this description and in the claims, the term “computing system” is defined broadly as including any device or system (or combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by a processor. The memory may take any form and may depend on the nature and form of the computing system. A computing system may be distributed over a network environment and may include multiple constituent computing systems.
- As illustrated in
FIG. 1 , in its most basic configuration, acomputing system 100 typically includes at least onehardware processing unit 102 andmemory 104. Thememory 104 may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term “memory” may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, the processing, memory and/or storage capability may be distributed as well. - The
computing system 100 also has thereon multiple structures often referred to as an “executable component”. For instance, thememory 104 of thecomputing system 100 is illustrated as includingexecutable component 106. The term “executable component” is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods, and so forth, that may be executed on the computing system, whether such an executable component exists in the heap of a computing system, or whether the executable component exists on computer-readable storage media. - In such a case, one of ordinary skill in the art will recognize that the structure of the executable component exists on a computer-readable medium such that, when interpreted by one or more processors of a computing system (e.g., by a processor thread), the computing system is caused to perform a function. Such structure may be computer-readable directly by the processors (as is the case if the executable component were binary). Alternatively, the structure may be structured to be interpretable and/or compiled (whether in a single stage or in multiple stages) so as to generate such binary that is directly interpretable by the processors. Such an understanding of example structures of an executable component is well within the understanding of one of ordinary skill in the art of computing when using the term “executable component”.
- The term “executable component” is also well understood by one of ordinary skill as including structures that are implemented exclusively or near-exclusively in hardware, such as within a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other specialized circuit. Accordingly, the term “executable component” is a term for a structure that is well understood by those of ordinary skill in the art of computing, whether implemented in software, hardware, or a combination. In this description, the terms “component”, “service”, “engine”, “module”, “control”, or the like may also be used. As used in this description and in the case, these terms (whether expressed with or without a modifying clause) are also intended to be synonymous with the term “executable component”, and thus also have a structure that is well understood by those of ordinary skill in the art of computing.
- In the description that follows, embodiments are described with reference to acts that are performed by one or more computing systems. If such acts are implemented in software, one or more processors (of the associated computing system that performs the act) direct the operation of the computing system in response to having executed computer-executable instructions that constitute an executable component. For example, such computer-executable instructions may be embodied on one or more computer-readable media that form a computer program product. An example of such an operation involves the manipulation of data.
- The computer-executable instructions (and the manipulated data) may be stored in the
memory 104 of thecomputing system 100.Computing system 100 may also containcommunication channels 108 that allow thecomputing system 100 to communicate with other computing systems over, for example,network 110. - While not all computing systems require a user interface, in some embodiments, the
computing system 100 includes auser interface 112 for use in interfacing with a user. Theuser interface 112 may includeoutput mechanisms 112A as well asinput mechanisms 112B. The principles described herein are not limited to theprecise output mechanisms 112A orinput mechanisms 112B as such will depend on the nature of the device. However,output mechanisms 112A might include, for instance, speakers, displays, tactile output, holograms and so forth. Examples ofinput mechanisms 112B might include, for instance, microphones, touchscreens, holograms, cameras, keyboards, mouse of other pointer input, sensors of any type, and so forth. - Embodiments described herein may comprise or utilize a special purpose or general-purpose computing system including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Embodiments described herein also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computing system. Computer-readable media that store computer-executable instructions are physical storage media. Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: storage media and transmission media.
- Computer-readable storage media includes NAND flash memory or other flash memory, RAM, DRAM, SRAM, ROM, EEPROM, CD-ROM or other optical disk storage, solid-state disk storage, magnetic disk storage or other storage devices, or any other physical and tangible storage medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computing system.
- A “network” is defined as one or more data links that enable the transport of electronic data between computing systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computing system, the computing system properly views the connection as a transmission medium. Transmissions media can include a network and/or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computing system. Combinations of the above should also be included within the scope of computer-readable media.
- Further, upon reaching various computing system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computing system RAM and/or to less volatile storage media at a computing system. Thus, it should be understood that storage media can be included in computing system components that also (or even primarily) utilize transmission media.
- Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general purpose computing system, special purpose computing system, or special purpose processing device to perform a certain function or group of functions. Alternatively, or in addition, the computer-executable instructions may configure the computing system to perform a certain function or group of functions. The computer executable instructions may be, for example, binaries or even instructions that undergo some translation (such as compilation) before direct execution by the processors, such as intermediate format instructions such as assembly language, or even source code.
- Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computing system configurations, including, traditional computing systems such as smartphones, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, datacenters, wearables (such as glasses, watches, etc.) and the like. In modern computing systems, in the age of Internet of Things (IoT), computing system configurations may be virtually any type of device including (but most certainly not limited to) smart luggage, smart clothing, smart jewelry, smart drinking bottles, smart skate boards, smart golf clubs, smart toys, smart brewing machines, smart wallets, smart home and business automation gear, smart appliances, smart furniture, etc. The invention may also be practiced in distributed system environments where local and remote computing systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.
- Those skilled in the art will also appreciate that the invention may be practiced in a cloud computing environment. Cloud computing environments may be distributed, although this is not required. When distributed, cloud computing environments may be distributed internationally within an organization and/or have components possessed across multiple organizations. In this description and the following claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of “cloud computing” is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.
- Reference is made frequently herein to IoT devices. As used herein, an IoT device can include any device that is connected to a network (whether that be a personal area network, local area network, wide area network, and/or the Internet) and that interacts with a physical environment (whether that be to control or influence some aspect of a physical environment, and/or to receive sensor data from a physical environment). As such, references to IoT devices herein should be interpreted broadly to include vast categories of devices, regardless of how those devices may be named or marketed. From a computing perspective, IoT devices may range from fairly complex (e.g., such as being embodied on a general-purpose computer system), to fairly simple (e.g., such as being embodied within a special-purpose microcontroller environment).
-
FIG. 2 illustrates anexample environment 200 for providing access to sensor data from devices within a physical space. As illustrated, theenvironment 200 includes a user computer system 202A. The user computer system 202A may be embodied, for example, bycomputer system 100, as described with respect toFIG. 1 . The user computer system 202A may comprise any type of computer system that is configured to communicate with, and utilize the functionality of, aserver computer system 210, which is described later. In an example, the user computer system 202A may comprise a desktop computer, a laptop computer, a tablet, a smartphone, and so forth. Notably, while theenvironment 200 includes a single user computer system 202A, theellipses 202B represents that any number of user computer systems may communicate with, and utilize the functionality of, theserver computer system 210. - The
server computer system 210 is configured to receive, store, and provide access to sensor data from devices (such as IoT devices) located within physical spaces (e.g., a room within a building), as further described herein. Again, theserver computer system 210 may be embodied, for example, bycomputer system 100, as described with respect toFIG. 1 . Theserver computer system 210 may comprise any type of computer system, including any combination of hardware and/or software that is configured to provide access to sensor data from devices located within particular physical spaces. - As shown, the
server computer system 210 may include various engines, functional blocks, and components, including (as examples) agraph engine 220, aproperty store 230, a rules and permissions store 240, a map association andgeneration engine 250, a tenant andresource rules store 260, and adata analysis engine 270, each of which may also include additional engines, functional blocks, and components (e.g., an object type store 221 within the graph engine 220). The various engines, components, and/or functional blocks of theserver computer system 210 may be implemented on a single computer system, or may be implemented as a distributed computer system that includes elements resident in a cloud environment, and/or that implement aspects of cloud computing (i.e., at least one of the various illustrated engines may be implemented locally, while at least one other engine may be implemented remotely). In addition, the various engines, functional blocks, and/or components of theserver computer system 210 may be implemented as software, hardware, or a combination of software and hardware. - Notably, the configuration of the
server computer system 210 illustrated inFIG. 2 is shown only for exemplary purposes. As such, theserver computer system 210 may include more or less than the engines, functional blocks, and/or components illustrated inFIG. 2 . In particular, theellipses 261 represent that any number of engines, functional blocks, and/or components may be utilized within the server computer system. Although not illustrated, the various engines of theserver computer system 210 may access and/or utilize a processor and memory, such as theprocessor 102 and thememory 104 ofFIG. 1 , as needed, to perform their various functions. - As briefly introduced, the
server computer system 210 includes thegraph engine 220, theproperty store 230, the rules and permissions store 240, the map association andgeneration engine 250, the tenant andresource rules store 260, and thedata analysis engine 270. Thegraph engine 220 may be configured to generate, store, and/or manage one or more hierarchical graphs (e.g.,hierarchical graph 310 ofFIG. 3 ) that defines a topology of areas and sub-areas of a physical space. For instance,FIG. 3 illustrates ahierarchical graph 310 that includes a topology of nodes associated with a physical space comprising “building 1” (e.g., building node 302). Thehierarchical graph 310 also represents areas and sub-areas of “building 1,” such as different floors (i.e.,floor node 304A,floor node 304B, and floor node 304C, all of which are sub-nodes of building node 302), as well as different rooms (i.e.,conference room node 306A,conference room node 306B,conference room node 306C, andoffice node 306D) associated with each floor. Although not shown, each of theroom nodes 306A-306A could be associated with additional sub-nodes representing physical objects in the rooms, such as desks, chairs, tales, computer, lab equipment, etc. - Any node in the
hierarchical graph 310 could be associated with devices/sensors and/or users. For example, the various room nodes (i.e., theconference room node 306A and theoffice node 306D) may also be associated with devices and sensors, and the room nodes and/or the device/sensor nodes may be associated with user nodes. Similarly,FIG. 4 shows arelated graph 410, that includesdevice nodes sensor nodes 422A-422C. While only seven nodes associated with areas/sub-areas are illustrated inFIG. 3 , theellipses 308 represents that any number of nodes that are associated with areas/sub-areas and devices/sensors may be utilized when practicing the principles described herein (whether those nodes be added or deleted in a horizontal direction (breadth) or a vertical direction (depth)). Furthermore, the topology of the graph may be continuously modified via adding or deleting nodes of the graph (in a horizontal direction or vertical direction). For instance, using the example ofFIG. 3 , a number of additional building nodes associated with different buildings than building 1 (corresponding to building node 302), each of which additional buildings may include additional nodes corresponding to floors, rooms, and so forth, may also be included within thegraph 310. - In some embodiments, the
hierarchical graph 310 may be stored within a relational database, though any type of database could be used. Additionally, regardless of the type of graph used, the full paths in the graph for each given node may be stored as metadata in the node to increase the performance and efficiency of querying thehierarchical graph 310. In this way, identification (e.g., via a query) of any ancestral node or child node (i.e., children nodes, grandchildren nodes, great-grandchildren nodes, and so on) of a given node may be performed in an order of one operation (i.e., an O(1) operation). For instance, a query that requests each node having a path that starts with “building1/floor3” (i.e., corresponding to the floor node 304C) may identifyconference room 3 and office 1 (i.e., corresponding toconference room node 306C andoffice node 306D, respectively) as being children of the floor node 304C in an O(1) operation. - Notably, even if the
conference room node 306C and theoffice node 306D were grandchildren, great-grandchildren, and so on, of the floor node 304C, a request for identification of each node having a path that starts with “building1/floor3” could result in identification of theconference room node 306C and theoffice node 306D (as well as any nodes between the floor node 304C and theconference room node 306C/theoffice node 306D) in an O(1) operation. Accordingly, paths associated with each node may be automatically computed and saved, which effectively tracks a primary identification for each node of the graph. While a cost is incurred upfront to generate and store each path (e.g., in connection with the addition and/or removal of one or more nodes to within the graph), the graph may be quickly and efficiently traversed to identify nodes and relationships between nodes within the graph than traditional traversing of graphs. By storing primarily static information in the graph, however, the need to generate/store these paths can be relatively infrequent. - Returning to
FIG. 2 , as illustrated, thegraph engine 220 includes various components that may comprise any combination of appropriate hardware and/or software, including an object type store 221, anupdate engine 222, and aquery engine 223. Notably, theellipses 224 represents that any number of components may be included with the graph engine 220 (i.e., more or less than the components illustrated within the graph engine 220). - The object type store 221 comprises a data store of node object types that can be selected to create additional nodes within the
graph 310. For instance, in addition to the node object types of buildings, floors, and rooms that are explicitly shown inFIG. 3 , any number of object types associated with areas/sub-areas of physical spaces (as well as devices/sensors and users/individuals, as further described herein) may be used within thegraph 310, including but not limited to organizations (e.g., businesses), geographic regions (e.g., continents, countries, states, cities, counties, and so forth), types of areas (e.g., buildings, farms, houses, apartments, conference rooms, offices, bathrooms, breakrooms, study areas, desks, chairs, and so forth), types of devices (e.g., thermostat, projector, paper towel dispenser, television, computer, and so forth), types of sensors (e.g., thermocouple, thermistor, humidity sensor, CO2 sensor, Geiger counter), and so forth. Additionally, the object type store 221 may be extensible, such that additional object types may be created on demand. - The
update engine 222 may be configured to update thehierarchical graph 310 with any changes made to the graph. For instance, theupdate engine 222 may update the graph with additional nodes, update the graph with less nodes (e.g., deleted nodes), update nodes with new or modified properties, update nodes with new or modified paths, and perform any other operations associated with modifying or updating the graph. - The
query engine 223 may be configured to allow for performing queries to thehierarchical graph 310. In particular, thequery engine 223 may be configured to receive queries, generate query plans, build responses to queries, and/or perform any other operations associated with receiving and responding to queries of thehierarchical graph 310. - As briefly introduced, the
server computer system 210 further includesdata analysis engine 270. Thedata analysis engine 270 may be configured to receive, gather, manage, and process data received from devices/sensors located within a physical space (associated with the hierarchical graph that defines the topology of the physical space). For instance,FIG. 2 illustrates various devices and sensors located within aphysical space 280. In particular, thephysical space 280 comprises various areas and sub-areas, including area/sub-area 281A, area/sub-area 281B, and area/sub-area 281C. Each of the sub-areas includes a single device having a single sensor (i.e., area/sub-area 281A includesdevice 290 A having sensor 291A, area/sub-area 281B includesdevice 290 B having sensor 291B, and area/sub-area 281C includesdevice 290 C having sensor 291C). Notably, while each of the areas/sub-areas within thephysical space 280 includes a single device having a single sensor, the ellipses 290 represents that there may be any number of areas/sub-areas within thephysical space 280, each of the areas/sub-areas including any number of devices having any number of sensors (including zero devices/sensors). - Notably, the devices and sensors may include any type of devices/sensors, including but not limited to devices/sensors associated with detecting temperature, CO2, light, pressure, toxic chemicals, humidity, and so forth. As such, the combination of the devices 290 (i.e., the
device 290A through thedevice 290C) and the sensors 291 (i.e., thesensor 291A through thesensor 291C) may be configured to capture sensor data (e.g., changes in temperature) and send the captured data to thedata analysis engine 270. The sensors may provide data to thedata analysis engine 270 periodically and/or continuously. Thus, in some implementations, thedata analysis engine 270 may receive, gather, manage, and process real-time or near real-time data received from the sensors. The sensors may actively push data to thedata analysis engine 270, or may only provide it upon request. - The
data analysis engine 270 may then be configured to receive, gather, manage, and process data received from such devices/sensors. In particular, as illustrated, thedata analysis engine 270 may include adata store 271 that is configured to organize, store, and allow access to received sensor data. Thedata store 271 may comprise any type of data store that is configured to manage dynamic, frequently changing data such as sensor data, and that provides quick and efficient performance. In an example, thedata store 271 may comprise a key-value database. For instance, thedata store 271 may comprise a REDIS™ CACHE. While thedata store 271 may store some data permanently, thedata store 271 only store some data temporarily. For example, when receiving real-time or near real-time data, thedata analysis engine 270 may processes large quantities of data, making it infeasible and/or undesirable to store it permanently. Data associated with a particular device (e.g., sensor data) may also be linked with device nodes of the hierarchical graph (e.g., the hierarchical graph 410), such that upon identification of a device node within the hierarchical graph, sensor data associated with the device corresponding to the device node may also be accessed, as further described herein. - As shown, the
data analysis engine 270 further includes aquery engine 272. Thequery engine 272 may be configured to allow for performing queries to thedata store 271. In particular, thequery engine 272 may be configured to receive queries, generate query plans, build responses to queries, and/or perform any other operations associated with receiving and responding to queries of thedata store 271. -
FIG. 4 illustrates anenvironment 400 includinghierarchical graph 410 comprising area/sub-area nodes, as well as device/sensor nodes that are each associated with one or more area/sub-area nodes. As shown, theconference room node 306A is associated withdevice node 420A (having a correspondingsensor node 422A) and theoffice node 306D is associated with thedevice node 420B (having two corresponding sensor nodes, thesensor node 422B and thesensor node 422C). Additionally,FIG. 4 includes a representation of an actual physical space 402 (associated with building 1) that corresponds to thebuilding node 302. - As illustrated, the
physical space 402 also comprisesconference room 406A (associated withconference room 1 and corresponding to theconference room node 306A) that includes the actualphysical device 440A having thesensor 442A, as well asoffice 406D (associated withoffice 1 and corresponding to theoffice node 306D) that includes the actualphysical device 440B having both thesensor 442B and thesensor 442C. In a specific example, thedevice 440A may correspond to a thermostat that includes a thermocouple (i.e., thesensor 442A) for measuring temperature. Such temperature measurements may then be sent to the data analysis engine for managing, storing, and processing the received sensor data. - Additionally, as illustrated in
FIG. 4 , user nodes (e.g., user node 430) may be included within thehierarchical graph 410 as being associated with one or more area/sub-area nodes (though they could additionally, or alternatively, be associated with sensor/device nodes). In particular,FIG. 4 shows the user node 430 being associated with theoffice node 306D. In a specific example, the user 1 (i.e., corresponding to the user node 330) may comprise an individual that has been assigned to office 1 (i.e., corresponding to theoffice node 306D). In this example, user node 430 could be used to control a user's access tooffice node 306D, including, for example, the user's ability to modifyoffice node 306D, to attached nodes tooffice node 306D, remove nodes fromoffice node 306D, or modify nodes that are already attached tooffice node 306D, etc. In some embodiment, associating user node 430 withoffice node 306D applies the user node's permissions to all nodes hierarchically belowoffice node 306D inhierarchical graph 410. Similar application of access rights could apply when associating a user node with a sensor/device node. - Notably, regardless of object/node type (e.g., area/sub-area nodes, device nodes, sensor nodes, user nodes), data and/or metadata associated with the node may be stored in the hierarchical graph (e.g., the
hierarchical graph 310 or the hierarchical graph 410), thedata store 271 of thedata analysis engine 270, or any other appropriate location associated with theserver computer system 210. - As briefly introduced, the
server computer system 210 further includesproperty store 230, rules and permissions store 240, map association andgeneration engine 250, and tenant andresource store 260. Theproperty store 230 may comprise a data store that includes properties associated with nodes of thehierarchical graph 310. For instance, particular properties may automatically be associated with particular object types (i.e., node types), as well as children of such object types. In a more particular example, a property associated with occupancy of a chair within a room may propagate to the room itself (i.e., showing that the room is occupied). Furthermore, as discussed with respect to the object type store 231, the property store may also be extensible, such that properties may be created and associated with any given node, and potentially associated with ancestral or children nodes of the given node. - The rules and permissions store 240 may include various rules and permissions associated with particular roles assigned to users. For instance, based on a particular role (e.g., an administrator) assigned to a user, the user may have access to perform various operations, including adding/deleting nodes, modifying nodes, accessing/modifying functionality of various devices (e.g., locking doors), and so forth. The rules/permissions stored in the rules and permissions store 240 may be applied to various nodes in the hierarchical graph, whether those be area/sub-area nodes, sensor/device nodes, or user nodes. The rules/permissions stored in the rules and permissions store 240 may additionally, or alternatively, be applied data in the
data store 271. In some embodiments, user nodes that are associated with nodes in the graph (e.g., areas or devices/sensors) grant corresponding users access to the associated node, and user rules/permissions associated with those user nodes are managed in the rules and permissions store 240. - The map association and
generation engine 250 may be configured to perform numerous functions with respect to associating maps with the hierarchical graph (and devices providing data to the data store), and/or generating the hierarchical graph, itself. For instance, the map association andgeneration engine 250 may be able to generate thehierarchal graph 300 based on user input and/or based on a map. In another example, the map association andgeneration engine 250 may be able to link nodes of the hierarchical graph to locations or devices included within a map. In yet another example, the map association andgeneration engine 250 may further be able to generate a map based on information included within the hierarchical graph corresponding to nodes of the hierarchical graph. - The tenant and resource rules store 260 may include rules associated with how resources, permissions, properties, and so forth are to be handled for each given entity (e.g., tenant) that utilizes the hierarchical graph.
- Notably, the
ellipses 261 represent that theserver computer system 210 may include any number of components (i.e., whether more or less) than the components illustrated within the server computer system inFIG. 2 . For instance, while both thegraph engine 220 and thedata analysis engine 270 include corresponding query engines (i.e., thequery engine 223 and thequery engine 272, respectively), an overarching query engine may be included within the physical analytics computer system that allows for querying both thegraph engine 220 and thedata analysis engine 270. In this way, a user may be able to generate queries that can traverse the hierarchical graph (e.g., the hierarchical graph 410) to identify one or more devices associated with a particular area/sub-area of the hierarchical graph, as well as current (or previous) sensor data associated with the one or more devices via thedata store 271 and thedata analysis engine 270. -
FIG. 5 illustrates a flowchart of amethod 500 for providing access to sensor data from devices within a physical space. Themethod 500 is described with frequent reference to the environments ofFIGS. 2-4 . As shown, themethod 500 includes identifying one or more areas and one or more sub-areas of the physical space (Act 502). For instance, thebuilding 402, theconference room 406A, and/or theoffice 406D ofFIG. 4 may be identified by the map association andgeneration engine 250. Themethod 500 further includes, based on the one or more identified areas and the one or more identified sub-areas, generating a hierarchical graph that describes a topology of the physical space (Act 504). For instance, based on the identification of the building 402 (and its corresponding areas/sub-areas), thehierarchical graph 410 may be generated by the map association andgeneration engine 250. - Generating the hierarchical graph further includes generating a node for each of the one or more identified areas and each of the one or more identified sub-areas (Act 506). For example, the
hierarchical graph 410 includes various nodes based on an identification of areas/sub-areas associated with thebuilding 402. Generating the hierarchical graph also includes generating a device node for each of one or more devices located within the physical space (Act 508). For instance, an identification of thedevice 440A and thedevice 440B may result in generating thedevice node 420A and thedevice node 420B, respectively. - Generating the device node for each of one or more devices located within the physical space further includes, for a particular one of the one or more areas or the one or more sub-areas, identifying a particular device associated with the particular area or the particular sub-area (Act 510). The particular device may include one or more sensors that generate data. For example, the
device 440A may be identified, as well as thesensor 442A. - Generating the device node for each of one or more devices located within the physical space further includes, for a particular one of the one or more areas or the one or more sub-areas, generating a particular device node within the hierarchical graph that is associated with the particular device (Act 512). The particular device node may be a sub-node of a particular node that was generated for the particular area or the particular sub-area. For instance, the
device node 420A may be generated in response to identifying thedevice 440A, and may further be associated with a particular area/sub-area node (i.e., thedevice node 420A being associated with theconference room node 306A). Additionally, any sensors associated with thedevice 440A may be identified, including thesensor 422A. - The
method 500 further includes generating a database that stores at least sensor data for the one or more devices located within the physical space (Act 514). The database may be associated with, but separate from, the hierarchical graph. For example, thedata store 271 may be generated for managing, storing, and accessing received sensor data. Themethod 500 may further include providing sensor data for the particular device (Act 516). For example, data from thesensor 442A ofdevice 440A may be provided to thedata store 271. In a more specific example, thesensor 442A may be configured to measure CO2 levels, which measurements may be provided by thedevice 440A (or by another device capable of communicating with thedevice 440A) to the data store 271 (and ultimately, the data analysis engine 270). - Providing sensor data for the particular device may also include using the hierarchical graph to identify the particular device within the particular area or the particular sub-area (Act 518). For example, a query provided to the server computer system 210 (and perhaps directly to the graph engine 220) may request an identification of each device (and therefore each device node) associated with a particular area/sub-area (and therefore the particular area/sub-area node corresponding to the particular area/sub-area). Providing sensor data for the particular device may further include, based on having identified the particular device using the hierarchical graph, using the database to identify sensor data corresponding to the particular device (Act 520). For instance, upon identifying the device/device nodes (and the corresponding sensors/sensor nodes), sensor data associated with the devices/sensors may then be identified within the
data store 271. - Accordingly, the principles described herein may allow for logically organizing devices (e.g., Internet of Things (IoT) devices) within physical spaces (or areas/sub-areas of physical spaces), and associating users with devices and/or spaces, thus allowing for intuitive organization and control of a plurality of devices, efficient use of such devices, and granular control of user access rights to devices and/or spaces. For instance, each device associated with a particular area/sub-area (e.g., on a particular floor of a building or a particular room) may be easily shut off or placed in a reduced power state, as location-based groupings of devices are automatically created. In particular, relatively static physical space data (e.g., data regarding floors and rooms of a building) and user access data may be placed in a reliable graph (e.g., a relational database), while more dynamic sensor data may be managed in a more dynamic database (e.g., a key-value database such as a REDIS CACHE).
- The reliability of a hierarchical graph may be supplemented with quickness/efficiency by computing and storing paths associated with each node upfront when adding/removing/modifying nodes in the graph. Computing and storing the paths may then allow for performing queries with respect to ancestral nodes or child nodes of any given node in an O(1) operation. The hierarchical graph and the dynamic database may then be linked such that sensor data stored at the dynamic database may be quickly accessed when querying nodes associated with an area/sub-area within the hierarchical graph. Accordingly, storing the hierarchical graph and the dynamic database within an improved computer system (e.g., within memory and/or persistent storage) may improve the speed and efficiency of the computer system with respect to traversing the hierarchical graph in response to queries, building responses to queries (e.g., surfacing live sensor data associated with a particular area or sub-area of a physical space corresponding to the hierarchical graph), and so forth.
-
FIG. 6 illustrates a more detailed example of the map association andgeneration engine 250 ofFIG. 2 . As shown inFIG. 6 , the map association andgeneration engine 250 includes both amap association engine 660 and amap generation engine 670. Additionally,ellipses 680 illustrates that the map association andgeneration engine 250 may include more or less than the components (e.g., themap association engine 660, themap accessibility engine 661, and so forth) shown inFIG. 6 . - The
map association engine 660 may be configured to link entities (e.g., areas, sub-areas, devices, sensors, and so forth) illustrated within a map of a physical space to nodes of a hierarchical graph that corresponds to the physical space. As illustrated, themap association engine 660 includes both amap accessibility engine 661 and alinking engine 662. Themap association engine 660 may be capable of accessing a map associated with a physical space for which a hierarchical map has been created. - For instance,
FIG. 7 illustrates a map 700 that comprises various areas and sub-areas, including ateam room 701, ateam room 702, anoffice 703, abathroom 704, anoffice 705, anoffice 706, anoffice 707, aconference room 708, aconference room 709, aconference room 710, anoffice 711, anoffice 712, anoffice 713, anoffice 714, anoffice 715, anoffice 716, ateam room 717, anoffice 718, anoffice 719, aconference room 720, ateam room 721, a set ofstairs 722, anoffice 723, and ahallway 724. Additionally, while not shown, the map 700 may also include locations of devices and/or sensors within areas and sub-areas of the map. - Such a map may comprise any file or data format, including but not limited to GEOJSON, portable document format (PDF), DWG, scalable vector graphics (SVG), etc. In some embodiments, a file/data format includes structured data, which can be used by the
map association engine 660 to create identifiers for any given entity (e.g., area, sub-area, device, sensor, and so forth) illustrated within the map. Such embodiments may also allow for adding metadata to entities in addition to these entity identifiers. For instance, the linkingengine 662 may be configured to generate a tag for any given entity within a map (e.g., the team room 701) that defines a link between the entity and a corresponding node of a hierarchical graph that is associated with the same entity. In an example, assume that theoffice 703 of the map 700 inFIG. 7 corresponds to theoffice node 306D of thehierarchical graph 310 inFIG. 3 . In such a case, an identifier associated with both theoffice 703 within the map 700 and theoffice node 306D may be the same. For instance, in the current example, such an identifier may be “Office 1,” though it could be any form of identifier including, for example, a globally-unique identifier (GUID). In some embodiments, linking between a hierarchical graph and a map may be at least partially performed automatically using heuristics and/or machine learning. For instance, links may be automatically generated between a node of a hierarchical graph and an entity of a map when the node and the entity are determined to have the same, or a similar, identifier. - Notably, the linking
engine 662 may also generate a tag for the corresponding node in the hierarchical graph that defines the link between the node and the corresponding entity of the map. As described more fully herein, each area node and sub-area node may also be linked to devices and/or sensors located within the corresponding area or sub-area (e.g., a room) of the physical space corresponding to the hierarchical graph of nodes. As part of such linking, the hierarchical graph of nodes may have access to, whether pulling sensor data or receiving sensor data from, the live sensor data being gathered in thedata store 271. In this way, linking may then allow for providing live data to a rendered view of a map (e.g., the map 700). For instance, based on a motion detector sensing that an individual has entered a room of a physical space for which there is a hierarchical graph, a rendering of the room within a rendered map of the physical space may indicate that the room is occupied. For instance, within the rendered version of the map, a color of the room may change (e.g., from red to green), an occupied symbol may appear, text stating “Occupied” may be illustrated, and so forth. - As briefly described, the map association and generation engine also includes the
map generation engine 670. As illustrated, themap generation engine 670 includes a Binary Large Object (BLOB)type store 671, a BLOBtype extensibility engine 672, and alinking engine 673. Themap generation engine 670 may be configured to generate a map based on data stored within a hierarchical graph that corresponds to a physical space. In some embodiments, each given node of such a hierarchical graph (e.g., the hierarchical graph 310) may include data associated with rendering a portion of a map that corresponds to the given node. For instance, an office node may include data associated with rendering the office corresponding to the node as part of a map. In an example, such data may comprise a Binary Large Object (BLOB), such as a corresponding portion of structured data (e.g., GEOJSON, PDF, DWG, SVG), etc.) usable to visually render a map. In such embodiments, each given node of a hierarchical graph may include a BLOB that comprises sufficient data for rendering at least a portion of a map associated with an entity (e.g., area, sub-area, device, sensor, and so forth) that corresponds to the given node. - As briefly described, the
map generation engine 670 includes aBLOB type store 671. TheBLOB type store 671 may include various types and subtypes of BLOB's, including area BLOB's, sub-area BLOB's, device BLOB's, and sensor BLOB's. Each of these BLOB types may include information related to a corresponding entity (e.g., area, device, sensor), including an identifier of the entity, properties associated with the entity, a location of the entity (e.g., Global Positioning System (GPS) coordinates), rules associated with the entity, and so forth. - In addition, the
BLOB type store 671 may include BLOB types associated with generating at least a portion of a map associated with an area, sub-area, device, or sensor, as well as an associated subtype of BLOB that corresponds to a type of map to be generated. For instance, the BLOB type store may include BLOB types associated with generating a wayfinding map (e.g., a wayfinding floor map); an electrical grid map; a water and sewer map; a heating, ventilation, and air conditioning (HVAC) map; a satellite map; and so forth. Each type of BLOB may be formatted to generate at least a portion of a particular type of map corresponding to a particular area, sub-area, device, or sensor. - Accordingly, each given node of a hierarchical graph may include a BLOB that can be used to generate a portion of a map that corresponds to the area, sub-area, device, or sensor corresponding to the given node. In some embodiments, each node may include multiple different associated BLOB types. For instance, a given area node (e.g., an office node) may include a wayfinding map BLOB type associated with the given area, an HVAC map BLOB type associated with the given area, and a water and sewer map BLOB type associated with the given area. Based on each of these associated BLOB types, multiple different types of maps may be generated that each corresponding to a given area, sub-area, device, or sensor. Notably, each BLOB associated with a particular node may be stored, along with the node, in a corresponding hierarchical graph of the particular node
- As briefly described, the
map generation engine 250 also includes the BLOBtype extensibility engine 672. The BLOB type extensibility engine may allow for creating any type of BLOB. For instance, a user may desire to generate a hierarchical graph for a unique type of physical space, and thus create additional BLOB types corresponding to the unique physical space. - In addition, the
map generation engine 250 includes a linkingengine 673. The linking engine may be configured to link each area node, sub-area node, device node, device node, sensor node, and user node, such that a full map (e.g., the map 700) may be generated that includes the relative positioning of each area, sub-area, device, and sensor in relation to each other. In some embodiments, such linking may comprise including linking information within each BLOB associated with each node, such that relative positioning of each area, sub-area, device, and/or sensor may be determined in relation to each other. - Again, in this way, live sensor data may also be provided to a rendered version of the map (e.g., occupancy of a room based on generated sensor data within the room). In particular, as more fully described herein, the hierarchical graph may also have access to live sensor data stored at the
data store 271. As such, queries may be continually or periodically performed to determine a current status of each device or sensor located within in any given area or sub-area. Then, based on a current status and any associated rules, sensor data may displayed at the rendered map and/or any corresponding changes to the map may be made. For instance, a rule may be created that includes changing an occupancy status of a room when motion is detected within a room (e.g., changing a color of the room within the map to demonstrate current occupancy). Notably, a rendering of the map may also display various levels of granularity based on a zoom level when viewing the rendered map. For instance, when zooming in, the map may show details such as temperature, users within a given area, and so forth, while when zooming out, the map may show less granular details such as simply whether or not a room is occupied. -
FIG. 8 illustrates a flowchart of amethod 800 for generating a map based on nodes of a hierarchical graph that is configured to provide access to sensor data from devices within a physical space. Themethod 800 is described with frequent reference to the environments ofFIGS. 2-7 . As shown inFIG. 8 , themethod 800 includes accessing a hierarchical graph that defines a topology of a physical space and comprises a plurality of nodes (Act 810). The plurality of nodes of the hierarchical graph may comprise a top node for the physical space and a plurality of other nodes coupled, through zero or more intermediate nodes, to the top node of the physical space. One or more of the plurality of nodes may comprise an area node or a sub-area node, wherein each area node and sub-area node represents an area or sub-area within the physical space. One or more of the plurality of nodes also may comprise a device node, wherein each device node represents a device located within the physical space and is configured to provide data or receive control signals. For instance, thehierarchical graph 310 ofFIG. 3 that defines a topology of a physical space and includes a plurality of nodes may be accessed by the map association andgeneration engine 250. - The
method 800 further includes, for a particular node of the plurality of nodes, generating map data corresponding to the particular node (Act 820). The generated map data is associated with generating at least a portion of a map corresponding to the particular node. For instance, themap generation engine 670 may generate a BLOB associated with a particular node of thehierarchical graph 310 that is formatted for generating a portion of a map associated with an area, sub-area, device, and/or sensor corresponding to the particular node. Themethod 800 further includes, for a particular node of the plurality of nodes, storing the generated map data corresponding to the particular node within the hierarchical graph (Act 830). For example, the generated BLOB may be stored at thehierarchical graph 310. The stored BLOB associated with the particular node may then be used to generate the portion of the map corresponding to the particular node, as further described herein. - Accordingly, hierarchical graphs corresponding to a physical space may be utilized to generate maps displaying live (i.e., real-time or very close to real-time) sensor data. In particular, BLOB's that include data for rendering at least a portion of a map may be generated for each given area node, sub-area node, device node, and/or sensor node of a hierarchical graph corresponding to a physical space. The BLOB's corresponding to each node may then be linked such that a positioning of each entity (i.e., area, sub-area, device, and/or sensor) in relation to each other within the map may be properly rendered. Live sensor data may then be provided for display at the map via the live sensor database (i.e., the data store 271).
- Additionally, multiple BLOB types that are each associated with a different type of map (e.g., wayfinding map, HVAC map, and so forth) may be generated for any given node, such that multiple types of maps associated with a given physical space may be generated from a hierarchical graph corresponding to the given physical space. In this way, various types of custom maps associated with a given space that are configured to illustrate live sensor data may be stored and generated.
- Furthermore, already-created maps of various formats (e.g., GEOJSON, PDF, DWG, SVG, and so forth) corresponding to a given physical space may also be linked to a hierarchical graph of nodes corresponding to the same given physical space. As further described herein, the hierarchical graph may also have access to a database of live sensor data, which may then allow for rendering such live sensor data at the already-created map.
- Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above, or the order of the acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.
- The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
Claims (20)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/964,751 US10484829B1 (en) | 2018-04-27 | 2018-04-27 | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users |
US16/685,975 US11019458B2 (en) | 2018-04-27 | 2019-11-15 | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/964,751 US10484829B1 (en) | 2018-04-27 | 2018-04-27 | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/685,975 Continuation US11019458B2 (en) | 2018-04-27 | 2019-11-15 | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users |
Publications (2)
Publication Number | Publication Date |
---|---|
US20190335300A1 true US20190335300A1 (en) | 2019-10-31 |
US10484829B1 US10484829B1 (en) | 2019-11-19 |
Family
ID=68293082
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/964,751 Active US10484829B1 (en) | 2018-04-27 | 2018-04-27 | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users |
US16/685,975 Active 2038-06-29 US11019458B2 (en) | 2018-04-27 | 2019-11-15 | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/685,975 Active 2038-06-29 US11019458B2 (en) | 2018-04-27 | 2019-11-15 | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users |
Country Status (1)
Country | Link |
---|---|
US (2) | US10484829B1 (en) |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111028350A (en) * | 2019-11-21 | 2020-04-17 | 大连理工大学 | Method for constructing grid map by using binocular stereo camera |
US20200162847A1 (en) * | 2018-04-27 | 2020-05-21 | Microsoft Technology Licensing, Llc | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users |
US10951482B2 (en) | 2018-05-16 | 2021-03-16 | Microsoft Technology Licensing, Llc | Device identification on a building automation control network |
US11032154B2 (en) * | 2018-12-21 | 2021-06-08 | Cisco Technology, Inc. | Graphical user interface for displaying a hierarchical network topology in a single site view |
CN113408997A (en) * | 2020-03-17 | 2021-09-17 | 北京四维图新科技股份有限公司 | Processing method, device and system for high-precision map drawing task |
US11456915B2 (en) | 2018-05-21 | 2022-09-27 | Microsoft Technology Licensing, Llc | Device model templates |
US20230244440A1 (en) * | 2020-07-05 | 2023-08-03 | Orange | Selection and control of connected objects from a symbolic representation of a topography of a site |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10747578B2 (en) | 2018-04-27 | 2020-08-18 | Microsoft Technology Licensing, Llc | Nested tenants |
US11580843B2 (en) * | 2020-09-08 | 2023-02-14 | Alarm.Com Incorporated | Intelligent emergency response for multi-tenant dwelling units |
Family Cites Families (126)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5394035A (en) | 1993-08-25 | 1995-02-28 | Novitas, Incorporated | Rate of change comparator |
US6067093A (en) * | 1996-08-14 | 2000-05-23 | Novell, Inc. | Method and apparatus for organizing objects of a network map |
US5877766A (en) | 1997-08-15 | 1999-03-02 | International Business Machines Corporation | Multi-node user interface component and method thereof for use in accessing a plurality of linked records |
US6298425B1 (en) | 1999-01-12 | 2001-10-02 | Compaq Computer Corp. | Computer disk management system using doublet A-B logging |
JP3763992B2 (en) | 1999-03-30 | 2006-04-05 | 富士通株式会社 | Data processing apparatus and recording medium |
CA2359168A1 (en) | 2000-10-25 | 2002-04-25 | John Doucette | Design of meta-mesh of chain sub-networks |
US20020199017A1 (en) | 2001-06-25 | 2002-12-26 | Russell Lance W. | Routing meta data for network file access |
US20040003341A1 (en) | 2002-06-20 | 2004-01-01 | Koninklijke Philips Electronics N.V. | Method and apparatus for processing electronic forms for use with resource constrained devices |
US7047226B2 (en) | 2002-07-24 | 2006-05-16 | The United States Of America As Represented By The Secretary Of The Navy | System and method for knowledge amplification employing structured expert randomization |
US7487234B2 (en) | 2002-09-17 | 2009-02-03 | International Business Machines Corporation | Context conflict resolution and automatic context source maintenance |
US7366674B2 (en) | 2003-01-24 | 2008-04-29 | Diegane Dione | Occupant management method, system, and program product |
US7457815B2 (en) | 2003-03-27 | 2008-11-25 | Apple Inc. | Method and apparatus for automatically providing network services |
US20040267694A1 (en) | 2003-06-30 | 2004-12-30 | Satoshi Sakai | Machine-readable medium & data management system and method for tracking real-world objects |
US7664573B2 (en) | 2003-09-26 | 2010-02-16 | Siemens Industry, Inc. | Integrated building environment data system |
US7457817B2 (en) | 2003-12-12 | 2008-11-25 | Oracle International Corporation | Versioning in an integration platform |
US7747464B2 (en) | 2004-02-18 | 2010-06-29 | Jansen Michael E | Motion picture theater and associated promotion |
US7512450B2 (en) * | 2004-03-25 | 2009-03-31 | Siemens Building Technologies, Inc. | Method and apparatus for generating a building system model |
US20050262081A1 (en) * | 2004-05-19 | 2005-11-24 | Newman Ronald L | System, method and computer program product for organization and annotation of related information |
US20060015376A1 (en) | 2004-07-16 | 2006-01-19 | Sap Aktiengesellschaft | Method and system for employee reservation of meeting rooms |
JP4808409B2 (en) | 2005-01-14 | 2011-11-02 | 株式会社日立製作所 | Sensor network system, sensor data search method and program |
JP4885463B2 (en) | 2005-03-03 | 2012-02-29 | 株式会社日立製作所 | Sensor network system, sensor data processing method and program |
WO2006110982A1 (en) | 2005-04-18 | 2006-10-26 | Research In Motion Limited | System and method for flexible visual representation of presentation components |
US7752491B1 (en) | 2005-05-05 | 2010-07-06 | Seagate Technology Llc | Methods and structure for on-the-fly head depopulation in a dynamically mapped mass storage device |
US7916421B1 (en) | 2005-05-05 | 2011-03-29 | Seagate Technology Llc | Methods and structure for recovery of write fault errors in a dynamically mapped mass storage device |
US7653847B1 (en) | 2005-05-05 | 2010-01-26 | Seagate Technology Llc | Methods and structure for field flawscan in a dynamically mapped mass storage device |
US7617358B1 (en) | 2005-05-05 | 2009-11-10 | Seagate Technology, Llc | Methods and structure for writing lead-in sequences for head stability in a dynamically mapped mass storage device |
US7620772B1 (en) | 2005-05-05 | 2009-11-17 | Seagate Technology, Llc | Methods and structure for dynamic data density in a dynamically mapped mass storage device |
US7685360B1 (en) | 2005-05-05 | 2010-03-23 | Seagate Technology Llc | Methods and structure for dynamic appended metadata in a dynamically mapped mass storage device |
US7840353B2 (en) * | 2005-05-17 | 2010-11-23 | The Boards of Trustees of the University of Illinois | Method and system for managing a network of sensors |
US7401089B2 (en) | 2005-08-17 | 2008-07-15 | Microsoft Corporation | Storage reports file system scanner |
US20070100872A1 (en) | 2005-11-03 | 2007-05-03 | Bodin William K | Dynamic creation of user interfaces for data management and data rendering |
US20070162315A1 (en) | 2006-01-06 | 2007-07-12 | Microsoft Corporation | Space reservation system |
US7840567B2 (en) | 2006-01-17 | 2010-11-23 | International Business Machines Corporation | Method and apparatus for deriving optimal physical space and ambiance conditions |
US8560569B2 (en) | 2006-01-27 | 2013-10-15 | Emc Corporation | Method and apparatus for performing bulk file system attribute retrieval |
US7777632B2 (en) | 2006-02-06 | 2010-08-17 | Cooper Technologies Company | Acoustic occupancy sensor |
WO2007140321A2 (en) | 2006-05-26 | 2007-12-06 | Mix & Meet, Inc. | System and method for scheduling meetings and user interface |
US20070288291A1 (en) | 2006-06-12 | 2007-12-13 | Earle Kevin C | System and method for dynamic meeting notification |
US7590652B2 (en) | 2006-08-18 | 2009-09-15 | Isilon Systems, Inc. | Systems and methods of reverse lookup |
CA2671781A1 (en) | 2006-12-15 | 2008-06-19 | Aftercad Software Inc. | Visual method and system for rdf creation, manipulation, aggregation, application and search |
US20080183483A1 (en) | 2007-01-17 | 2008-07-31 | Hart Marcia A | Office management solution |
US20080277486A1 (en) | 2007-05-09 | 2008-11-13 | Johnson Controls Technology Company | HVAC control system and method |
US20090006143A1 (en) | 2007-06-26 | 2009-01-01 | Rearden Commerce, Inc. | System and Method for Interactive Natural Language Rebooking or Rescheduling of Calendar Activities |
JP5024351B2 (en) | 2008-11-28 | 2012-09-12 | 株式会社ニコン | Image file generation device, camera, and image file generation program |
US8301297B2 (en) | 2009-03-04 | 2012-10-30 | Bell And Howell, Llc | System and method for continuous sorting operation in a multiple sorter environment |
US20100299517A1 (en) | 2009-05-22 | 2010-11-25 | Nuvon, Inc. | Network System with a Plurality of Networked Devices with Various Connection Protocols |
US8743198B2 (en) | 2009-12-30 | 2014-06-03 | Infosys Limited | Method and system for real time detection of conference room occupancy |
US9741020B2 (en) | 2010-01-27 | 2017-08-22 | Google Inc. | Conference room scheduling based on attendee locations |
US9257042B2 (en) | 2010-03-11 | 2016-02-09 | Inrix, Inc. | Learning road feature delay times based on aggregate driver behavior |
US9147039B2 (en) | 2010-09-15 | 2015-09-29 | Epic Systems Corporation | Hybrid query system for electronic medical records |
US8732039B1 (en) | 2010-12-29 | 2014-05-20 | Amazon Technologies, Inc. | Allocating regional inventory to reduce out-of-stock costs |
US8797159B2 (en) | 2011-05-23 | 2014-08-05 | Crestron Electronics Inc. | Occupancy sensor with stored occupancy schedule |
US9020987B1 (en) | 2011-06-29 | 2015-04-28 | Emc Corporation | Managing updating of metadata of file systems |
US9552367B2 (en) | 2011-09-16 | 2017-01-24 | Ca, Inc. | System and method for network file system server replication using reverse path lookup |
US9143402B2 (en) | 2012-02-24 | 2015-09-22 | Qualcomm Incorporated | Sensor based configuration and control of network devices |
CA2877520A1 (en) | 2012-06-15 | 2013-12-19 | 650438 Alberta Ltd. | Method and system for separation of suspensions |
US10181139B2 (en) | 2012-10-14 | 2019-01-15 | John M Glass | Automated workspace usage management methods and apparatus |
US9411558B2 (en) | 2012-10-20 | 2016-08-09 | Luke Hutchison | Systems and methods for parallelization of program code, interactive data visualization, and graphically-augmented code editing |
US9230235B2 (en) | 2012-11-09 | 2016-01-05 | Accenture Global Services Limited | Room inventory management |
US9361306B1 (en) | 2012-12-27 | 2016-06-07 | Emc Corporation | Managing concurrent write operations to a file system transaction log |
US9542396B1 (en) | 2012-12-27 | 2017-01-10 | EMC IP Holding Company LLC | Managing a file system to avoid unnecessary replay of a transaction log |
US9361139B1 (en) * | 2013-03-15 | 2016-06-07 | Ca, Inc. | System and method for visualizing virtual system components |
US9330116B2 (en) * | 2013-03-15 | 2016-05-03 | Oracle International Corporation | Determining hierarchical paths to nodes |
US20140297206A1 (en) | 2013-03-28 | 2014-10-02 | Kaspar Llc | Universal Smart Energy Transformer Module |
US9471500B2 (en) | 2013-04-12 | 2016-10-18 | Nec Corporation | Bucketized multi-index low-memory data structures |
US20140351181A1 (en) | 2013-05-24 | 2014-11-27 | Qualcomm Incorporated | Requesting proximate resources by learning devices |
US10257705B2 (en) | 2013-06-10 | 2019-04-09 | Apple Inc. | Configuring wireless accessory devices |
US9311429B2 (en) | 2013-07-23 | 2016-04-12 | Sap Se | Canonical data model for iterative effort reduction in business-to-business schema integration |
JP2017513138A (en) | 2014-03-31 | 2017-05-25 | コファックス, インコーポレイテッド | Predictive analysis for scalable business process intelligence and distributed architecture |
JP6168475B2 (en) * | 2014-04-10 | 2017-07-26 | 新日鉄住金ソリューションズ株式会社 | Graph generation apparatus, graph generation method, and graph generation program |
WO2015160346A1 (en) | 2014-04-16 | 2015-10-22 | Abb Inc. | System and method for automated and semiautomated configuration of facility automation and control equipment |
US10560975B2 (en) | 2014-04-16 | 2020-02-11 | Belkin International, Inc. | Discovery of connected devices to determine control capabilities and meta-information |
US9551594B1 (en) | 2014-05-13 | 2017-01-24 | Senseware, Inc. | Sensor deployment mechanism at a monitored location |
US8868375B1 (en) * | 2014-05-21 | 2014-10-21 | Locometric Ltd | Generation of a floor plan |
US9955318B1 (en) | 2014-06-05 | 2018-04-24 | Steelcase Inc. | Space guidance and management system and method |
US9766079B1 (en) | 2014-10-03 | 2017-09-19 | Steelcase Inc. | Method and system for locating resources and communicating within an enterprise |
US20160004759A1 (en) * | 2014-07-03 | 2016-01-07 | Adarsh Ramakrishnan | Platform for Managing and Visualizing Data on a Computer |
US20160012556A1 (en) | 2014-07-14 | 2016-01-14 | Rocket Lawyer Incorporated | Method and System of Creating and Signing Electronic Documents With Increased Party-Signatory Accuracy and Execution Integrity |
US10078865B2 (en) | 2014-09-08 | 2018-09-18 | Leeo, Inc. | Sensor-data sub-contracting during environmental monitoring |
US10063439B2 (en) | 2014-09-09 | 2018-08-28 | Belkin International Inc. | Coordinated and device-distributed detection of abnormal network device operation |
WO2016054629A1 (en) | 2014-10-03 | 2016-04-07 | Skejul Inc. | Systems and methods for private schedule coordination and event planning |
US9852388B1 (en) | 2014-10-03 | 2017-12-26 | Steelcase, Inc. | Method and system for locating resources and communicating within an enterprise |
US9703830B2 (en) * | 2014-10-09 | 2017-07-11 | International Business Machines Corporation | Translation of a SPARQL query to a SQL query |
US9703890B2 (en) * | 2014-10-17 | 2017-07-11 | Vmware, Inc. | Method and system that determine whether or not two graph-like representations of two systems describe equivalent systems |
US20160147962A1 (en) | 2014-10-30 | 2016-05-26 | AgriSight, Inc. | Automated agricultural activity determination system and method |
US20160125331A1 (en) | 2014-10-30 | 2016-05-05 | AgriSight, Inc. | Automated agricultural activity determination system and method |
US10149335B2 (en) | 2014-11-10 | 2018-12-04 | Qualcomm Incorporated | Connectivity module for internet of things (IOT) devices |
US9893948B2 (en) * | 2015-03-26 | 2018-02-13 | Utopus Insights, Inc. | Network management using hierarchical and multi-scenario graphs |
US9501611B2 (en) | 2015-03-30 | 2016-11-22 | Cae Inc | Method and system for customizing a recorded real time simulation based on simulation metadata |
US10296301B2 (en) | 2015-06-08 | 2019-05-21 | Cisco Technology, Inc. | Thing discovery and configuration for an internet of things integrated developer environment |
US9853827B1 (en) | 2015-06-16 | 2017-12-26 | Amazon Technologies, Inc. | Automated device discovery on a building network |
CN106339947A (en) | 2015-07-07 | 2017-01-18 | 阿里巴巴集团控股有限公司 | Method and device for performing business operation and acquiring group member information based on chat group |
US9955316B2 (en) | 2015-07-20 | 2018-04-24 | Blackberry Limited | Indoor positioning systems and meeting room occupancy |
US10324773B2 (en) | 2015-09-17 | 2019-06-18 | Salesforce.Com, Inc. | Processing events generated by internet of things (IoT) |
JPWO2017056194A1 (en) | 2015-09-29 | 2017-10-05 | 株式会社東芝 | Information device or information communication terminal and information processing method |
US10447784B2 (en) | 2015-12-14 | 2019-10-15 | Afero, Inc. | Apparatus and method for modifying packet interval timing to identify a data transfer condition |
EP3391639B1 (en) | 2015-12-17 | 2022-08-10 | Koninklijke KPN N.V. | Generating output video from video streams |
WO2017111860A1 (en) * | 2015-12-26 | 2017-06-29 | Intel Corporation | Identification of objects for three-dimensional depth imaging |
US10430293B1 (en) | 2015-12-30 | 2019-10-01 | EMC IP Holding Company LLC | Backup client agent |
US9875333B1 (en) | 2016-01-19 | 2018-01-23 | Cadence Design Systems, Inc. | Comprehensive path based analysis process |
US10437791B1 (en) | 2016-02-09 | 2019-10-08 | Code 42 Software, Inc. | Network based file storage system monitor |
US10387392B2 (en) | 2016-05-17 | 2019-08-20 | Rockwell Automation Technologies, Inc. | Method to automate historian configuration using controller based tag meta attribute |
US9921726B1 (en) | 2016-06-03 | 2018-03-20 | Steelcase Inc. | Smart workstation method and system |
US10579678B2 (en) * | 2016-07-12 | 2020-03-03 | Sap Se | Dynamic hierarchy generation based on graph data |
US10445260B2 (en) | 2016-08-31 | 2019-10-15 | Intel Corporation | Direct access to hardware queues of a storage device by software threads |
US10275278B2 (en) | 2016-09-14 | 2019-04-30 | Salesforce.Com, Inc. | Stream processing task deployment using precompiled libraries |
US10397733B2 (en) * | 2016-10-01 | 2019-08-27 | Intel Corporation | Sharing of environmental data for client device usage |
US10365642B2 (en) | 2016-10-03 | 2019-07-30 | Avaya Inc. | Probe of alarm functionality using communication devices |
US10178579B2 (en) | 2016-10-21 | 2019-01-08 | Afero, Inc. | Internet of things (IoT) system and method for selecting a secondary communication channel |
US10126132B2 (en) * | 2017-01-17 | 2018-11-13 | Blind InSites, LLC | Devices, systems, and methods for navigation and usage guidance in a navigable space using wireless communication |
US10087063B2 (en) | 2017-01-20 | 2018-10-02 | Afero, Inc. | Internet of things (IOT) system and method for monitoring and collecting data in a beverage dispensing system |
US10503782B2 (en) | 2017-03-18 | 2019-12-10 | Tracelink, Inc. | Metafutures-based graphed data lookup |
US9818448B1 (en) | 2017-04-10 | 2017-11-14 | Avid Technology, Inc. | Media editing with linked time-based metadata |
US10027551B1 (en) * | 2017-06-29 | 2018-07-17 | Palantir Technologies, Inc. | Access controls through node-based effective policy identifiers |
US10705918B1 (en) | 2017-07-21 | 2020-07-07 | EMC IP Holding Company LLC | Online metadata backup consistency check |
US20190130367A1 (en) | 2017-10-28 | 2019-05-02 | Facebook, Inc. | Intelligently organizing a directory in a room management system |
US10652370B2 (en) | 2017-12-07 | 2020-05-12 | Bank Of America Corporation | System and method for transferring image systems of different types between computers in a single data packet |
US10691354B1 (en) | 2018-01-31 | 2020-06-23 | EMC IP Holding Company LLC | Method and system of disk access pattern selection for content based storage RAID system |
US10484829B1 (en) * | 2018-04-27 | 2019-11-19 | Microsoft Technology Licensing, Llc | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users |
US10705753B2 (en) | 2018-05-04 | 2020-07-07 | EMC IP Holding Company LLC | Fan-out asynchronous replication logical level caching |
US10860239B2 (en) | 2018-05-04 | 2020-12-08 | EMC IP Holding Company LLC | Fan-out asynchronous replication caching |
US11615373B2 (en) | 2018-05-09 | 2023-03-28 | Target Brands, Inc. | Inventory management |
US10951482B2 (en) | 2018-05-16 | 2021-03-16 | Microsoft Technology Licensing, Llc | Device identification on a building automation control network |
US20190354910A1 (en) | 2018-05-21 | 2019-11-21 | Microsoft Technology Licensing, Llc | Methods and systems for dynamically scheduling spaces |
US11456915B2 (en) | 2018-05-21 | 2022-09-27 | Microsoft Technology Licensing, Llc | Device model templates |
US20190354906A1 (en) | 2018-05-21 | 2019-11-21 | Microsoft Technology Licensing, Llc | Methods and systems for executing business logic related to physical spaces and associated devices |
US11226996B2 (en) | 2018-08-03 | 2022-01-18 | Kilpatrick Townsend & Stockton Llp | Identifying and graphically representing multiple parent nodes of a child node |
-
2018
- 2018-04-27 US US15/964,751 patent/US10484829B1/en active Active
-
2019
- 2019-11-15 US US16/685,975 patent/US11019458B2/en active Active
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20200162847A1 (en) * | 2018-04-27 | 2020-05-21 | Microsoft Technology Licensing, Llc | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users |
US11019458B2 (en) * | 2018-04-27 | 2021-05-25 | Microsoft Technology Licensing, Llc | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users |
US10951482B2 (en) | 2018-05-16 | 2021-03-16 | Microsoft Technology Licensing, Llc | Device identification on a building automation control network |
US11456915B2 (en) | 2018-05-21 | 2022-09-27 | Microsoft Technology Licensing, Llc | Device model templates |
US11032154B2 (en) * | 2018-12-21 | 2021-06-08 | Cisco Technology, Inc. | Graphical user interface for displaying a hierarchical network topology in a single site view |
CN111028350A (en) * | 2019-11-21 | 2020-04-17 | 大连理工大学 | Method for constructing grid map by using binocular stereo camera |
WO2021098079A1 (en) * | 2019-11-21 | 2021-05-27 | 大连理工大学 | Method for using binocular stereo camera to construct grid map |
US11315318B2 (en) | 2019-11-21 | 2022-04-26 | Dalian University Of Technology | Method for constructing grid map by using binocular stereo camera |
CN113408997A (en) * | 2020-03-17 | 2021-09-17 | 北京四维图新科技股份有限公司 | Processing method, device and system for high-precision map drawing task |
US20230244440A1 (en) * | 2020-07-05 | 2023-08-03 | Orange | Selection and control of connected objects from a symbolic representation of a topography of a site |
Also Published As
Publication number | Publication date |
---|---|
US10484829B1 (en) | 2019-11-19 |
US20200162847A1 (en) | 2020-05-21 |
US11019458B2 (en) | 2021-05-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11019458B2 (en) | Methods and systems for generating maps corresponding to physical spaces, devices, and/or users | |
US10951482B2 (en) | Device identification on a building automation control network | |
US11210323B2 (en) | Methods and systems for generating property keys corresponding to physical spaces, devices, and/or users | |
US11762356B2 (en) | Building management system with integration of data into smart entities | |
US20190354910A1 (en) | Methods and systems for dynamically scheduling spaces | |
Bajaj et al. | A study of existing Ontologies in the IoT-domain | |
US20190354906A1 (en) | Methods and systems for executing business logic related to physical spaces and associated devices | |
US11456915B2 (en) | Device model templates | |
US20190332789A1 (en) | Hierarchical access rights and role based access | |
US20150026158A1 (en) | Systems, methods, and software for unified analytics environments | |
US10747578B2 (en) | Nested tenants | |
US20210172639A1 (en) | Automated Building Concierge | |
US20200097493A1 (en) | Individualized Telemetry Processing Leveraging Digital Twins Property(ies) and Topological Metadata | |
Hijazi et al. | NIBU: A new approach to representing and analysing interior utility networks within 3D geo-information systems | |
WO2019067645A1 (en) | Building management system with data ingestion into smart entities and interface of smart entities with enterprise applications | |
US20190332713A1 (en) | Methods and systems for managing physical spaces, associated devices, and users | |
US20200193700A1 (en) | Generating space models from map files | |
Boysen et al. | Constructing indoor navigation systems from digital building information | |
US10866831B2 (en) | Distributed execution of data processing pipelines | |
Rahimi et al. | A topology-based graph data model for indoor spatial-social networking | |
US10951431B1 (en) | Device registry service | |
US20160314180A1 (en) | System of dynamic hierarchies based on a searchable entity model | |
US8910183B2 (en) | Access to context information in a heterogeneous application environment | |
US12014119B2 (en) | Enhancing a construction plan with data objects | |
Niu et al. | Considering common data model for indoor location-aware services |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:VITON, FERNANDO NAHUEL;VOGEL, MATTHEW EVAN;VANDENBROUCK, GREGORY CHRISTOPHER JOHN;SIGNING DATES FROM 20180425 TO 20180427;REEL/FRAME:045673/0171 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |