Patent Application
20170300970
This disclosure relates to systems and methods for determining and reporting locations. More particularly, it relates to systems and methods for determining and reporting locations of mobile points of interest.
For entertainment, recreation, and fitness, people often attend many types of events, such as professional and/or recreational sporting events, festivals, fairs, and the like. For certain events, it is often difficult to know where certain people, vendors, or other points of interest are located, especially when the points of interest, such as participants in races, are mobile. Some events provide spectators with static maps, but the mobility of people and other points of interest limit the usefulness of such maps. Some race events provide websites that provide limited information about the whereabouts of participants, but generally these update only after an athlete has crossed a particular location. This means spectators are only informed of an athlete's location after the fact, which can lead to spectator frustration, spectators getting lost at the event, and a decrease in event satisfaction. In the case of race events, spectators may miss their favorite racer on the course. In a professional sporting event, the inability for spectators to find a particular concession vendor may lead to lost revenue. Therefore, it would be desirable to provide systems and methods that can track mobile points of interest during events and alert interested parties in near real-time where the mobile point of interest, such as race participants and/or concession vendors, are located.
The disclosed system can be used to track mobile points of interest during events and to alert attendees in near real time where mobile points of interest are located. The system can include one or more beacons, such as Bluetooth Low Energy beacons, that can be affixed to or worn by mobile points of interest; one or more spectators with one or more compatible mobile devices (e.g., smartphones or tablets); and one or more network connected servers, which can be cloud-hosted.
The disclosed system can collect data via mobile devices from wireless beacons located on a plurality of mobile points of interest and transmit collected data to a server database. The system can use this data to generate a dynamic map of the geographic region that includes mobile points of interests. It can present the dynamic map to individuals, such as spectators, with a compatible mobile device or any suitable Internet connected system who are connected to the server. The dynamic map can allow event spectators to know the location of mobile points of interest in near real time. Near real time mapping can help spectators to easily find things that they are interested in or are looking for, which can reduce frustration and potentially increase revenue for event vendors (who can be mobile points of interest).
The disclosed system can use algorithms to filter reported data so that the higher quality and more reliable data is stored by the system and reported to users. This filtering can be desirable because the beacons transmit data at a high rate that can result in potentially redundant data. Filtering data at the mobile device can prevent uploading redundant data to the server and thus can prevent server overload and unnecessary cellular data use. Filtering data at the server can prevent storing and reporting redundant data to the users. In a non-limiting example the mobile device that collects the data can filter the data on one or more criteria that can include accuracy of the geolocation information and accuracy of the beacon radio frequency signal. Likewise, the server can filter on the same or similar criteria before storing and reporting the data.
In one non-limiting example, distance running event athletes can wear a wireless beacon, and spectators can be presented with a map that updates to show the real-time location of athletes they follow. This can allow spectators to locate the athlete they are following on the course so that they can plan where to view the race.
In another non-limiting example, a temporary event, such as a state fair, can have wireless beacons placed at vending locations or at amusement rides to allow visitors to know where vendors are located.
In yet another non-limiting example the present disclosure provides a system for tracking mobile points of interest within a geographical region. The system can include one or more beacons affixed to one or more corresponding mobile points of interest, one or more mobile computing devices, and an Internet-connected server. Each of the one or more beacons can be structured and configured to broadcast advertisements with unique identifying information via a short-range communication protocol. Each mobile computing device can include beacon communication hardware configured to receive advertisements broadcast by the one or more beacons, Internet communication hardware, and geolocation capability. Each mobile computing device can be programmed and configured to record received advertisements from the one or more beacons along with corresponding geolocation information from the geolocation capability. For each of the one or more beacons from which the mobile computing device has recorded received advertisements, it can be programmed and configured to filter the recorded received advertisements along with corresponding geolocation information, to result in device-filtered beacon location data. The mobile computing device can be programmed and configured to transmit the device-filtered beacon location data via the Internet communication hardware. The Internet-connected server can be programmed and configured to receive and record the device-filtered beacon location data from each of the one or more mobile computing devices for each of the one or more beacons from which the one or more mobile computing devices have recorded received advertisements. For each of the one or more beacons from which the one or more mobile computing devices have recorded received advertisements, the server can be programmed and configured to filter the device-filtered beacon location data, to result in server-filtered beacon location data. The server can be programmed and configured to transmit the server-filtered beacon location data to at least one other entity.
The above summary is not intended to describe each and every example or every implementation of the disclosure. The Description that follows more particularly exemplifies various illustrative embodiments.
The following description should be read with reference to the drawings. The drawings, which are not necessarily to scale, depict examples and are not intended to limit the scope of the disclosure. The disclosure may be more completely understood in consideration of the following description with respect to various examples in connection with the accompanying drawings, in which:
The present disclosure relates to systems and methods for determining and reporting locations of mobile points of interest. Various embodiments of the systems and methods are described in detail with reference to the drawings, in which like reference numerals may be used to represent like parts and assemblies throughout the several views. Reference to various embodiments does not limit the scope of the systems and methods disclosed herein. Examples of construction, dimensions, and materials may be illustrated for the various elements, those skilled in the art will recognize that many of the examples provided have suitable alternatives that may be utilized. Any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the systems and methods. It is understood that various omissions and substitutions of equivalents are contemplated as circumstances may suggest or render expedient, but these are intended to cover applications or embodiments without departing from the spirit or scope of the disclosure. Also, it is to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting.
In some embodiments, the disclosed systems and methods can include, without limitation, beacons configured to attach to, and be associated with, one or more mobile points of interest, such as event participants and/or concession vendors; computing devices (some or all of which can also be mobile) that can detect the beacons and host an application to process beacon data; and a server-based system that can receive information about detections of beacons from the computing devices and provide information about beacon whereabouts to interested parties in near real-time. It is to be understood that the term “mobile points of interest” can be, but is not limited to, a person or thing that is currently moving (e.g. a person in a race, etc.), a person or thing that is intermittently moving (e.g. a food vendor, emergency medical personal, etc.) or a person or thing whose current position is fixed for a temporary period of time (e.g. a race start or finish line, medical tent, etc.).
Each runner 12a-12d in the example of
Computing devices 14a, 14b, 14c, 14d, and 14e (as well as possibly other computing devices not illustrated) can be located at various places in the vicinity (or not necessarily in the vicinity) of the course 16. As discussed further herein, computing devices 14a-14e can include hardware capable of detecting beacons 12a-12d (as well as possibly other beacons), subject to proximity of the beacons to the computing devices. Communication protocols by which computing devices 14a-14e detect beacons 12a-12d can be relatively short range protocols, such as Bluetooth. Computing devices 14a-14e can communicate information pertaining to beacon detections to a server system 20 via an information network such as (but not limited to) the Internet. Prior to communicating beacon detection information to server system 20, computing devices 14a-14e can be programmed and configured to filter the information, which can improve the quality of data transmitted to the server system and reduce bandwidth requirements.
In some embodiments, beacons generally do not have built-in geolocation capability, but computing devices generally do have geolocation (such as via GPS and/or GLONASS, etc.) built-in, or if stationary, are at known geographic coordinates. When communication modes by which computing devices 14a-14e detect beacons 12a-12d are relatively short range, the location of a computing device when it detects a beacon can be a good proxy or surrogate for the location of the beacon.
Server system 20 can receive beacon detection information from computing devices 14a-14e (as well as possibly other computing devices) and can perform filtering on such data, which can result in improved beacon location data. Server system 20 can share beacon location data with interested parties via entities such as computing devices 14a-14e, as well as via other information platforms 22, 24, 26 and 28, where communication between the server system and computing devices and information platforms can be facilitated by an information network such as (but not limited to) the Internet. The interested parties could be, for example and without limitation, spectators or support personnel at the event, friends or fans of runners 12a-12d following their progress at a distance, event administrators, or any other suitable parties. Information systems 22, 24, 26 and 28 can include, but are not limited to, personal computing systems, network connected televisions, computing systems that connect a television to a network, tablet devices and other systems capable of communicating with the server system.
In embodiments of present disclosure, a beacon such as beacons 12a-12d can be a Bluetooth device, and more specifically can be a Bluetooth 4 (or higher version, e.g. Bluetooth 4.1, 4.2, 5, etc.), Bluetooth Smart, and/or Bluetooth Low Energy (BLE) device (and/or another or future Bluetooth protocol device) that can be configured to periodically emit a Bluetooth format radio frequency signal. However, this is not limiting, and in other embodiments, a beacon, can be any suitable device that can transmit uniquely identifying information that can be detected by computing devices (described further elsewhere herein) configured to detect beacons. In some embodiments, the communication protocol (such as Bluetooth Low Energy) by which beacons communicate with computing devices are effective only over relatively short ranges such as less than about 100, 80, 60, or 40 meters. Using a short-range communication protocol can help ensure that the position of a beacon detected by a computing device is similar to the position of the computing device, within the maximum range of the communication protocol.
Many Bluetooth devices can have characteristics that can make them particularly suitable for use as beacons, including low weight, low volume, low cost, low power consumption, and widely adopted use of the Bluetooth radio frequency protocol. (Other non-Bluetooth beacon devices may also exhibit some or all of these characteristics.) In non-limiting examples a beacon can be configured to be worn or otherwise attached to a user (mobile point-of-interest), such as with a clip, loop, or lanyard, etc., or a beacon could be placed in a pocket, etc. A beacon can be affixed to event equipment, such as a race bib, or a clothing item or accessory, such as a wrist worn band, toe tag, shoelace, or other accessory. A Bluetooth beacon can weigh on the order of 10-20 grams, and can displace a volume on the order of single digits of cubic centimeters. Such a small, light device may be essentially unnoticed by users/wearers/mobile points-of-interest, which may be important for acceptance by users. Low power consumption can enable a beacon to operate for the entire duration of an event, or for enough time for multiple events, on a single battery, such as a type 2032 lithium battery, or any other suitable battery or energy storage device. In some embodiments, a beacon could include an energy-harvesting mechanism and not require an energy storage device to provide operational power.
In another embodiment, the beacon could be capable of transmitting information via other radio frequency protocols (e.g. Zigbee, Wi-Fi, NFC, etc.) and methods (e.g amplitude modulation, frequency modulation, etc.), light signals, acoustic signals or mechanical signals (e.g. vibration).
In embodiments of present disclosure, beacons can be configured to broadcast unique identifying information, for example in Bluetooth format data packets. In some embodiments, a beacon can be programmed to transmit one or more unique identifiers. In some embodiments, beacons can be coded at manufacture with a unique identity. In some other embodiments, beacons can be programmed after manufacture with an identity, which can be a unique identity, by any appropriate organization, authority, or entity. In some examples, such programming can be done via Bluetooth, via direct electrical connection or via another method. In some implementations, unique identifying information broadcast by beacons can be arbitrary, without intrinsic meaning. In such cases where the unique identifying information is arbitrary, any association or correlation with a particular mobile point-of-interest (such as the identity of a race participant) can be done externally, for example, at the server level. In some other implementations, unique identifying information could include non-arbitrary information, such as personally-identifiable information. In some embodiments, non-arbitrary information such as person's name, name of an organization, website address, and so on, can be broadcast.
In the present disclosure, “beacon ID” can describe unique identifying information associated with a beacon that the beacon broadcasts.
In some embodiments, beacons can broadcast only unique identifying information (whether arbitrary or not) that does not change from broadcast to broadcast. In other embodiments, beacons could broadcast any suitable dynamic information, such as (but not limited to) temperature, altitude, activity level (e.g., through accelerometers), and biometrics (such as heart rate). In some examples, a beacon could have geolocation capability built-in, such as a GPS and/or GLONASS receiver/processor, and the beacon could broadcast location information. However, it is envisioned that in many or most embodiments and implementations of systems of the present disclosure, most or all beacons do not have built-in geolocation capability, and that beacon location determination is performed elsewhere in the systems and methods, such as in computing devices that detect beacons, and in server-level systems that process beacon location data, as discussed further herein. Beacons not including geolocation capabilities can be less expensive, lighter, smaller, and less power-consuming than self-geolocating beacons.
In the present disclosure, “beacon data” can describe data transmitted by the beacon other than a beacon ID or data associated with a beacon ID (such as “beacon location data”) which can describe geolocation data associated with the beacon. The beacon location data can be directly transmitted by the beacon to the recipient application or can be measured by the application and associated with the beacon data. In turn, the beacon data can be associated with the beacon ID to associate the data with a unique beacon.
In some embodiments both a beacon ID and beacon data can be transmitted at the same time by the beacon so that other agents of the system can associated the beacon ID, transmitted data and location of the beacon together.
In some embodiments, beacons can broadcast information with essentially a fixed frequency (for example, once every 100 milliseconds). In some other embodiments, beacons could be configured to transmit at varying frequencies, for example, tied to activity level in a beacon incorporating an activity-level sensing mechanism. In some embodiments, a beacon could be configured to transmit information after detecting a specific signal, such as a triggering signal from a computing device configured to detect beacons or a signal from another beacon. It is envisioned that in many embodiments and implementations of systems of the present disclosure, beacons can transmit information autonomously, without any external trigger, input, or stimulus. Transmissions from beacons can be referred to as “advertisements.”
Systems and methods of the present disclosure can be practiced with beacons operating in accordance with any suitable beacon operating and/or communication protocols, including Apple's iBeacon profile, Google's Eddystone format, or other proprietary or non-proprietary beacon protocols.
A “discovery” or “discovery event” of a beacon can refer to the act or actions of a computing device with an associated application that is programmed to detect the signal from the beacon detecting the desired signal.
Beacons can be distributed to and associated with mobile points-of-interest (such as event participants like runners) by any suitable methods. For example, in the case of a running race, beacons can be distributed to race participants as part of race registration and can attach to apparel or other equipment that the race participants will wear during the race. A beacon can associate a race identity (i.e., a bib number, beacon number, etc.) with a race participant. This association could be programmed by the race organization, or the race participant could be issued an unassociated beacon and the participant could make the association themselves, for example, via a website or application running on a computing device such as a smartphone or tablet. In another example, race participants can use a specific beacon at a plurality of events and, instead of associating the race participants with a race identity for a specific race, a beacon can associate the race participant with a persistent identification.
In some embodiments, the beacons can be programmed to communicate with one another as well as transmitting data to a system programmed to detect the beacons. In this type of network the beacons can both send and receive data. In this type of embodiment, the beacons would be able to receive data from other systems that are around them giving the beacons information about their local environment. A non-limiting example of this would be a beacon affixed to a race participant that was programmed to receive data from waypoints along the course or from other racers (e.g. the participant was running with others that they were friends with).
Beacon Detection Via Computing Devices with Mobile Application
In embodiments of present disclosure, computing devices such as computing devices 14a-14e of
However, it is envisioned that systems and methods of the present disclosure will often include computing systems that provide both sets of functionality (“beacon detection functions” as well as “beacon location reporting”), and indeed, there can be significant advantages to having computing systems providing both kinds of functionality. Consider the example of a running race, as illustrated in
While it is envisioned that mobile devices may commonly be used for “beacon detection functions”, systems and methods of the present disclosure are not limited to using only mobile devices, and any suitable computing devices may be used. In some cases, computers such as desktop or laptop computers could be used for “beacon detection functions” at generally fixed locations. In some examples, mobile devices could be used at essentially fixed locations; while such devices could be moved from place-to-place during an event, in these examples they could be kept stationary. Computing device at fixed locations could be deployed by event organizers to provide “beacon detection functions” at locations where spectator densities are anticipated to be low. In the present disclosure, “mobile” should not be considered to be limiting, and any particular device or entity should only be considered to be strictly mobile or strictly stationary if explicitly described as such.
Additionally, it is envisioned in the present disclosure that not all users of devices 14a-14e need to be within the geographic area or region 18 (
The middle lane of the flow diagram of
In the present discussion of operation of the App of
At 206, the App can determine which events (i.e., races) are associated with the spectator, and can determine which beacons to detect, which can be beacons associated with events associated with the spectator. These determinations can involve information received at 204. At 206, the App can compile, collect, receive, or otherwise define a list of beacons to (potentially) perform “beacon detection functions” for. In some examples, such a list of beacons can be provided to the App from the server system. The list of beacons can include, for example, the unique identifying beacon ID for each beacon of interest.
At 206, the App and server system can determine whether to scan for beacons, based upon criteria that can include (but are not necessarily limited to): whether the user agrees to permit their device to detect beacons (in general, and/or for specific events), whether the mobile device is within the vicinity of an event of interest, both geographically and with regard to the time of the event's occurrence, and whether the mobile device has sufficient resources such as energy and communicative connectivity. With regard to vicinity, “geofencing” can be used to define a region, such as region 18 around course 16, schematically indicated by a dashed border in
If the App determines at 206 to scan for beacons, beacon detection can initiate. At 208, 208′, etc., the mobile device running the App can receive and record information contained in advertisements transmitted by the beacon at 202, 202′, etc. In addition to recording the information of the beacon advertisement, the mobile device App can also record any other suitable information, including (without limitation) the time of the beacon discovery, the distance of the beacon from the mobile device making the beacon discovery, and the geolocation of the mobile device at the time of the beacon discovery. Any or all of these pieces of information can be included in “beacon data” associated with a beacon discovery. As discussed further elsewhere herein, the geolocation of the mobile device can be a proxy or surrogate for the location of the beacon.
After recording advertisement information at 208, 208′, etc., the App can perform information processing or “filtering” on said data at 210, 210′, etc. Information processing/filtering is discussed in further detail elsewhere herein, including in relation to
At 212, beacon data, which can be data pertaining to one or more received beacon advertisements, can be transmitted by the mobile device App to the server system by any suitable communication protocol, such as a cellular data protocol, Wi-Fi, etc. In some embodiments, beacon data can be transmitted essentially as soon as possible after each beacon discovery 208, 208′. In some embodiments, beacon data can be stored by the App and transmitted to the server in batches. Beacon data transmitted at 212 can be filtered, as discussed elsewhere herein. In some embodiments, unfiltered beacon data (meaning information from essentially all received beacon advertisements) can be transmitted to the server, but this can be substantially more information than filtered data, and hence, transmitting filtered beacon data can conserve resources such as bandwidth and mobile device energy needed to transmit data. Beacon data transmitted at 212 can be filtered beacon data from multiple beacons. After received beacon data is transmitted to the server at 212, the server can communicate confirmation to the App that it has received the data at 216, after which the App can delete, erase, or otherwise clear the transmitted beacon data from its memory at 218.
The right lane of the flow diagram of
Returning to the operation of the App executing on the mobile device, as mentioned herein, beacon data recorded at beacon discovery 208, 208′, etc. can be processed or filtered at 210, 210′, etc. Generally, filtering of the beacon data and/or beacon location data by the computing device can reduce the amount of beacon data stored by the computing device and improve the quality of beacon data after filtering, in terms of the accuracy of location information or quality of the data transmitted by the beacon.
At 302, a new or next set of beacon data (where each “set of beacon data” corresponds to a single beacon discovery 208, 208′, etc.) can be entered, loaded, or otherwise considered. If beacon data is being filtered directly after each individual beacon discovery 208, 208′, etc., method 300 can commence with operation 302 essentially immediately after each beacon discovery. In cases in which beacon data from multiple beacon sightings 208, 208′, etc. are batched processed, operation 302 can occur for each set of beacon data in turn as the batch is being processed.
At 304, a determination can be made whether the set of beacon data is of interest. This determination can be made according to any suitable criteria, including whether the beacon ID is included on a list of beacon IDs of interest, which can be a list loaded or otherwise compiled at operation 206 of
At 306, the method can include assessing whether the set of beacon data includes a beacon distance between the mobile device and the beacon. The beacon distance can be determined by any suitable means. In some examples, the beacon distance can be calculated based upon received signal strength indicator (RSSI). Such a calculation can be included as a standard function or algorithm in a beacon library or protocol. In some examples, beacon distance calculations can consider other factors such as information from multiple beacon advertisement receiving/recording events, and/or the elapsed time since a beacon discovery has occurred. If the beacon distance is not known, the beacon data can be ignored and the method can return to 302.
At 308, the processing can include assessing whether the beacon discovery represents a duplicate beacon discovery, meaning a discovery of a beacon that has been discovered by the mobile device previously, or whether it is for a new beacon discovery. Beacon discoveries can be considered new or old based on a number of factors, including but not limited to, whether or not the beacon has been discovered previously within a certain time period or whether or not the beacon has ever been discovered by the user at a particular geographic location. If it is a new beacon discovery, method 300 can include at 310 assessing the quality of geolocation information (colloquially described as “GPS data,” but this is not limiting) associated with the beacon discovery, according to any suitable criteria. If the geolocation information quality is deemed to be inadequate (for example, if an uncertainty in location exceeds a predetermined distance), then the beacon data can be ignored and the method can return to 302. If, alternatively, the geolocation information is deemed to be of sufficient quality, then the method can proceed to 312.
If the beacon discovery represents a duplicate beacon discovery, then at 310 the method 300 can assess whether the geolocation information associated with the currently-considered beacon discovery is inferior to other available geolocation information, which can be geolocation information for another discovery of the same beacon, or in some cases could be geolocation information acquired by the mobile device relatively recently (according to any suitable criteria). If the other geolocation information is superior, then it can be associated with the present beacon discovery at 310 in lieu of the originally-associated geolocation information. Geolocation information quality can be assessed with any suitable criteria. One criterion can be uncertainty of the geolocation, with lower uncertainty meaning higher quality. Geolocation uncertainty can be calculated by a standard function or algorithm associated with geolocation capabilities of the mobile computing device. In the case of a computing device used at a fixed location (at least for the duration of an event) for performing “beacon detection functions”, the geolocation can be a fixed value (determined by any suitable means) for all beacon location data produced by the device.
At 306, the method 300 can include assessing whether the beacon distance between the mobile device and the beacon is sufficiently small, close, or short, according to any suitable criteria. The closer the beacon is to the mobile device, according to the beacon distance, the better a proxy or surrogate the geolocation of the mobile device can be for the geolocation of the beacon. If the beacon distance between the mobile device and the beacon is sufficiently small, then the beacon data can be designated or marked at 314 for upload to the server. In some cases, the upload to the server can be performed essentially immediately after a positive determination at that the beacon data is acceptable at 306, 308, 310, and/or 312. In other cases, the beacon data marked at 314 can be stored for later upload to the server, in some cases along with other marked information pertaining to other beacons. If the beacon distance is too great, the method can return to 302 to consider the next set of beacon data. In some cases, a set of beacon data earlier deemed at 306 not to have a sufficiently small beacon distance for upload could later be marked for upload to the server after it is determined to be the best available data—for example, after a predetermined period has elapsed without further beacon discoveries of the same beacon, after a predetermined time while the beacon is still being detected, or if the mobile computing device has moved a sufficiently far distance from the original beacon discovery location. In some cases, if beacon distance and geolocation information for a beacon discovery are of sufficiently high quality, the beacon data could be uploaded to the server even if not all beacon data of the same beacon have been considered by the filtering method 300. In some cases, beacon data can be uploaded to the server essentially immediately as soon as method 300 determines that the beacon data is of higher quality than previous beacon data for the same beacon. In all cases, uploaded beacon data can include, without limitation: beacon ID, beacon distance, and geolocation.
Filtering beacon data at a beacon-detecting computing device, by the repeated application of method 300 of
In some embodiments, processing or filtering of beacon data for a plurality of beacon discoveries of the same beacon can essentially include selecting the shortest beacon distance of the plurality of discoveries, and selecting the highest quality geolocation information of the plurality of discoveries.
In some embodiments, processing or filtering of beacon data for a plurality of beacon discoveries of the same beacon can essentially include combining the beacon distance and the computing device's geolocation information for each individual beacon discovery to arrive at an overall beacon position uncertainty for each individual beacon discovery, then selecting the individual beacon data record with the lowest beacon position uncertainty.
Server system 20 can include any suitable computing system(s) and/or resources(s) capable of performing the processing, storage, and communication operations described herein. Server system 20 can include one or more tangible and/or virtual processors, executing one or more operating system environments. Server system 20 can be cloud-based. Server system 20 can be communicatively coupled via any suitable data network(s) with computing devices 14a-14e, and/or information platforms 22, 24, 26, 28, and/or any other suitable device(s).
The server system generally can receive beacon data relating to one or more beacons (each with one or more unique beacon IDs), from one or more computing devices 14a-14e, etc.
At 402, method 400 can include entering, loading, or otherwise considering beacon data for a beacon ID. At 404, the method can include assessing whether the beacon data is valid, according to any suitable criteria. Such criteria can include, beacon ID validity, geofencing and/or time-fencing. If the data is invalid, method 400 can terminate (for the particular beacon ID for which it is executing). If the data is valid, method 400 can proceed to 406 where the server can determine whether the beacon ID corresponds to an active beacon, and if not, method 400 can terminate. If the beacon (beacon ID) is active, the beacon data can be added to a beacon data database at 408.
At 410, the server can determine whether there are any subscribers to the beacon, such as user accounts of the beacon tracking system that are indicated for being updated on the beacon's location, or any other valid party or entity indicated to receive beacon data. If not, method 400 can terminate, with beacon data having been added to the database. If there are subscribers, the server can collect, retrieve, or compile a list of subscriber(s) to the beacon at 412. At 414, the server can determine whether the subscriber(s) need or desire an update on the beacon data. For example, if none of the subscribers to the beacon are active (e.g,. no mobile App, web session, etc., is active), then no updates on the beacon data are needed and the method can terminate. If any subscribers do need an update, then method 400 can include performing server filtering of beacon data at 416 (as further discussed elsewhere herein, including in relation to
Server 20 can receive beacon data for a particular beacon from multiple computing devices 14a-14e. Filtering such beacon data at 416 by server 20 can be a method for arriving at improved or “best” beacon data for a particular beacon, in terms of the accuracy of location data for the beacon.
If there are multiple samples within a predetermined time interval, method 500 can proceed to further filtering at 508, where beacon samples can be grouped by location, according to any suitable predetermined criteria for geographic proximity. At 510, for each geographic grouping, beacon data that fall outside a predetermined temporal range can be discarded.
At 512, method 500 can include filtering beacon data by beacon distance, with smaller distances being favored. At 514, method 500 can include filtering beacon data by geolocation quality/accuracy. At 514, based in part upon filter at 512, beacon data can be combined into a single point representing the best aggregate information about the position of the particular beacon. While operations 508, 510, 512, and 514 are graphically represented as distinct operations in
At 508, 510, 512, 514, filtering and combining can be performed according to any suitable criteria. In some embodiments, criteria can be dynamic based upon data availability, with more stringent criteria being applied when more data are available or can be weighted to give preference to a particular criteria.
In some embodiments, filtering and combining at 508, 510, 512, 514 can essentially include combining the beacon distance and the computing device geolocation information for each individual sample to arrive at an overall beacon position uncertainty for each individual sample, then selecting the individual sample with the lowest beacon position uncertainty.
At 514, method 500 can include storing the filtered location data for a beacon in a beacon position database. An entry in the beacon position database can include beacon ID, beacon location, and time at the beacon location.
Systems and methods of the present disclosure can provide near-real time information about the location of tracked beacons 12a-12d to users of the system as well as other data associated with the beacon at the location(s) where it was detected. Beacon data can be provided via “beacon location reporting” functions of the App running on a mobile computing device 14a-14e as well as via other information platforms 22, 24, 26 and 28, which can include, for example, an event website. As described elsewhere herein, a user may be required to register as a user of the beacon tracking system and provide information such as identities of mobile-points-of-interest whose locations are of interest to the user and identifying information about specific events of interest to the user.
Beacon data can be presented in any suitable manner. On a mobile device, for example, the App can present a user/spectator with a home screen that illustrates a map of the user's surrounding geographical region. If there are race participants or other mobile points of interest with active beacons in the surrounding geographical region, the mobile application can direct the mobile device to scan for and display the nearby beacons. The mobile application can then display to the spectator a map with corresponding beacons and beacon events, as illustrated in
Illustrated in
The radio frequency transmitter device can have one or more radio frequency transmitter and/or receivers which can be combined into one unit (“transceivers”) 806. The radio frequency transceiver 806 can receive instructions from the processer 802 to transmit or receive a radio signal.
In some embodiments, the radio frequency transmitter device 800 can have additional features or functionality. For example, the radio frequency transmitter device 800 can also include additional sensor devices 808 such as, for example, accelerometers, magnetometers, altimeters or gyroscopes.
The radio frequency transmitter device can receive power from any type of energy storage or harvesting unit 810. This can include but is not limited to battery power, mechanical harvesting, solar harvesting or alternating current from an exterior source. The energy storage unit 810 connects to the remainder of the radio frequency transmitter device 800 and can provide enough power for the radio frequency transmitter device 800 to execute its functions.
In some embodiments, the system described herein uses a computing system to carry out the various functions described herein. Is to be understood that the system can include one or more computing systems but only one is depicted here for readability and simplicity.
The computing device 900 can be a computing device 900 located in a user's home or other place of business. In some embodiments, computing device 900 is a mobile device. The computing device 900 can be a stand-alone computing device or a networked computing device that communicates with one or more other computing devices 900 across a network 902. The additional computing device(s) 900 can be, for example, located remotely from the first computing device 900, but configured for data communication with the first computing device 900 across a network 902.
In some examples, the computing devices 900 include at least one processor or processing unit 904 and system memory 906. The processor 904 is a device configured to process a set of instructions. In some embodiments, system memory 906 may be a component of processor 904; in other embodiments system memory 906 is separate from the processor 904. Depending on the exact configuration and type of computing device, the system memory 906 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. System memory 906 typically includes an operating system 918 suitable for controlling the operation of the computing device 900, such as the WINDOWS® operating systems or the OS X operating system, or a server, such as Windows SharePoint Server, also from Microsoft Corporation, or such as a Mac running OS X. The system memory 906 may also include one or more software applications 920 and may include program data 922.
The computing device 900 may have additional features or functionality. For example, the computing device 900 may also include additional data storage devices 924 (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Computer storage media 924 may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory, removable storage, and non-removable storage are all examples of computer storage media. Computer storage media 924 includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computing device 900. An example of computer storage media 924 is non-transitory media.
In some examples, one or more of the computing devices 900 can be located in an establishment. In other examples, the computing device 900 can be a personal computing device that is networked to allow the user to access and utilize the system disclosed herein from a remote location, such as in a user's home, office or other location. In some embodiments, the computing device 900 is a smart phone tablet, laptop computer, personal digital assistant, or other mobile device. In some embodiments, system operations and functions are stored as data instructions for a smart phone application. A network 902 facilitates communication between the computing device 900 and one or more servers, such as an additional computing device 900, that hosts the system. The network 902 may be a wide variety of different types of electronic communication networks. For example, the network 902 may be a wide-area network, such as the Internet, a local-area network, a metropolitan-area network, or another type of electronic communication network. The network 902 may include wired and/or wireless data links. A variety of communications protocols may be used in the network 902 including, but not limited to, Wi-Fi, Ethernet, Transport Control Protocol (TCP), Internet Protocol (IP), Hypertext Transfer Protocol (HTTP), SOAP, remote procedure call protocols, and/or other types of communications protocols.
In some examples, the additional computing device 900 is a Web server. In this example, the first computing device 900 includes a Web browser that communicates with the Web server to request and retrieve data. The data is then displayed to the user, such as by using a Web browser software application. In some embodiments, the various operations, methods, and functions disclosed herein are implemented by instructions stored in memory. When the instructions are executed by the processor 904 of the one or more computing devices 900, the instructions cause the processor 904 to perform one or more of the operations or methods disclosed herein.
Persons of ordinary skill in arts relevant to this disclosure and subject matter hereof will recognize that embodiments may comprise fewer features than illustrated in any individual embodiment described by example or otherwise contemplated herein. Embodiments described herein are not meant to be an exhaustive presentation of ways in which various features may be combined and/or arranged. Accordingly, the embodiments are not mutually exclusive combinations of features; rather, embodiments can comprise a combination of different individual features selected from different individual embodiments, as understood by persons of ordinary skill in the relevant arts. Moreover, elements described with respect to one embodiment can be implemented in other embodiments even when not described in such embodiments unless otherwise noted. Although a dependent claim may refer in the claims to a specific combination with one or more other claims, other embodiments can also include a combination of the dependent claim with the subject matter of each other dependent claim or a combination of one or more features with other dependent or independent claims. Such combinations are proposed herein unless it is stated that a specific combination is not intended. Furthermore, it is intended also to include features of a claim in any other independent claim even if this claim is not directly made dependent to the independent claim.
Any incorporation by reference of documents above is limited such that no subject matter is incorporated that is contrary to the explicit disclosure herein. Any incorporation by reference of documents above is further limited such that no claims included in the documents are incorporated by reference herein. Any incorporation by reference of documents above is yet further limited such that any definitions provided in the documents are not incorporated by reference herein unless expressly included herein.
For purposes of interpreting the claims, it is expressly intended that the provisions of Section 112, sixth paragraph of 35 U.S.C. are not to be invoked unless the specific terms “means for” or “step for” are recited in a claim.
This application claims the benefit of U.S. Provisional Application No. 62/323,715 filed Apr. 17, 2016 and titled SYSTEM FOR COMMUNICATING POSITIONS OF MOBILE POINTS OF INTEREST WITHIN A GEOGRAPHICAL REGION, which is hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62323715 | Apr 2016 | US |
