Software Technology for Systems, methods, and apparatus for light-enabled indoor positioning and reporting

Invented by II Thomas Lawrence Zampini, Beco LLC, Beco Inc, Sentry Centers Holdings LLC

The Beco LLC, Beco Inc, Sentry Centers Holdings LLC invention works as follows

Background for Systems, methods, and apparatus for light-enabled indoor positioning and reporting

Humans spend 90% or more of their time indoors.” However, indoor positioning of users (users) can be difficult to determine or unreliable using the existing infrastructure.

The present disclosure addresses the need to contextually engage users based upon their location. It also measures user traffic through a space such as a building. The beacon solution does not require setup, but can be used to provide accurate indoor positioning to any device.

Indoor positioning is a way to facilitate navigation, analytics and context engagement. Indoor positioning information, such as in a retail environment, can be used to help shoppers find items on their shopping list and help store employees and assets track. This information can then be analyzed for valuable insights on user traffic. For example, where shoppers go, how they get there and dwell times. These data can also be used to optimize floor plans and workflows. To deliver new experiences for shoppers, contextual data such as location can be combined with online activity and point of sale data. You can engage them directly from your mobile device, or look to the future by changing the environment around you. For example, shelves that glow to highlight items that are of interest to you. Data on how people use a building’s floor plan can be extremely useful in optimizing building systems such as lighting, HVAC, heating, ventilation, air conditioning, and other elements. This will result in improved user comfort and energy savings. Based on real-world data, and analysis of how users use a space over a given period of time, user position data can be used to optimize floor plans. Building owners, operators, tenants and landlords can save money by having better floor plans and energy savings.

The present solution captures user location with better granularity in their measurements. It is also less costly and easier to deploy and/or less intrusive for users. One example is that occupancy sensors such as PIR and/or Ultrasonic sensors might not be able to distinguish one user from several. Security cameras are intrusive and expensive, especially when they are used in offices. Wi-Fi tracking is a wireless access point that records user smart phone addresses. However, it can be difficult to pinpoint the user’s position accurately in places with many walls and partitions such as offices, hospitals and universities.

The commonality of all these technologies is that they do not bring any value to the user. They are used strictly for user tracking and/or input into a building management software, such as an occupancy sensor to monitor lighting or HVAC. Our daily lives are seamlessly integrated with smart phones, wearable tech devices and apps. These solutions provide indoor location infrastructure by placing sensors and lighting throughout the spaces. This allows users to receive this service immediately while also providing tracking. Wireless beacons are a localized wireless solution that can be used to locate indoors. A wireless beacon is an open, one-way wireless broadcast that uses Bluetooth low energy (BLE). It often includes some data. Multiple nearby mobile devices may detect this broadcast simultaneously. The data can be read without the need to pair or connect to the wireless beacon. The data may be configured as a universally unique ID (UUID) but, in all cases, it is just broadcast information.

To transmit wireless beacons, physical hardware can be deployed. The beacon hardware of third parties may be small, battery-operated modules that are designed to broadcast wireless beacon signals. Wireless beacons are largely inaccuracy and only provide a local solution. Conventional positioning with beacon broadcasts measures power in received radio signals (referred to as received sign strength indication or RSSI) then compares it to original broadcasted power levels, which are the power levels included in the beacon broadcast. This technique can produce inconsistent readings in real-world environments. It is influenced by physical constraints such as room layouts, obstructions (including people) and the orientation of the mobile phone at the time the broadcast was received. It is sometimes difficult to determine which beacon device is closer when there are multiple beacon broadcasts.

Today’s beacon hardware needs to be installed in a planned manner. Beacons are often placed near points of interest. One example of a point of interest is a product display in retail stores. As the user approaches the display their mobile device detects the nearby beacon signal and establishes close proximity to it. For example, a conference room within an office building could be a point of interest. The mobile device would have had to be preprogrammed, or updated remotely by a server to associate specific data, such as beacon UUID, with the location and respond accordingly. Some embodiments may use beacon hardware that is installed at known geo locations. The device can then be calibrated using techniques like triangulation to determine an approximate user’s position. These devices need to be programmed and planned carefully in order to deploy successfully. These devices, which are powered by batteries, require care in their operation (e.g. These devices require careful consideration regarding their operation (e.g., broadcast power and interval) and maintenance. The beacon’s life expectancy is affected by the broadcast time. However, reducing the broadcast duration to conserve battery life can greatly decrease the likelihood that the beacon will be detected reliably by a mobile device. Today’s beacon hardware is vulnerable to theft and tampering, just like any other device that needs maintenance. These limitations are important in commercial environments that require long-term deployments. This is especially true when you consider the millions of batteries that must be replaced each year.

Third-party beacon companies use encryption and other proprietary methods to lock down beacon broadcasts as a way of controlling and monetizing wireless beacons. Apple’s iBeacon is an example of this. An app can only hear beacon UUIDs that it has in advance. If the UUID is not known, iOS will obscure the beacon UUID, rendering it inaccessible to other Apps. Other configurations require beacon companies to pay a subscription and an SDK for third-party apps to install. The SDK is used to decode beacons and, in some cases, provide advertising services. Advertisers may be required to use the beacon company’s proprietary interface or advertising exchange to send coupons and advertising to their mobile devices. Some require their own app for beacon interaction. This approach is shortsighted in all cases as it creates an ecosystem of closed beacons that is based on proprietary hardware and subscribing apps with limited functionality. This creates a physical beacon for each App industry. A single indoor location might require multiple beacon devices to support multiple Apps. Each beacon must be set up and interact with a different App. Beacons in their current state, due to the inaccuracy of using one beacon to establish position based upon RSSI and the short life span of beacon batteries, are very limited.

The present solution provides a maintenance-free beacon system that doesn’t require setup. It can be used to provide accurate indoor positioning for any mobile device by integrating wireless devices directly into light bulbs and fixtures, either natively or via an add-on. Combining beacons with lighting allows you to take advantage of existing lighting infrastructure. This provides an unlimited power source for your beacon, which is located in a secure location. The availability of lighting is ubiquitous and evenly distributed throughout the space, making it possible to deploy beacons without the need for additional beacon hardware. This allows for wireless sniffing to be implemented within the same device that detects mobile devices, such as smart phones, and other wearable technology via Wi-Fi, Bluetooth, and/or cellular detection.

Beacons can be attached to light fixture housings or installed inside of a bulb or lighting fixture. An integrated circuit that includes a processor and a wireless radio on one chip is called the ACB (advanced Control Beacon). The ACB can also include one or several processors, wireless radios and memory. An antenna and/or one sensor may be included. This will provide feedback to the ACB processor. It will enable the ACB processor to control the Light Source’s on/off status and lighting intensity. One embodiment of the ACB has a solar cell that draws energy directly from the ACB’s light source.

Each ACB beacon transmits wireless broadcasts that contain a method for unique identification. This can be used to identify the ACB beacon and allow it to be used for mobile positioning. Lighting Data may be included in the ACB broadcast, which can include data about energy metering, lifetime monitoring data and Ambient Data. This includes mobile devices that are detected using sniffing for wireless signals and MAC addresses. Data regarding the power and calibration of the wireless broadcast can also be included in the wireless broadcast. The BecoID is the broadcast, regardless of format or protocol. Some or all of the BecoIDs can change at a defined or random interval to protect against beacon hijacking or spoofing. In some cases, this interval may be defined by variables like lighting run time or time of day. The ACB processor may calculate the BecoIDs using an algorithm or polynomial formula seeded with a unique amount, such as the ACB processor’s media access control address (MAC), Device ID, or similar. A URL (uniform Resource Locator) is one format that can broadcast a BecoID. This URL may be used interchangeably with URI (uniform resources locator) or URN (uniform URL name), which has the same functionality as URL, URI and URN. The URL contains a unique identifier, which may be combined with Ambient Data and/or Lighting Data, as described. An iBeacon is another format to broadcast the BecoID. It contains a UUID (uniform resource locator), Major, and Minor values. The UUIDs, Major and/or minor bits may change over time to protect security. URL (also known as a URI Beacon) and iBeacon protocols are examples of Beco ID formats. However, the format and delivery methods of BecoIDs can vary as described in this document. It may be expressed as a BecoID, or just a UUID. Both terms may be interchangeably.

Each ACB can also be equipped with the ability to scan for nearby wireless devices. You can do this by changing the radio’s operation mode from broadcast to receiver. The wireless radio then becomes available for connecting to nearby devices. Multiple radios can be used to detect different wireless signals. Each radio may have its own antenna or share the same antenna. The ACB can record any nearby wireless devices it detects to its memory. The ACB may adjust lighting operation by changing the on/off status and/or brightness of one/more light fixtures. These data, collectively known as Ambient Data, are collected by the ACB and stored in the ACB Database for future retrieval. They may also be broadcast via the ACB wireless beacon.

Upon detecting one of the BecoIDs, nearby devices may trigger an event or record this detection as an incident. One case is that the mobile device might simply compare the detected BecoID to a database stored in its mobile device memory to determine its location, e.g. BecoID 123 sounds near a kitchen, so I’m near it. The mobile device may issue what’s called a Location Request in more advanced cases. This could be a URL hit or API call or something similar to the location engine. The Location Engine is a collection or remote servers that are connected via the internet. It manages BecoIDs and metadata such as ACB physical locations and, in some cases, content that might be associated with one or several BecoIDs. The location request is made through an Application Programming Interface, hitting a URL or other means to connect one or more remote devices with one or more servers. A Location Request can include all BecoIDs found or a selected number of BecoIDs. For instance, it may submit only BecoIDs above a certain RSSI threshold, or the BecoID with the highest RSSI over a specified time period. The Location Engine can simply decode the BecoID, return information about the mobile device, including metadata, and the decoded value. A different configuration is that the Location Engine may decode each BecoID and return it to a known ACB. This serial number can be either its MAC address or Device ID or any other unique identifier. BecoID is used throughout the document to describe an unique identifier broadcasted by the ACB. However, BecoIDs can change over time and point back to a static serial number. The Location Engine can determine that the combination or BecoIDs corresponds to a known Location Identifier. This is a unique number that is assigned to a physical place and made up of multiple BecoIDs. The Location Identifier can be expressed as a unique identifier (such a number), or as a Virtual Beacon ID. The Virtual Beacon ID is a way to present the Location Identifier in a format that the mobile device can understand. One example is that the Virtual Beacon can be delivered in an iBeacon format. The Location Identifier will be presented as a UUID along with supporting Major/Minor information (per the iBeacon standard, iBeacon). If the Location Engine detects more than one BecoID, it may create a new Location Identifier. BecoIDs, and/or Location Identifiers can be manually entered into the Location Engine database.

The Location Engine will respond to the mobile device if it receives a Location Request. The response could include the decoded values of one or more BecoIDs as well as a UUID and a Major/Minor, along with metadata, a Virtual Beacon ID, and other pertinent information. The Location Engine response allows the mobile device to provide contextual information such as coupons and advertisements. The mobile device can also interact with the surrounding physical space by communicating directly with other devices via the Location Engine or through a third party system. Third-party Ad Servers may be used to deliver the ads. For example, programmatic Ad Exchanges use a unique identifier that the mobile device requests from an Ad-Server. This allows the Ad-Server to access location data. Additional information, such as an advertisement ID or a unique identifier from the mobile device may also be used. The mobile device can also determine the user’s location based on proximity to other users, absolute position and/or physical space. Apps can now automate tasks specific to their location or improve the user experience based on it. Third parties can also use this information to access user schedules in order to improve their services and/or deliver targeted advertising.

In almost all cases, the Location Engine can use all data available, regardless of whether it is known at the time of creating a BecoID or Location Identifier. It may also collect and store data over time through maintaining a database Location Requests. This data will be used to optimize the functionality and accuracy of the Location Engine. These data can be provided directly by the mobile device via the Location Request, from third-party data sources, or by a Gateway Device located at the same physical location with one or more ACBs. The Gateway Device is configured to collect data from ACBs, which is then connected into Location Engine. The data may include the measured RSSI, mobile device Bluetooth LE or WI-FI addresses, as well as nearby Wi-Fi access point MAC addresses. These data may be used over time to improve the location accuracy of any given BecoID or Location Identifier. In part, this data can also include measured RSSI, mobile device MAC addresses, whether Bluetooth, Bluetooth LE, or Wi-Fi, nearby Wi-Fi access points, mobile device ID, user IDs, and other information about the mobile device, its user, and its environment. To optimize the accuracy of Location Identifier position over time, BecoIDs can be dynamically reassigned or shared among multiple Location Identifiers.

In addition to providing location services the Location Engine may also track all Location Request activity. This data is then available for Location Analytics that can provide feedback to building management systems such as security, lighting, HVAC, demand response and other systems. It can also generate visualizations and reports on the space’s usage. Location Analytics can also be used to display key performance indicators such as the number of visits, the duration of visits and repeat visits, and other information that can be compiled based on the connectivity between the mobile device (and the Location Engine). The Location Engine can also use this data to provide real time, scheduled, and predictive feedback to third-party systems. This can be done via an API, or directly connected to a Building Management System. Data such as occupancy data of a room may be sent back to the building. The Location Engine can also use data available to predict user occupancy. This may include the arrival or departures of one or more users. This allows the BMS to adjust building systems in advance of the predicted event, such as cooling in a particular room several minutes prior to the user arrives.

Also, upon receipt of a Location Request the Location Engine may decode data embedded by the ACT into a BecoID. Ambient Data and Lighting Data may be included. Lighting Data can include any operational data for the ACB or host Light Source. This includes but is not limited to operating hours, temperature and light intensity, intensity histograms, CO2 and other measurable data points. Ambient Data can include all data about nearby devices, wireless or otherwise, including mobile devices, computers and displays. These data could include one or more MAC addresses. The MAC may be complete, abbreviated or hashed. It could also contain a count of devices detected over time, devices being filtered using transient devices verses static, and the stat devices that the ACB has determined to be constants but not reported. An ACB could also contain a database that contains some or all of a hashed time stamp, MAC address, and RSSI level. Each Location Request includes Ambient Data and Lighting Data. Lighting Analytics can be performed using the Lighting Data. This includes analyzing the energy consumption of a particular bulb or fixture over time, operating temperatures, error codes, operating hours, temperature, and any other information that could be used to improve the quality of the billions of worldwide LED fixtures and bulbs. Location Analytics can be improved with Ambient Data. This includes devices making Location Requests (for example, those that have the appropriate App or operating system), as well as devices nearby that include a radio but are not connected to the Location Engine.

Although generally described as providing location information or information in response a request for location, any type information associated with ACB devices may be retrieved and processed by a server or location engine. Additional information may include information such as profile information, environmental information and sensor information.

Unlike building networks such as BACnet or lighting control systems, the current embodiment does not require integration with building networks. The Lighting Data and Ambient Data are forwarded to Location Engine with every Location Request. This is done using any nearby mobile device. The nearby mobile device provides the Lighting Data, Ambient Data, and Location Engine. This is sometimes done to provide the server with data. For instance, an App or mobile OS hitting a URL that contains this data. It can also be done in exchange of positioning data. This includes a Beco ID or Location Identifier, Virtual Beacon ID and/or metadata about where an App or mobile OS hits the server, such as a URL, API call, and receives a reply.

Where a dedicated connection is available to the Location Engine, the ACB can also communicate with it using existing building infrastructure such as a Wi-Fi network, location area network (LAN) or similar. One example is that the ACB could include a WIFI radio to communicate with the LAN. A Gateway Device can be used to allow one or more ACBs to communicate with a nearby Gateway Device. This could include a wireless gateway or LAN connection that has an Internet connection. It may be as easy as the Gateway Device receiving the ACB beacon broadcast from the Location Engine and forwarding it to them. One example is that the Gateway Device would keep a continuous scan mode and detect nearby ACB beacon broadcasts. Another example is that the Gateway Device would directly connect to each ACB. This could be used for polling ACBs or requesting data. Another example is two or more ACB beacons that form a mesh network, which relays messages between each ACB and finally to the Gateway Device. Another scenario is that the Gateway Device could also be a mobile device. The Gateway Device must be in contact with the Location Engine in all cases. The communication can be continuous or at a set interval.

In some aspects, this solution is directed at innovative systems and methods for attaching a beacon on a lightbulb including functionality such as rotating UUIDs collecting lighting data and/or via request, the ACB solar panel, using a light sensor and energy metering, using multiple beacon broadcasts refine position, adjusting beacon operation according to environmental inputs and stored energy, coordination and power conversion with other ACBs, etc.