POSITION IS LIKELY ACCURATE

RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Application No. 63/267,291, filed on January 28, 2022, and entitled “System and Method for Detecting a Likelihood a User Position is Spoofed”, which is hereby incorporated by reference in full.

BACKGROUND

[0002] Determining the exact location of a mobile device (e.g., a smartphone operated by a user) in an environment can be quite challenging, especially when the mobile device is located in an urban environment or is located within a building. Imprecise estimates of the mobile device's altitude, for example, may have life or death consequences for the user of the mobile device since an inaccurate altitude estimate can delay emergency personnel response times as they search for the user on multiple floors of a building. In less dire situations, imprecise altitude estimates can lead a user to the wrong area in an environment.

[0003] Spoofing a geolocation position is known in the art and occurs when a location of the user or device convincingly appears to be somewhere that is it not. Spoofing a location using x and y coordinates is common in mobile games that expect users to “collect” an item or reward. For example, known available software packages allow users to spoof their location in mobile games so the user can collect the item without actually visiting the location. In other words, the user fakes their location in order to collect the reward. On a larger scale, military operatives may spoof their location data to hide covert operations or to mask activities so their actual whereabout is a mystery. One spoofing technique uses a false 3D position, and then adds noise to create the appearance of frequently updated position data. Another spoofing technique uses a terrestrial radio transmitter to mimic GPS signals at a greater signal strength than the actual system can muster, effectively replacing real GPS signals with a fake signal.

[0004] Such spoofing activities may also be employed by users participating in the “metaverse”. The metaverse is an emerging technology and generally refers to shared virtual world environments which people can access via the Internet. The term can refer to digital spaces which are made more lifelike by the use of virtual reality (VR), augmented reality (AR), or mixed reality (XR). Gaming worlds exist in which users have a character that can walk around the virtual world environment and interact with other players. Blockchain technology can also be used in the metaverse where users can buy virtual land and other digital assets using cryptocurrencies and non- fungible tokens (NFTs).

SUMMARY

[0005] In some embodiments, a method is disclosed that includes a server receiving a plurality of data packets from a mobile device. Each data packet comprises a user pressure measurement corresponding to an estimated user position at a time indicated by an associated timestamp. The server identifies a plurality of reference pressure measurements associated with the estimated user positions and the associated timestamps. The server determines one or more of a user pressure stability metric, a combined stability metric, and a combined accuracy metric using one or more of the received user pressure measurements, the reference pressure measurements, and the associated timestamps. The server determines a likelihood value by comparing one or more of the user pressure stability metric, the combined stability metric, and the combined accuracy metric to a respective threshold. The server determines that one or more of the estimated user positions are unlikely accurate when the likelihood value exceeds a likelihood threshold and determines that one or more of the estimated user positions are likely accurate when the likelihood value does not exceed the likelihood threshold.

[0006] In some embodiments, a system is disclosed that includes a memory storing executable instructions and a processor. The processor is coupled to the memory and performs a method by executing the instructions stored in the memory. The method includes the processor receiving a plurality of data packets from a mobile device. Each data packet comprises a user pressure measurement corresponding to an estimated user position at a time indicated by an associated timestamp. The processor identifies a plurality of reference pressure measurements associated with the estimated user positions and the associated timestamps. The processor determines one or more of a user pressure stability metric, a combined stability metric, and a combined accuracy metric using one or more of the received user pressure measurements, the reference pressure measurements, and the associated timestamps. The processor determines a likelihood value by comparing one or more of the user pressure stability metric, the combined stability metric, and the combined accuracy metric to a respective threshold. The processor determines that one or more of the estimated user positions are unlikely accurate when the likelihood value exceeds a likelihood threshold and determines that one or more of the estimated user positions are likely accurate when the likelihood value does not exceed the likelihood threshold.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 is a simplified schematic diagram of an example system for determining the likelihood that one or more of the estimated user positions is likely or unlikely accurate, in accordance with some embodiments.

[0008] FIG. 2 shows a simplified example environment for determining a likelihood that one or more of the estimated user positions is likely or unlikely accurate or for validating a user position, in accordance with some embodiments.

[0009] FIG. 3 is a flowchart of a method for determining a likelihood that one or more of the estimated user positions are likely or unlikely accurate, in accordance with some embodiments.

[0010] FIG. 4 is a graph showing a pressure profile, in accordance with some embodiments.

[0011] FIG. 5 is a graph showing a pressure difference profile, in accordance with some embodiments.

[0012] FIG. 6 is a graph showing an altitude difference profile, in accordance with some embodiments.

[0013] FIG. 7 is a graph showing a pressure difference profile with vertical movement, in accordance with some embodiments.

[0014] FIGs. 8 and 9 detail the combined stability metric and combined accuracy metric respectively with regard to a respective threshold, with a conclusion, in accordance with some embodiments.

[0015] FIG. 10 is a table showing an assessment of the likelihood that user pressure measurements are likely accurate when considering more than one metric, in accordance with some embodiments.

[0016] FIG. 11 is a flowchart of a method for validating a likelihood that user position measurements are likely accurate, in accordance with some embodiments. [0017] FIG. 12 depicts simplified schematic diagrams of a transmitter, a mobile device, and a server, in accordance with some embodiments.

DETAILED DESCRIPTION

[0018] Spoofing a geolocation position is known in the art and occurs when a location of the user or device convincingly appears to be somewhere that is it not. Systems and methods are disclosed for determining a likelihood that one or more of the estimated user positions are likely or unlikely accurate using atmospheric pressure measurements made by a mobile device at the user’s actual position. Ambient air pressure varies over small timescales, especially during weather events, with pressure changing significantly every few minutes. Air pressure also varies over distance, with pressure gradients being significant on the order of a few kilometers. Therefore, if pressure measurements made by the user device correlate with reference pressure measurements associated with a given true position during a time frame, the mobile device is highly likely to be close to the true position, such as within a few kilometers.

[0019] As described herein, an estimated 2D or 3D position of a mobile device may be referred to as an “estimated user position.” Similarly, an atmospheric pressure measurement made using a barometric pressure sensor of the mobile device may be referred to as “a user pressure measurement.” Data such as user pressure measurements corresponding to an estimated user position at an associated timestamp for a user’s activity or for an event may be collected and compared to reference pressure measurements associated with the estimated user positions and the associated timestamps from a reference network. Based on generated metrics, the systems and methods may determine if the estimated position of the user is likely accurate given the received user pressure measurements and the reference pressure measurements at associated timestamps. From this analysis, whether one or more of the estimated user positions are likely or unlikely accurate is determined. When it is determined that the estimated position of the user is unlikely accurate, spoofing of the user’s position or location is suspected. When it is determined that the estimated position of the user is likely accurate, spoofing of the user’s position or location is not suspected. From this, the estimated user positions may be validated based on one or more of the estimated user positions are likely accurate - or not spoofed.

[0020] Embodiments of the systems and methods disclosed represent an improvement over conventional solutions which do not provide a suitable mechanism for checking, verifying, or validating an estimated user position to prevent spoofing based on using one or more of the received user pressure measurements, the reference pressure measurements, and the associated timestamps. Validating the physical position of a user at a particular time has practical applications. According to embodiments herein, spoofing of a user position or location may be eliminated so that fraud, imitation, and deception may be prevented. The validation of the physical position of the user provides proof of the position of the user at a particular time which enables improved security and accountability of user identities. For example, upon validation of the user’s position, a financial transaction, a conveyance of a good, or a digital treasure hunt dependent on the one or more estimated user positions may be conducted.

[0021] In some embodiments, an NFT may be generated when the user position is validated. This provides a digital certificate that proves the user’s position and other verifiable information which may be stored in a distributed digital ledger. The NFT may serve as a tamper-resistant record on a blockchain.

[0022] FIG. 1 is a simplified schematic diagram of an example system 100 for determining the likelihood that one or more of the estimated user positions (i.e., the position of a mobile device) is likely or unlikely accurate (e.g., spoofed), in accordance with some embodiments. In some embodiments, the system 100 generally includes a server 102 and several user devices or mobile devices 104. The server 102 generally communicates with the mobile devices 104 through a network 106. The server 102 represents one or more computerized devices, such as a cloud computing system, a server farm, a set of computers, a desktop computer, or a notebook computer, among others. The mobile devices 104 each generally represent a mobile phone, smartphone, a cell phone, another wireless communication device, a handheld computer, a notebook computer, a personal computer, a portable computer, a navigation device, a tracking device, a game console, a smart watch, a receiver, etc. The network 106 generally represents any appropriate combination of the Internet, cell phone communication systems, broadband cellular networks, wide area networks (WANs), local area networks (LANs), wireless networks, networks based on the IEEE 802.11 family of standards (Wi-Fi networks), and other data communication networks.

[0023] In some embodiments, each mobile device 104 generally includes a position sensor 108, a movement sensor 110, a barometric pressure sensor 112, a device data packet 118, and device activity data 120, among other hardware, software, and data. The position sensor 108 generally represents one or more appropriate sensor devices and associated software for detecting a position of the mobile device 104, such as for a Global Navigation Satellite System (GNSS, such as GPS, GLONASS, Galileo, Compass/Beidou), a terrestrial transmitter system, or a hybrid satellite/terrestrial system, among others. The movement sensor 110 generally represents one or more appropriate sensor devices and associated software for detecting movement of the mobile device 104, such as an accelerometer, a gyroscope, a magnetometer/compass, and/or a pedometer, among others. In some embodiments, all of the above data and sensors of a mobile device 104 may be used for determining a likelihood that an estimated user position is likely accurate or likely inaccurate, while in other embodiments only a portion of the above sensors and data may be used. For example, if the device activity data 120 were missing, it is still possible to estimate the likelihood that a position is likely accurate or unlikely accurate.

[0024] The barometric pressure sensor 112 represents any appropriate sensor device that generates an atmospheric pressure measurement with which the mobile device 104 determines its altitude. The device data packet 118 comprises a user pressure measurement corresponding to an estimated user position at a time indicated by an associated timestamp and may include other data such as activity data or motion data. In some embodiments, the user pressure measurement is generated by the barometric pressure sensor 112 at the mobile device 104. The mobile device 104 transfers the device data packet 118 to the server 102 for the server 102 to determine the likelihood that one or more of the estimated user positions are likely or unlikely accurate when the likelihood value exceeds a likelihood threshold.

[0025] In some scenarios, the estimated user position (e.g., a user position reported to an application on behalf of a user) is generated using the mobile device 104. However, in some scenarios the estimated user position might be injected by malware, spoofing software, or another device such as a laptop.

[0026] In some embodiments, the server 102 generally contains server data packets 122 (corresponding to the device data packets 118), server activity data 124 (corresponding to the device activity data 120), transition data 126 (whether derived by the server 102 or received from the mobile device 104), and reference data 128 among other hardware, software, and data. The server 102 generally maintains the server data packets 122, the server activity data 124, and the transition data 126 for each mobile device 104. The server activity data 124 and the transition data 126 are generally received by the server 102 from each of the mobile devices 104 as data in the server data packets 122 or are calculated by the server 102 from the data in the server data packets 122.

[0027] The reference data 128 includes a plurality of reference pressure measurements associated with the estimated user positions and the associated timestamps. The reference data 128 is generally received by the server 102 from a reference network such as a reference atmospheric weather network (not shown). The reference network is comprised of atmospheric sensors for measuring atmospheric pressure and/or temperature. Such sensors are often incorporated into stable pressure instruments (SPI) and/or weather stations. In general, a stable pressure instrument exhibits less sensor drift and produces more accurate atmospheric measurements as compared to a less stable pressure instrument of a so-called weather station. In some embodiments, the reference network may be a crowdsourced atmospheric weather network or other pressure networks.

[0028] FIG. 2 shows a simplified example environment for determining a likelihood that one or more of the estimated user positions is likely or unlikely accurate or for validating a user position, in accordance with some embodiments. The environment 200 includes a network of terrestrial transmitters 202, at least one of the mobile devices 104, and the server 102. The server 102 exchanges communications with various devices, such as the mobile device 104. Each of the transmitters 202 and the mobile device 104 may be located at different altitudes or depths that are inside or outside various natural or manmade structures (e.g., buildings 204 and 206), relative to different elevations throughout a terrain 208, as illustrated by examples in FIG. 2.

[0029] Positioning signals 210 and 212 are transmitted from the transmitters 202 and satellites 214, respectively, and are subsequently received by the mobile device 104 using known transmission technologies. The transmitters 202 may transmit the signals 210 using one or more common multiplexing parameters that utilize time slots, pseudorandom sequences, frequency offsets, or other approaches, as is known in the art or otherwise disclosed herein. Examples of possible hardware, software, and data components in the transmitters 202, the mobile device 104, and the server 102 are shown in FIGs. 1 and 12, as described herein. In particular, each transmitter 202 and mobile device 104 may include atmospheric sensors (e.g., barometric pressure sensors and temperature sensors, as appropriate) for generating measurements of atmospheric conditions (e.g., atmospheric pressure and temperature) that may be used by the reference network to generate the reference data 128. When using particular terrestrial transmitters 202, the timestamp and the authenticity of the transmitters used to determine the position may be validated.

[0030] As a person/user 216 with the mobile device 104 moves throughout such an example environment 200, the mobile device 104 may experience a variety of activities. For example, the mobile device 104 may be moving rapidly (e.g., its position changes significantly in a relatively short time) when it is in a vehicle that the user is driving (or riding in). In another example, the mobile device 104 may be moving somewhat rapidly (e.g., slower than is typical for driving, but faster than is typical for walking or running) when the user is riding a bicycle. In another example, when the user 216 is walking or running, the mobile device 104 may be moving somewhat slowly (relative to driving or biking), or movement data from the accelerometer may indicate steps by the user 216 while the barometric pressure data is not changing significantly. In another example, the mobile device 104 may be still (e.g., the movement data from the accelerometer is stable) when the user 216 is simply standing or sitting (as at 228) or parked in a vehicle. Other possible activities may include running, roller skating, skateboarding, skiing, swimming, etc. Thus, although the examples described herein use driving, walking, and still activities, it is understood that other embodiments can use any appropriate combination of determinable activities. The activity may occur in a location area 234.

[0031] It is known in the art that an estimated position or location of the user may easily be spoofed to make the estimated position or location appear valid. However, it is difficult to spoof an atmospheric pressure measurement or a time series of pressure measurements in any given position or location since atmospheric pressure is not a fixed value, nor is it easily predictable to a fine enough resolution and accuracy. Since an ambient pressure and a true user position are highly correlated, meaning people in the nearby locations experience very similar ambient pressure measurements, detection of an uncorrelated pressure with a given position could imply that a user position was spoofed. The systems and methods disclosed herein can detect if the user position is spoofed by determining if one or more of the estimated user positions are likely or unlikely accurate when a likelihood value exceeds a likelihood threshold. [0032] FIG. 3 is a flowchart of a method 300 for determining a likelihood that one or more of the estimated user positions are likely or unlikely accurate, in accordance with some embodiments. The particular steps, order of steps, and combination of steps are shown for illustrative and explanatory purposes only. Other embodiments can implement different particular steps, orders of steps, and combinations of steps to achieve similar functions or results.

[0033] At block 302, the server 102 receives from the mobile device 104 a plurality of device data packets 118 (or the device activity data 120). Each data packet comprises a user pressure measurement corresponding to an estimated user position at a time indicated by an associated timestamp. The device data packets 118 and the device activity data 120 correspond to the plurality of server data packets 122 and the plurality of server activity data 124 respectively in the server 102. In some embodiments, the user pressure measurement is generated by the barometric pressure sensor 112 at the mobile device 104, and the estimated user position is generated using the mobile device 104.

[0034] At block 304, the server 102 identifies a plurality of reference pressure measurements associated with the estimated user positions and the associated timestamps of server data packets 122 or the plurality of server activity data 124. In some embodiments, the server 102 also determines any additional weather parameters. This may be accomplished by querying a reference network such as a reference atmospheric weather network or a crowdsourced atmospheric weather network. In some embodiments, the reference pressure measurements are generated using a reference network. The determination of the plurality of reference pressures and the plurality of reference temperatures can be done in multiple ways such as averaging all weather stations, averaging a number of closest weather stations, or the like. This may be set forth in U.S. Patent Number 10,386,448 entitled “Systems and Methods for Selecting Atmospheric Data of Reference Nodes for Use in Computing the Altitude of a Receiver” which is hereby incorporated by reference.

[0035] The determination of the plurality of reference pressures and the plurality of reference temperatures can be done by interpolating across weather stations and/or across geographic features. This may be set forth in U.S. Patent Application Number 18/053,907, filed November 9, 2022, and entitled “Mitigating Atmospheric Effects from Geographical Anomalies on Reference Pressure Estimates” which is hereby incorporated by reference. In some embodiments, in lieu of information from the reference network, a range of reference pressures or a range of reference temperatures, such as a range of minimum reference pressures and a range of maximum reference pressures, or a range of minimum reference temperatures and a range of maximum reference temperatures, may be estimated from historical climatology data. In some embodiments, the changes in pressure over time may be compared to the relative changes of the pressures in a building-terrain envelope. The building-terrain envelope is a vertical region that can be bounded by the building top above and/or the terrain below, with some buffer. This may include a region below the terrain for cases where there are subterraneous floors (i.e., basement levels).

[0036] At block 306, the server 102 determines one or more of a user pressure stability metric, a combined stability metric, and/or a combined accuracy metric using one or more of the received user pressure measurements, the reference pressure measurements, and the associated timestamps. The user pressure stability metric is determined by using one or more of the user pressure measurements corresponding to the estimated user position and the associated timestamp of the plurality of server data packets 122 or the plurality of server activity data 124. To increase the integrity of the data, there may be a minimum amount of data points necessary before determining the metric. In some embodiments, the user pressure may be unchanged and stuck at a fixed value. When this occurs, a flag may be introduced by the server 102 to indicate a likely sensor error and that the pressure may not have been spoofed. Alternatively, in some embodiments, this may indicate a spoofed pressure.

[0037] For example, FIG. 4 is a graph showing a pressure profile, in accordance with some embodiments. The pressure profile graph 400 illustrates a time series aligned plurality of user pressure measurements corresponding to an estimated user position and the associated timestamps, and a time series aligned plurality of reference pressure measurements associated with the estimated user positions and the associated timestamps received by the server 102. In this example, the user may be in a fixed position such as the user 216 standing or sitting (228) in FIG. 2. The y-axis is pressure in Pascals and the x-axis is a time interval or timestamp. The server 102 may sort the user pressure measurements into “likely accurate” and “unlikely accurate” based on the user pressure stability metric. This may be based on comparing a standard deviation or variance of the data difference to a threshold value.

[0038] By way of example, the threshold value may be zero to three meters or zero to 30 Pascals so that data within the threshold value is assigned as a likely accurate pressure and data greater than the threshold value is assigned as an unlikely accurate pressure. In some embodiments, when the user pressure stability metric is less than a threshold value such as 0.1 Pascals, the reported user pressure may be suspect of being set to a fixed value. In such scenarios, the reported user pressure may be thereafter characterized as being an unlikely accurate pressure. For example, in a spoofing scenario, the estimated user pressure may be set to a constant pressure value whereas the pressure value should vary in most circumstances. In other embodiments, other threshold values may be used depending on the application such as user criteria, industry-standard, or geography.

[0039] In addition to comparing time series data using a metric such as the standard deviation of the difference between the time series, curve matching techniques to determine the similarity of waveforms or time series may also be used. Time series similarity can also be found using frequency domain similarity analysis of the spectral content, for example, of the two waveforms.

[0040] The plurality of user pressure measurements corresponding to the estimated user position plotted in FIG. 4 include likely accurate pressures 402, unlikely accurate pressures 404, and reference pressures 408 (e.g., reference pressure measurements associated with the estimated user positions) from the reference network, all of which are identified in the key 406. When comparing the plot of likely accurate pressures 402 to the plot of reference pressures 408, the plots have a same pattern such as rising and falling at the same time intervals, although offset from one another. This is interpreted as the estimated position of the user, based on the user pressure measurements corresponding to the estimated user position, is most likely in the same area as the reference pressures, but at a different altitude. In this scenario, spoofing of the user position is not suspected. On the other hand, when comparing the plot of unlikely accurate pressures 404 to the plot of reference pressures 408, the plots have very different patterns such as rising and falling at different time intervals. This indicates that the unlikely accurate pressures - based on the user pressure measurements corresponding to the estimated user position - are not in the same location or position as the reference pressures. In this scenario, spoofing of the user position is suspected.

[0041] The server 102 may have checks in place to ensure the integrity of the user pressure measurements corresponding to the estimated user position by applying conditions to validate the user pressure time series. The server 102 may evaluate the difference between the user pressure data points (e.g., a first pressure going to a second pressure) per time interval to ensure the altitude does not change in a physically impossible way over time. For example, it would be unlikely for the altitude of the user to change by 100 meters in one second, corresponding to about a 1000 Pascal change in one second. If this is shown in the user pressure time series, spoofing may be suspected.

[0042] The server 102 determines a time series aligned pressure difference profile as being a difference between the received user pressure measurements at the associated timestamps and the reference pressure measurements at the associated timestamps. FIG. 5 is a graph showing a pressure difference profile, in accordance with some embodiments. The pressure difference profile graph 500 illustrates plot 502 which is the time series aligned pressure difference between the plurality of likely accurate pressures and the plurality of reference pressures from FIG. 4 where the user may be in a fixed position such as the user 216 standing or sitting (228) from the example in FIG. 2. Plot 504 is also illustrated, which is the time series aligned pressure difference between the plurality of unlikely accurate pressures and the plurality of reference pressures from FIG. 4. Plots 502 and 504 are described in the key 506.

[0043] Plot 502 is practically flat or at 0° because the time series aligned pressure difference between the plurality of likely accurate pressures and the plurality of reference pressures is consistent over time. Plot 502 may serve as a check that the location of the user is most likely in the same area as the reference pressures so spoofing of the user position is not suspected based on the reference pressures alone. Plot 504 illustrates a curved line falling and rising over the time interval and having a slope(s). The time series aligned pressure difference between the plurality of unlikely accurate pressures and the plurality of reference pressures is not consistent over time, but rather, changes over time. Plot 504 may serve as a check that the position of the user is most likely not in the same location as the received reference pressures so spoofing of the user position is suspected.

[0044] Referring back to FIG. 3, at block 306, the server 102 additionally, or alternatively, calculates a time series aligned altitude profile using the received user pressure measurements at the associated timestamps, the reference pressure measurements at the associated timestamps, the reference temperature measurements at the associated timestamps, and a barometric formula. The determined altitudes are based on the received user pressure measurements at the associated timestamps, the reference pressure measurements at the associated timestamps, and the plurality of reference temperatures using a barometric formula. The plurality of reference pressure measurements and the plurality of reference temperatures are received from the reference network.

[0045] In a barometric-based positioning system, altitude can be determined using a measurement of pressure from a calibrated pressure sensor of a mobile device along with ambient pressure measurement(s) from a network of calibrated reference pressure sensors and a measurement of ambient temperature from the network or other sources. An estimate of an altitude of a mobile device (h _mo bHe)' can be determined by the mobile device, a server, or another machine that receives needed information as follows: (Equation 1), where P _mO biie is the estimate of pressure at the location of the mobile device by a pressure sensor of the mobile device, P _sen sor is ^an estimate of pressure at the location of a reference pressure sensor that is accurate to within a tolerated amount of pressure from true pressure (e.g., less than 5 Pa), T _remote is an estimate of temperature (e.g., in Kelvin) at the location of the reference pressure sensor or a different location of a remote temperature sensor, h _sensor is an estimated altitude of the reference pressure sensor that is estimated to be within a desired amount of altitude error (e.g., less than 1.0 meters), g corresponds to the acceleration due to gravity (e.g., -9.8 m/s ² ), A is a gas constant, and is the molar mass of air (e.g., dry air or other). The minus sign (-) may be substituted with a plus sign (+) in alternative embodiments of Equation 1, as would be understood by one of ordinary skill in the art (e.g., $=9.8 m/s ² ). The estimate of pressure at the location of the reference pressure sensor can be converted to an estimated reference-level pressure that corresponds to the reference pressure sensor in that it specifies an estimate of pressure at the latitude and longitude of the reference pressure sensor, but at a reference-level altitude that likely differs from the altitude of the reference pressure sensor. The reference-level pressure can be determined as follows: where P _sen sor is the estimate of pressure at the location of the reference pressure sensor, P _re j- is the reference-level pressure estimate, and h _re is the reference-level altitude. The altitude of the mobile device h _mob n _e can be determined using Equation 1, where h _re is substituted for h _sensor and P _re f is substituted for Psensor • The reference-1 evel altitude h _re f may be any altitude and is often set at 0 meters mean sea level (MSL) or 0 meters height above ellipsoid (HAE). T _remote is the measurement of ambient temperature at the location of the reference pressure sensor. When two or more reference-level pressure estimates are available, the reference-level pressure estimates are combined into a single reference-level pressure estimate value (e.g., using an average, weighted average, or other suitable combination of the reference pressures), and the single reference-level pressure estimate value is used for the reference-level pressure estimate P _re f.

[0046] FIG. 6 is a graph showing an altitude profile, in accordance with some embodiments. The altitude is calculated in meters using the received user pressure measurements such as the likely accurate pressures and the unlikely accurate pressures of FIG. 4. The altitude profile graph 600 has altitude in meters on the y-axis over time on the x-axis. Plot 602 illustrates the time series aligned altitude profile calculated using the plurality of likely accurate pressures and the plurality of reference pressures and reference temperatures (e.g., reference pressure measurements associated with the estimated user positions) from FIG. 4. Plot 604 illustrates the time series aligned altitude profile determined by using the plurality of unlikely accurate pressures and the plurality of reference pressures from FIG. 4, with a plurality of reference temperatures (not shown). Plots 602 and 604 are described in the key 606. Plot 602 is practically flat or at 0° because the time series aligned altitude calculated using the likely accurate pressures and the plurality of reference pressures is correlated and consistent over time.

[0047] In some embodiments, the altitude profile may be more stable than the pressure difference profile in cases where the user position is “vertically far” from the weather stations being used to determine the reference weather data. In this context, “vertically far” means that the difference in altitude exceeds a threshold value regardless of the horizontal distance, for example 100 meters. Horizontal distance is important in determining the closest reference weather data to the user’s position, but it need not be extremely accurate to estimate a reasonable reference weather data. Specifically, the atmospheric pressure gradient in the user’s area may be weak over large distance scales. For example, if the pressure gradient is 1 Pa / 1 km, the user could spoof a position 1 km away. In this case, the user’s true reference pressure compared to the spoofed reference pressure would differ by 1 Pa. This is a small amount and it would be hard to establish a spoofed location with certainty since the small amount may be a statistical fluctuation. The server 102 can perform other checks to ensure the integrity of the data.

[0048] Referring back to FIG. 3, at block 306, the server 102 additionally, or alternatively, determines a combined stability metric using the time series aligned pressure difference profile (e.g., a difference between the received user pressure measurements at the associated timestamps and the reference pressure measurements at the associated timestamps) and the time series aligned altitude profile (e.g., determined using the received user pressure measurements at the associated timestamps, the reference pressure measurements at the associated timestamps, the reference temperature measurements at the associated timestamps, and a barometric formula). The combined stability metric is further determined by using a first slope of the time series aligned pressure difference profile and a second slope of the time series aligned altitude profile. For example, the combined stability metric determines how “flat” the difference is between the received user pressure measurements and the reference pressure measurements, and how “flat” is the calculated altitude. Other ways to determine the stability metric, such as a deviation from a central tendency, are considered.

[0049] This metric distinguishes between vertical motion and uncorrelated pressure and may be characterized by standard deviation, variance, or another distribution from a central tendency (e.g., a mean or median value) that screens for sudden jumps or changes in the data points. The standard deviation can be applied to smaller segments or clusters of data. For example, in some embodiments, the difference between a set of data clusters to another set of data clusters cannot exceed a threshold pressure that can be derived from a specific use case such as using building data. Data clusters can be determined using additional sensor information (e.g., inertial sensors indicating insignificant user motion) or activity state information (e.g., activity or activity transitions indicating insignificant user motion).

[0050] As described herein, the server 102 may have checks in place to ensure the integrity of the data. The determined altitude ranges for the user pressures may be compared to a building-terrain envelope for vertical motion transitions in data that correspond to the building-terrain envelope. For example, a user cannot likely fly between buildings, so the determined altitudes should be altitudes indicative of the user walking to a ground floor or skybridge in order to be in a neighboring building. Additionally, the determined altitudes need to be within the building envelope. For the sensors used, a calibrated sensor may have some small range (e.g., +/- 3 meters), but an uncalibrated sensor may have some large range (e.g., +/- 50 meters). When the range overlaps the building-terrain envelope, it is possible that the user is within the building, or it is difficult to disambiguate spoofing from calibration. When the range does not overlap the building-terrain envelope, the altitude is unphysical and thus the user position is suspect, or it is likely to disambiguate spoofing from calibration since calibration issues alone cannot explain the discrepancy. For example, if the determined altitude is 100 meters above the local terrain and the building has an envelope of only two stories, which is approximately 10 meters, the user is well outside of the building envelope and spoofing may be suspected. Other sensor information may be used to cross-check against movement. This may be set forth in U.S. Patent Number 10,805,452 entitled “Systems and Methods for Determining a Height of a Mobile Device Above a Surface” which is hereby incorporated by reference.

[0051] FIG. 7 is a graph showing a pressure difference profile with vertical movement, in accordance with some embodiments. In this example, the user may be moving such as walking up flights of stairs then walking down or riding in an elevator to higher floors and then to lower floors. The pressure difference profile graph 700 is similar to that shown in FIG. 5 which is the pressure difference profile for a fixed position. The graph 700 illustrates clusters 702 which are the time series aligned pressure difference profile between the received user pressure measurements at the associated timestamps and the reference pressure measurements at the associated timestamps. The key 706 describes a vertical movement standard deviation of 84.02 Pascals for all the clusters combined and a standard deviation per cluster ranging between 6.7 Pascals to 8.53 Pascals. This demonstrates that the time series aligned pressure difference between the received user pressure measurements at the associated timestamps and the reference pressure measurements at the associated timestamps are stable per cluster or have the same pattern in a short time interval as shown by the clusters. This means that the user pressure measurement corresponding to an estimated user position are most likely from the same general location (or position) as the reference pressures. In this case, the data are analyzed over short time intervals as opposed to single data point-to-data point to see the clusters and recognize that the user is changing altitude.

[0052] Referring to FIG. 3, at block 306, the server 102 additionally, or alternatively, calculates a combined accuracy metric using the time series aligned pressure difference profile (e.g., a difference between the received user pressure measurements at the associated timestamps and the reference pressure measurements at the associated timestamps) and the time series aligned altitude profile (e.g., determined by using the received user pressure measurements at the associated timestamps, the reference pressure measurements at the associated timestamps, the reference temperature measurements at the associated timestamps, and a barometric formula). The combined accuracy metric is further determined by determining a proximity of the time series aligned pressure difference profile to a first expected result, and a proximity of the time series aligned altitude profile to a second expected result. The combined accuracy metric is a metric that quantifies the excursion distribution of either a pressure difference profile or an altitude profile from its expected respective values. For example, if a user is expected to be at 10 meters and the altitude time series wanders from 9 meters to 11 meters to 9.5 meters, the metric would quantify that 80% of the results have an error of less than 1.5 meters. The Cumulative Distribution Function (CDF) of the absolute value of the measured altitude minus the true altitude may be determined and various percentages (e.g., 80%, 90%) reported. The metric could be reported as both a metric in magnitude and percentage. Alternatively, the metric may be “all” or 100% of the data points are within 5 meters. In some embodiments, the combined accuracy metric is a mathematical combination and may have a weighted value applied.

[0053] In some embodiments, the combined accuracy metric may be influenced by the calibration of the sensor. By way of example, for an uncalibrated sensor, a calibration range of A meters (e.g., 30 to 50 meters) may be assumed, meaning the uncalibrated user sensor could be off by up to +/- A meters or +/- B Pascals, where the barometric formula may be used to convert between A and B, yielding roughly 8 to 14 Pascals per meter. The calibration range may be specified by the identity or quality of the sensor, or the identity or quality of the device in which the sensor is located. For a calibrated sensor, the calibration range A is small, such as 3 to 5 meters, which is significantly smaller than for the uncalibrated user sensor. In other embodiments, as described herein, the range of determined altitudes of the user may be compared to the known altitude of the terrain and building database to determine if the user is likely within the building-terrain envelope, or if no buildings are in the vicinity of the user, within a range of the terrain value in the vicinity of the user’s position. When the range of determined altitudes of the user exceeds the building-terrain envelope - or does not overlap with the building-terrain envelope, spoofing may be suspected. For an uncalibrated sensor, the range would be very large compared to a calibrated sensor.

[0054] At block 308 of the method 300 shown in FIG. 3, the server 102 determines a likelihood value by comparing one or more of the user pressure stability metric, the combined stability metric, and/or the combined accuracy metric to a respective threshold value. The respective threshold may be a distance, pressure, altitude or combination thereof. As described herein, respective threshold values vary depending on the application, and include user criteria, industry-standard criteria, geography, or the type of reference network used. For example, a calibrated network or a reference atmospheric weather network can generate data that is likely more accurate than a crowdsourced atmospheric weather network, so a smaller threshold value may be applied. For example, three meters may be used as the threshold value. Since the data from the crowdsourced atmospheric weather network may be less accurate than other networks, the threshold value for the crowdsourced data may be larger than three meters, such as 10 meters. Methods to improve crowdsourced pressures may be set forth in U.S. Patent Number 10,704,905 entitled “Systems and Methods for Determining a Reference Pressure for Use in Estimating an Altitude of a Mobile Device,” and U.S. Patent Number 10,378,894 entitled “Systems and Methods for Estimating an Altitude of a Mobile Device Based on Detected Temperature Conditions,” which are both hereby incorporated by reference.

[0055] In one example, if the combined stability metric from block 306 is determined to be 50 meters and the threshold value is three meters, since 50 meters is significantly more than the threshold value of three meters, the system would fail the threshold test. The result (e.g., 50 meters) indicates the pressure difference between the user pressure and the reference pressure may not be stable and may indicate uncorrelated user pressure with reference pressure or location spoofing. [0056] In some embodiments, the likelihood value may be based on the difference or absolute value between the user pressure stability metric, the combined stability metric, or the combined accuracy metric as compared to the respective threshold. In other words, the likelihood value is how close the given metric is to the respective threshold. The absolute value of the difference may be assessed for statistical significance with a normal distribution function, standard deviation, Cumulative Distribution Function (CDF) or the like. In some embodiments, the likelihood value may be indicated as standard deviations below or above the respective threshold value. In some embodiments, the likelihood value may be a weighted combination of the user pressure stability metric, the combined stability metric, or the combined accuracy metric as compared to the respective threshold, and the weights could be representative of a numerical distance to a respective threshold value. In some embodiments, such weights could be binary and be only 0 or 1, or the weights could represent a continuous distribution.

[0057] At block 310, the server 102 determines that one or more of the estimated user positions are unlikely accurate when the likelihood value exceeds a likelihood threshold, and at block 312, the server 102 determines that one or more of the estimated user positions are likely accurate when the likelihood value does not exceed a likelihood threshold. The likelihood threshold may be based on user criteria, industry-standard criteria, geography, or reference network. In some embodiments, the likelihood threshold may be determined by using a population of previously measured values. For example, in some embodiments, a likelihood threshold may be representative of one or two standard deviations from a central tendency of a distribution of the previously measured values.

[0058] As an example, the central tendency may be 10 and the standard deviation may be two. Therefore, the likelihood threshold would be between 6 and 14. If the likelihood value falls outside this range, or above this range, or below this range, the likelihood is high that one or more of the estimated user positions are unlikely accurate.

[0059] In another non-limiting example, if the combined stability metric is determined as 2.0 meters, the likelihood threshold may be one standard deviation from a central tendency of previously measured values. The central tendency is 2.5 meters so the likelihood threshold would be between 1.5 meters and 3.5 meters, or one standard deviation from the central tendency. Since the combined stability metric is within the likelihood threshold, this would pass the threshold test. The result is stable and indicates a correlation between the received user pressure measurements at the associated timestamps and the reference pressure measurements at the associated timestamps and therefore, one or more of the estimated user positions are likely accurate and not spoofed.

[0060] The metrics may be converted into a confidence value describing the confidence of the conclusion that the user’s position is spoofed. The confidence value may depend on the number of data points, such as how close the metrics are to the respective threshold, the type of reference network used, a stability fit metric, or the like. For example, it may be described as a PASS/FAIL assessment or a percentage confidence in spoofing.

[0061] FIGs. 8, 9, and 10 are tables showing an assessment of the one or more of the estimated user positions that are likely or unlikely accurate (e.g., spoofed), in accordance with some embodiments. FIGs. 8 and 9 detail the combined stability metric and combined accuracy metric respectively to a respective threshold, with a conclusion. In general, when the metric FAILs against the respective threshold, the likelihood is that the user pressure measurements are spoofed, or unlikely accurate. FIG. 10 is a table showing an assessment of the likelihood that user pressure measurements are likely accurate when considering more than one metric, in accordance with some embodiments. The combined stability metric and combined accuracy metric are shown with PASS/FAIL relative to their respective threshold and the conclusion. In some embodiments, there may be a mismatch between PASS/FAIL for the combined stability metric and combined accuracy metric, meaning the conclusion may be unknown as opposed to likely or unlikely accurate. For example, the user may be in a location or position where the building database is incorrect, the sensor calibration value exceeds the expected value, the position is coincidentally spoofed to a position with similar pressures, or the user's position could be in an inopportune location such as in a very tall building where altitude could span a range of possibilities and spoofing cannot be confidently determined.

[0062] In some embodiments, each determined metric such as the user pressure stability metric, the combined stability metric, and the combined accuracy metric may be assigned a confidence value, and then the confidence values for these metrics may be combined in any manner to generate a combined confidence value. For example, the combined stability metric may have a confidence value of 90%, the combined accuracy metric may have a confidence value of 60%, and the combination may have a confidence value of 75%. In some embodiments, before generating the combined confidence value, each confidence value for the metrics (e.g., the user pressure stability metric, the combined stability metric, and the combined accuracy metric) may be assigned a weighted value. Appropriate weights can be determined using field data measurements and aligning with expected results.

[0063] The metrics may be combined by using the weighted confidence values to generate a combined confidence value. For example, if W1 corresponds to the weight of the first metric, W2 corresponds to the weight of the second metric, and Cl and C2 are first and second confidence values respectively, then (Equation 3).

In some embodiments, the metrics are combined by multiplying the individual metric confidence value percentages along with appropriate scale factors:

Combined Confidence = (.41 x Cl) x (.42 x C2) (Equation 4), where Al and A2 are scale factors that can amplify or reduce the individual confidences.

[0064] Scale factors act similarly to weights but may be used to normalize the Combined Confidence to not be too small (e.g., 1%) or unphysically large (e.g., 200%). For example, the scale factor for Cl may be 1.2 since the first metric tends to underestimate confidence, and the scale factor for C2 may be 0.7 since the second metric tends to overestimate confidence. These scale factors can be determined from existing measurements across a variety of environments and circumstances. Alternatively, one scale factor can be combined such that A12 = (Al x A2) and

Combined Confidence = (.412 x Cl x C2) (Equation 5).

[0065] The combined confidence value may be used to determine if the estimated user positions are likely accurate. For example, the estimated user positions are likely accurate when the combined confidence value exceeds a combined confidence value threshold, and the estimated user positions are unlikely accurate when the combined confidence value does not exceed the combined confidence value threshold.

[0066] In further embodiments, using method 300 for determining a likelihood that an estimated user position is likely or unlikely accurate, the inverse problem may be constructed such as determining where the user is most likely located for the user pressure measurements at the associated timestamps. For example, for each timestamp, the reference pressure and reference temperature may be queried in a gridded fashion across an area of interest such as the state, country, etc. This could be compared to user pressure measurements (and/or determined altitudes) for the gridded area. Depending on matches, the likelihood of the user position may be determined. A confidence value may be calculated per grid point, and confidence maps of the areas of interest may be generated. This is referred to herein as “pressure fingerprinting”.

[0067] The systems and methods disclosed herein may be used to validate a user’s position. For example, the user’s physical position at a given time, or the vertical position of where the user is physically located, may be validated. In another example, the user’s physical position at a given time, for the complete x, y, and z geolocation of where the user is physically located may be validated. As described herein, when using GPS-based technology to estimate a user’s position or location, the estimated position or location can be spoofed quite easily. By using embodiments of the present disclosure, such as the method 300 for determining the likelihood that user position measurements are likely or unlikely accurate, spoofing can be recognized and, in some embodiments, eliminated. As technology applications in the metaverse emerge, and the physical and the digital worlds are monetized, validating the physical position of a user at a particular time prevents spoofing of the physical position or location and can prevent fraud. The validation of the physical position of the user provides proof of the position of the user at a particular time with a confidence level. The embodiments herein may also validate the buying of digital assets where being represented in the physical world is a requirement. In some embodiments, a validation confidence value may be provided with the validation.

[0068] FIG. 11 is a flowchart of a method 1100 for validating a likelihood that user position measurements are likely accurate, in accordance with some embodiments. The method 1100 begins at block 1102, executing method 300. Method 300 is described in blocks 302 to 312 with reference to the flowchart in FIG. 3. The embodiments of blocks 302 through 312 have been described herein and will not be described again in detail. In some embodiments, the blocks may be performed sequentially or in a different order, and some of the blocks may be performed simultaneously. In some embodiments, the vertical position of the user may be validated by leveraging sensors in the mobile device to read the barometric pressure and comparing it to local conditions that are measured through the reference network. The server 102 may calculate the specific altitude measurement of the mobile device 104 based on the data. The altitude measurement may be an “air fingerprint” in a specific software application to validate the physical presence of the user - with vertical position - of where someone is, including the timestamp of when they are there.

[0069] At block 1104, in some embodiments, the one or more of the estimated user positions is validated when it is determined that the one or more of the estimated user positions are likely accurate, as determined in block 312. In some embodiments, the one or more of the estimated user positions is validated when the likelihood value exceeds a benchmark. The benchmark may be associated with a YES/NO condition, a PASS/FAIL criteria, a percentage, an upper limit, or a lower limit. For example, the benchmark may be associated with a YES/NO condition such as when it is determined that the one or more of the estimated user positions are likely accurate (e.g., not spoofed), the user position is VALIDATED. Conversely, when it is determined that the one or more of the estimated user positions are unlikely accurate (e.g., spoofed), the user position is NOT VALIDATED. In some embodiments, the benchmark may be associated with a percentage. For example, it may be determined that the one or more of the estimated user positions that are likely accurate (e.g., not spoofed) is 10%. This may be compared to the benchmark whereas the benchmark is at least 70% meaning that when the one or more of the estimated user positions that are likely accurate (e.g., not spoofed) is compared to the benchmark - 10% versus 70%, the one or more of the estimated user positions are NOT VALIDATED since 10% is not at least 70%. Put another way: user position 0%-10% likely accurate = user position is NOT VALIDATED user position 70%-100% likely accurate = user position is VALIDATED [0070] Other benchmarks may be used depending on the application. [0071] There are many practical applications for the method 1100 for validating the position of the user at a specific time to prevent spoofing and fraud. In some embodiments, upon validation, a financial transaction, a conveyance of a good, or a digital treasure or scavenger hunt is conducted.

[0072] In some embodiments, validating the position (e.g., location) and time when the user was present may be used in different types of financial transactions. For example, the user may buy virtual real estate in the digital world that is based on a physical location or position. In this way, the physical location may be validated in the digital world such as the metaverse. In another example, rent in a digital or physical currency may be collected. The user may visit the physical location or position and the method 1100 validates that the user visited the physical location. Upon validation, the financial transaction such as collecting rent may occur. In some embodiments, the systems and methods herein may validate the location of the user then a conveyance of a good is executed. For example, once the position of the user is validated, the user may be permitted to purchase a digital representation of a good. For real estate, the physical location such as a vertical location or position in an urban area may be validated then “air rights” for the real estate may be granted. In some embodiments, the digital treasure or scavenger hunt may be associated with a virtual game in which players need to visit a physical location to collect a virtual item or reward. Once the systems and methods described herein validate the user’s estimated position, the player collects the virtual item or reward. In another example, a person may attend a specific event (e.g., concert or sporting event) to gain access to specific content. Accordingly, once the person’s estimated user position is validated, access to the content is granted.

[0073] By using method 1100, the estimated position - with x, y, and z coordinates - and time when the user is actually at the physical location, may be validated when the one or more of the estimated user positions are likely accurate. This eliminates cheating by the user for spoofing the location or position without physically visiting the location. In some games, users collect a prize when they physically visit, for example, the 10 ^th floor of a building. The systems and methods disclosed herein prevent users from merely “driving by” the building and not ascending to the 10 ^th floor.

[0074] A Non-fungible Token (NFT) is a digital asset that represents real- world objects like art, music, in-game items, and videos, and can be bought and sold. In some embodiments, once the position of the user has been validated by method 1100, an NFT may be generated when the one or more of the estimated user positions are likely accurate is validated. This represents a validation that the user has visited the actual physical location or position and is a digital certificate that provides verifiable information as to who the owner is and allows the NFT to be stored in the database such as a distributed digital ledger. The NFT may serve as proof or a receipt and have an assigned confidence level. The validation by the method may be encoded or stamped into the NFT so the information stays with the NFT, thereby becoming a permanent record when bought or sold. The quality metric value of the validation with the confidence value becomes part of the value of the NFT. The NFT may be stored on a blockchain and the system 100 also stores the record of the NFT in storage 130 (see FIG. 1) in case of disputes. In a dispute, the information used, such as a proof of validation, evidence of the NFT, the accuracy of the system 100, method 300 and method 1100, the type of data collected for validation, and the actual data collected for validation, may be relied upon. In further embodiments, a fee or service charge may be incurred to validate the position of the user and/or to store and retrieve proof of that validation.

[0075] Regarding the example of buying digital real estate in the metaverse, an NFT may be generated for this transaction and saved on the blockchain as a permanent, verifiable record. In some embodiments, the NFT, the record of the transaction, and the ownership of the digital real estate may be presented on different platforms. The system 100 may serve as a Title Company for digital real estate transactions to verify the legality of the purchase.

[0076] Conversely, if an NFT is visible in a certain position and at a particular height, the methods described herein can validate the digital placement of the NFT based on a physical world location or position. For example, a digital ticketing platform may leverage NFTs as "ticket stubs" where the physical location verification can be used to validate the attendance of an individual at a concert or event.

[0077] In some embodiments, validation of an estimated user position may be used as part of a two-factor security or authentication system. In some embodiments, validation of an estimated user position may be used as part of a security protocol for allowing or disallowing a user to view sensitive or classified data.

[0078] FIG. 12 depicts simplified schematic diagrams of a transmitter, a mobile device, and a server, in accordance with some embodiments. By way of example in FIG. 12, transmitters 202 discussed herein may include: a mobile device interface 11 for exchanging information with a mobile device 104 (e.g., antenna(s) and RF front end components known in the art or otherwise disclosed herein); one or more processor(s) 12; memory/data source 13 coupled to one or more processors 12 for providing storage and retrieval of information and/or program instructions; atmospheric sensor(s) 14 for measuring environmental conditions (e.g., pressure, temperature, humidity, other) at or near the transmitter 202; a server interface 15 for exchanging information with a server 102 (e.g., an antenna, a network interface, or other); and any other components known to one of ordinary skill in the art. The memory/data source 13 may include memory storing software modules with executable instructions, and the processor(s) 12 may perform different actions by executing the instructions from the modules, including: (i) performance of part or all of the methods as described herein or otherwise understood by one of skill in the art as being performable at the transmitter 202; (ii) generation of positioning signals for transmission using a selected time, frequency, code, and/or phase; (iii) processing of signaling received from the mobile device 104 or another source; or (iv) other processing as required by operations described in this disclosure. Signals 210 generated and transmitted by the transmitter 202 may carry different information that, once determined by the mobile device 104 or the server 102, may identify the following: the transmitter 202; the transmitter's position; environmental conditions at or near the transmitter 202; and/or other information known in the art. The atmospheric sensor(s) 14 may be integral with the transmitter 202 or separate from the transmitter 202 and either co-located with the transmitter 202 or located in the vicinity of the transmitter 202 (e.g., within a threshold amount of distance).

[0079] By way of example in FIG. 12, the mobile device 104 may include a network interface 27 for exchanging information with the server 102 via the network 106 (e.g., a wired and/or a wireless interface port, an antenna, and RF front end components known in the art or otherwise disclosed herein); one or more processor(s) 22; memory/data source 23 for providing storage and retrieval of information and/or program instructions; atmospheric sensor(s) 24 (including the barometric pressure sensor 112) for measuring environmental conditions (e.g., pressure, temperature, other) at the mobile device 104; other sensor(s) 25 for measuring other conditions (e.g., compass, accelerometer and inertial sensors for measuring movement and orientation); a user interface 26 (e.g., display, keyboard, microphone, speaker, other) for permitting the user of the mobile device 104 to provide inputs and receive outputs; and any other components known to one of ordinary skill in the art. A GNSS interface and processing unit (not shown) are contemplated, which may be integrated with other components or a standalone antenna, RF front end, and processors dedicated to receiving and processing GNSS signaling. The memory/data source 23 may include memory storing data and software modules with executable instructions, including a signal processing module, a signal-based position estimate module, a pressure-based altitude module, a movement determination module, the data packet, and modules.

[0080] The processor(s) 22 may perform different actions by executing the instructions from the modules, including: (i) performance of part or all of the methods, processes and techniques as described herein or otherwise understood by one of ordinary skill in the art as being performable at the mobile device 104; (ii) estimation of an altitude of the mobile device 104 (based on measurements of pressure from the mobile device 104 and transmitter(s) 202, temperature measurement(s) from the transmitter(s) 202 or another source, and any other information needed for the computation); (iii) processing of received signals to determine position information or location data (e.g., times of arrival or travel time of the signals, pseudoranges between the mobile device 104 and transmitters 202, transmitter atmospheric conditions, transmitter and/or locations or other transmitter information); (iv) use of position information to compute an estimated position of the mobile device 104; (v) determination of movement based on measurements from inertial sensors of the mobile device 104; (vi) GNSS signal processing; (vii) assembling and transmitting the device data packet 118; (viii) storing the device data packet 118; (ix) calibrating the barometric pressure sensor 112; and/or (x) other processing as required by operations described in this disclosure.

[0081] By way of example in FIG. 12, the server 102 may include: a network interface 31 for exchanging information with the mobile device 104 and other sources of data via the network 106 (e.g., a wired and/or a wireless interface port, an antenna, or other); one or more processor(s) 32; memory/data source 33 for providing storage and retrieval of information and/or program instructions; and any other components known to one of ordinary skill in the art. The memory/data source 33 may include memory storing software modules with executable instructions, a signal-based positioning module, a pressure-based altitude module, as well as other modules for each of the above-described methods and processes or portions/ steps thereof.

[0082] The processor(s) 32 may perform different actions by executing instructions from the modules, including: (i) performance of part or all of the methods, processes, and techniques as described herein or otherwise understood by one of ordinary skill in the art as being performable at the server 102; (ii) estimation of an altitude of the mobile device 104; (iii) computation of an estimated position of the mobile device 104; or (iv) other processing as required by operations or processes described in this disclosure. Steps performed by servers 102 as described herein may also be performed on other machines that are remote from the mobile device 104, including computers of enterprises or any other suitable machine.

[0083] Reference has been made to embodiments of the disclosed invention. Each example has been provided by way of explanation of the present technology, not as a limitation of the present technology. In fact, while the specification has been described in detail with respect to specific embodiments of the invention, it will be appreciated that those skilled in the art, upon attaining an understanding of the foregoing, may readily conceive of alterations to, variations of, and equivalents to these embodiments. For instance, features illustrated or described as part of one embodiment may be used with another embodiment to yield a still further embodiment. Thus, it is intended that the present subject matter covers all such modifications and variations within the scope of the appended claims and their equivalents. These and other modifications and variations to the present invention may be practiced by those of ordinary skill in the art, without departing from the scope of the present invention, which is more particularly set forth in the appended claims. Furthermore, those of ordinary skill in the art will appreciate that the foregoing description is by way of example only and is not intended to limit the invention.