Patent Description:
Electronic devices may include a variety of sensors and inputs to monitor and infer relative device position. For example, based on input received by a WiFi sensor, a device can measure Received Signal Strength Indication (RSSI) or Round Trip Time (RTT) to infer device position relative to one or more wireless access points. In another example, a Global Navigation Satellite System (GNSS) can be used to determine device position.

Data collection servers may process and redistribute position information collected by electronic devices (e.g., crowd sourcing). However, always on data collection by electronic devices may consume limited device resources while providing data to the data collection server. For example, when the device is a mobile device that uses battery power, data collection can consume some of the limited battery resource of the device as one or more sensors gather data. Furthermore, data reporting out to a collection server can also consume limited wireless bandwidth resources. For example, users may have a data bandwidth cap and may be charged excess usage fees when data use exceeds the cap. Therefore, users may be hesitant to allow their devices to provide unrestricted data reporting to data collection servers.

The cost of data collection can impact data collection servers as well as clients or connected devices. For example, too much traffic to a server can consume a server's bandwidth and excess data may not add value commensurate with the cost of a large unmanaged data flow. Blind data collection can be wasteful and expensive especially when multiplied by many client devices. If the server becomes overwhelmed with connections, incoming and outgoing data may be dropped and the user experience at the device may be negatively impacted. Attention is drawn to <CIT> which relates to a radio node for fingerprinting positioning measurements. The radio node may be configured to provide a fingerprinting measurement result comprising radio channel related information. Examples of radio channel information may be Doppler, speed and/or delay spread information. Example embodiments presented herein may also be directed towards a positioning node for fingerprinting positioning management. The positioning node may be configured to receive radio channel related information from the radio node and generate a radio fingerprint based on the received radio channel related information. Further attention is drawn to <CIT> which describes a wireless mobile communication system having a position determination service and in which base station information is stored in a base station almanac. In addition to the position of the base station antenna, forward link delay calibration, and base station identification information, a base station almanac record includes the center location of the base station sector coverage area, the maximum range of the base station antenna, the terrain average height over the sector coverage area, the terrain height standard deviation over the sector coverage area, round-trip delay calibration information, repeater information, pseudo-random noise increments, uncertainty in the base station antenna position uncertainty in the forward-link delay calibration, and uncertainty in the round-trip delay calibration. Further attention is drawn to <CIT>which relates to a signal-of-opportunity location device (SOLD) that may be situated in a complex radio propagation environment with multiple RF signal obstructions and that receives RF signals from a distant transmitter. The RF signals from the distant transmitter interact with obstructions in the propagation environment local to the SOLD. The local obstructions perturb the RF signals causing the RF signals to exhibit near field behavior in the complex radio propagation environment. The SOLD receives the locally perturbed signals. The SOLD detects signal characteristics of RF signal components of the received signals and compares these signal characteristics with reference data in a reference data store to determine the current location of the SOLD.

In accordance with the present invention, methods, a server and a system, as set forth in the independent claims, are provided. Embodiments of the invention are claimed in the dependent claims.

The following description and related drawings disclose specific embodiments of methods and systems. Alternate embodiments may be devised without departing from the scope of the claims.

Additionally, well-known elements of systems and/or methods may not be described in detail or may be omitted so as not to obscure the relevant details of the disclosure.

Likewise, the term "embodiments" does not require that all embodiments include the discussed feature, advantage or mode of operation.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of embodiments of the disclosure. It will be further understood that the terms "comprises", "comprising", "includes" and/or "including", when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Further, many embodiments are described in terms of sequences of actions to be performed by, for example, elements of a computing device (e.g., a server or device). It will be recognized that various actions described herein can be performed by specific circuits (e.g., application specific integrated circuits), by program instructions being executed by one or more processors, or by a combination of both. Additionally, these sequence of actions described herein can be considered to be embodied entirely within any form of computer readable storage medium having stored therein a corresponding set of computer instructions that upon execution would cause an associated processor to perform the functionality described herein. In addition, for each of the embodiments described herein, the corresponding form of any such embodiments may be described herein as, for example, "logic configured to" perform the described action.

<FIG> is block diagram illustrating an exemplary mobile device. The system may be a device (e.g., the device <NUM>), which may include one or more processors <NUM>, a memory <NUM>, I/O controller <NUM>, and network interface <NUM>. Device <NUM> may also include a number of device sensors coupled to one or more buses or signal lines further coupled to the processor <NUM>. It should be appreciated that device <NUM> may also include a display <NUM>, a user interface (e.g., keyboard, touch-screen, or similar devices), a power device <NUM> (e.g., a battery), as well as other components typically associated with electronic devices. In some embodiments, device <NUM> may be a mobile or non-mobile device.

The device (e.g., device <NUM>) can include sensors such as a clock <NUM>, ambient light sensor (ALS) <NUM>, accelerometer <NUM>, gyroscope <NUM>, magnetometer <NUM>, temperature sensor <NUM>, barometric pressure sensor <NUM>, red-green-blue (RGB) color sensor <NUM>, ultra-violet (UV) sensor <NUM>, UV-A sensor, UV-B sensor, compass, proximity sensor <NUM>, near field communication (NFC) <NUM>, and/or Global Positioning Sensor (GPS) <NUM>. As used herein the microphone <NUM>, camera <NUM>, and/or the wireless subsystem <NUM> (Bluetooth <NUM>, WiFi <NUM>, cellular <NUM>) are also considered sensors used to analyze the environment (e.g., position) of the device. In some embodiments, multiple cameras are integrated or accessible to the device. For example, a mobile device may have at least a front and rear mounted camera. In some embodiments, other sensors may also have multiple installations or versions.

Memory <NUM> may be coupled to processor <NUM> to store instructions for execution by processor <NUM>. In some embodiments, memory <NUM> is non-transitory. Memory <NUM> may also store one or more models or modules to implement embodiments described below. Memory <NUM> may also store data from integrated or external sensors. In addition, memory <NUM> may store application program interfaces (APIs) for accessing the Fine Grain Position Data Collection (FGPDC). In some embodiments, FGPDC functionality can be implemented in memory <NUM>. In other embodiments, FGPDC functionality can be implemented as a module separate from other elements in the device <NUM>. The FGPDC module may be wholly or partially implemented by other elements illustrated in <FIG>, for example in the processor <NUM> and/or memory <NUM>, or in one or more other elements of the device <NUM>. Additional details regarding implementation of FGPDC functionality are described below.

Network interface <NUM> may also be coupled to a number of wireless subsystems <NUM> (e.g., Bluetooth <NUM>, WiFi <NUM>, Cellular <NUM>, or other networks) to transmit and receive data streams through a wireless link to/from a wireless network, or may be a wired interface for direct connection to networks (e.g., the Internet, Ethernet, or other wireless systems). The mobile device may include one or more local area network transceivers connected to one or more antennas. The local area network transceiver comprises suitable devices, hardware, and/or software for communicating with and/or detecting signals to/from WAPs, and/or directly with other wireless devices within a network. In one aspect, the local area network transceiver may comprise a WiFi (<NUM>. 11x) communication system suitable for communicating with one or more wireless access points.

The device <NUM> may also include one or more wide area network transceiver(s) that may be connected to one or more antennas. The wide area network transceiver comprises suitable devices, hardware, and/or software for communicating with and/or detecting signals to/from other wireless devices within a network. In one aspect, the wide area network transceiver may comprise a CDMA communication system suitable for communicating with a CDMA network of wireless base stations; however in other aspects, the wireless communication system may comprise another type of cellular telephony network or femtocells, such as, for example, TDMA, LTE, Advanced LTE, WCDMA, UMTS, <NUM>, or GSM. Additionally, any other type of wireless networking technologies may be used, for example, WiMax (<NUM>), Ultra Wide Band, ZigBee, wireless USB, etc. In conventional digital cellular networks, position location capability can be provided by various time and/or phase measurement techniques. For example, in CDMA networks, one position determination approach used is Advanced Forward Link Trilateration (AFLT). Using AFLT, a server may compute its position from phase measurements of pilot signals transmitted from a plurality of base stations.

Thus, device <NUM> may be a: mobile device, wireless device, cell phone, personal digital assistant, mobile computer, wearable device (e.g., head mounted display, virtual reality glasses, etc.), robot navigation system, tablet, personal computer, laptop computer, or any type of device that has processing capabilities. As used herein, a mobile device may be any portable, or movable device or machine that is configurable to acquire wireless signals transmitted from, and transmit wireless signals to, one or more wireless communication devices or networks. Thus, by way of example but not limitation, the device <NUM> may include a radio device, a cellular telephone device, a computing device, a personal communication system device, or other like movable wireless communication equipped device, appliance, or machine. The term "mobile device" is also intended to include devices which communicate with a personal navigation device, such as by short-range wireless, infrared, wire line connection, or other connection - regardless of whether satellite signal reception, assistance data reception, and/or position-related processing occurs at the device <NUM>. Also, "mobile device" is intended to include all devices, including wireless communication devices, computers, laptops, etc. which are capable of communication with a server, such as via the Internet, WiFi, or other network, and regardless of whether satellite signal reception, assistance data reception, and/or position-related processing occurs at the device, at a server, or at another device associated with the network. Any operable combination of the above are also considered a "mobile device.

The mobile device may communicate wirelessly with a plurality of WAPs using RF signals (e.g., <NUM>, <NUM>, and <NUM>/<NUM> bands) and standardized protocols for the modulation of the RF signals and the exchanging of information packets (e.g., IEEE <NUM>. By extracting different types of information from the exchanged signals, and utilizing the layout of the network (i.e., the network geometry) the mobile device may determine position within a predefined reference coordinate system.

Embodiments as will be hereinafter described may be implemented through the execution of instructions, for example as stored in the memory <NUM> or other element, by processor <NUM> of device and/or other circuitry of device and/or other devices. Particularly, circuitry of device, including but not limited to processor <NUM>, may operate under the control of a program, routine, or the execution of instructions to execute methods or processes in accordance with embodiments of the disclosure. For example, such a program may be implemented in firmware or software (e.g. stored in memory <NUM> and/or other locations) and may be implemented by processors, such as processor <NUM>, and/or other circuitry of device. Further, it should be appreciated that the terms processor, microprocessor, circuitry, controller, etc., may refer to any type of logic or circuitry capable of executing logic, commands, instructions, software, firmware, functionality and the like.

Further, it should be appreciated that some or all of the functions, engines or modules described herein may be performed by device itself and/or some or all of the functions, engines or modules described herein may be performed by another system connected through I/O controller <NUM> or network interface <NUM> (wirelessly or wired) to device. Thus, some and/or all of the functions may be performed by another system and the results or intermediate calculations may be transferred back to device. In some embodiments, such other device may comprise a server (e.g., server <NUM>) configured to process information in real time or near real time. In some embodiments, the other device is configured to predetermine the results, for example based on a known configuration of the device. Further, one or more of the elements illustrated in <FIG> may be omitted from the device <NUM>. For example, one or more of the sensors <NUM>-<NUM> may be omitted in some embodiments.

<FIG> is block diagram illustrating an exemplary server <NUM>. For the sake of simplicity, the various features and functions illustrated in the box diagram of <FIG> are connected together using a common bus meant to represent that these various features and functions are operatively coupled together. Those skilled in the art will recognize that other connections, mechanisms, features, functions, or the like, may be provided and adapted as necessary to operatively couple and configure a data processing system (e.g., server <NUM>). Further, it is also recognized that one or more of the features or functions illustrated may be further subdivided or combined.

The server <NUM> may include a network interface <NUM> configured to communicate with a network (not shown), which may be configured to communicate with other servers, computers, and devices (e.g., device <NUM>).

A processor <NUM> may be connected to the network interface <NUM>, and the memory <NUM>. The processor may include one or more microprocessors, microcontrollers, and/or digital signal processors that provide processing functions, as well as other calculation and control functionality. The memory <NUM> can store data and software instructions for executing programmed functionality within the server. The memory <NUM> may be on-board the processor <NUM> (e.g., within the same IC package), and/or the memory may be external memory to the processor and functionally coupled over a data bus. The details of software functionality associated with aspects of the disclosure will be discussed in more detail below.

A number of software modules or data tables may reside in memory <NUM> and be utilized by the processor <NUM> in order to manage communications, and FGPDC functionality. As illustrated in <FIG>, memory <NUM> may include location database <NUM>, and the FGPDC <NUM>. One should appreciate that the organization of the memory contents as shown in <FIG> is merely exemplary, and as such the functionality of the modules and/or data structures may be combined, separated, and/or be structured in different ways depending upon the implementation of the mobile device. In one embodiment, FGPDC <NUM> may be a process running on the processor <NUM> of the server <NUM>, which provides for enhanced data collection.

The server may optionally store auxiliary position/motion data in memory that may be derived from information received from various sources at the device <NUM> as described below. Moreover, in other embodiments, supplemental information may include, but not be limited to, information that can be derived or based upon Bluetooth signals, beacons, RFID tags, and/or information derived from a map (e.g., receiving coordinates from a digital representation of a geographical map by, for example, a user interacting with a digital map).

Processor <NUM> may include any form of logic suitable for performing at least the techniques provided herein. For example, processor <NUM> may be operatively configurable based on instructions in memory <NUM> to selectively initiate one or more routines that exploit motion data for use in other portions of the mobile device.

The server may include an input/output controller <NUM> to provide any suitable interface systems, such as a microphone/speaker, keypad, and display that allows for local input to the server.

<FIG> is a diagram of an exemplary operating environment for a mobile device <NUM> and server <NUM> performing Fine Grain Position Data Collection. In one embodiment, one or more mobile devices (e.g., devices <NUM>, <NUM>', and <NUM>") can collect position data and upload position data to a server (e.g., server <NUM>). In one embodiment, position data is the data relevant to inferring or determining position or location. Each mobile device can collect position data from one or more of its available device sensors (e.g., ambient light sensor (ALS) <NUM>, accelerometer <NUM>, gyroscope <NUM>, magnetometer <NUM>, temperature sensor <NUM>, barometric pressure sensor <NUM>, red-green-blue (RGB) color sensor <NUM>, ultra-violet (UV) sensor <NUM>, NFC <NUM>, UV-A sensor, UV-B sensor, compass, Bluetooth <NUM>, WiFi <NUM>, cellular <NUM>, proximity sensor <NUM> and/or Global Positioning Sensor (GPS) <NUM>). In some embodiments, the mobile device determines positioning based on communication with one or more Wireless Access Points (e.g., <NUM>, and <NUM>). In some embodiments, the Wireless Access Points may also provide updates or requests for data to the server <NUM>.

The WAPs <NUM> and <NUM> can be part of a Wireless Network (e.g., Wireless Local Area Network, Wide Area Network, etc.), which may operate in buildings and perform communications over a relatively small geographic region compared to a Cellular or Wide Area Network. Such WAPs may be part of, for example, WiFi networks (<NUM>1x). In one embodiment, each WAP may be, for example, a WiFi wireless access point, which is not necessarily set in a fixed position and can change location. In one embodiment, the mobile device position may be determined by having the mobile device receive signals from each WAP. Each signal may be associated with its originating WAP based upon some form of identifying information that may be included in the received signal (such as, for example, a MAC address). The mobile device may then derive the time delays associated with each of the received signals. In one embodiment, the mobile device <NUM> can determine its placement within a building or floor of a building.

In one embodiment, Fine Grain Position Data Collection (FGPDC) makes efficient use of mobile device bandwidth, processing, and power resources when collecting data from one or more mobile devices (e.g., device <NUM>). In one embodiment, the collected data may be position data related to the location of the respective mobile device.

<FIG> is a flow diagram illustrating an exemplary method of Fine Grain Position Data Collection performed a server (e.g., server <NUM>). At block <NUM>, an embodiment (e.g., FGPDC at the server) can receive position data collected by a mobile device with a first positioning configuration. The FGPDC at the server can receive position data from one or more mobile devices, each device having a respective positioning configuration with parameters for one or more mobile device sensors.

For example, device "A" may have WiFi, GPS, two cameras, NFC and Bluetooth. Device "A" may be initially configured to use WiFi to gather position data while the other available sensors remain inactive. Device "B" may be limited to WiFi and one camera sensor, and also may use WiFi to gather position data while the camera remains inactive. Accordingly, the server may initially receive WiFi data from both device "A" and device "B. " Alternatively, the server may receive GPS data from device "A" while camera and WiFi data from device "B" is also sent to the server, or any number of other initial sensor data combinations may used to gather and send data from the device to the server.

At block <NUM>, the embodiment determines, from the position data received at the server, a mobile device position. For example, based on position data that includes WiFi identifiers, RSSI, and RTT, the server may compare the position data to data within a location database accessible by the server (e.g., location database <NUM>). The server may be able to determine the location of the mobile device based on received position data. For example, the server can determine device location if the position data matches Location Data within the location database. Location Data is described in greater detail below. In other embodiments, the server need not determine an exact location of the mobile device to incorporate position data into the location database. For example, the server may determine a user is within a general location, such as within a building, and that data received can be associated with Location Data for the respective building.

At block <NUM>, the embodiment creates a second positioning configuration created according to at least the mobile device position. For example, the server can determine, based on a current device position, that the mobile device is on a particular floor of a specific building and further determine whether additional data collection for the particular floor of the building is needed. In one embodiment, the server may trigger a request for additional data collection is useful based on a number of factors (e.g., a change in received position data from previously collected position data, a request associated with a location, a change in positioning performance of the mobile device, or an amount of time elapsed since a previous position data collection by the server).

Upon determining a need for additional information for the respective location, the server may request additional data collection from the mobile device. For example, while the previous device configuration may be configured for WiFi data, a new configuration may be suggested to the device that includes camera data collection or some other sensor data. The server may determine that additional WiFi data or other additional/new sensor data can build up the server's location database. For example, the server may request device "B" turn on the camera sensor to capture images of the local environment of the mobile device. The images or a representation of the images may be sent to the server for analysis and storage in the location database.

At block <NUM>, the embodiment sends, by the server, the second positioning configuration to the mobile device. In one embodiment, when the server requests additional or customized data collection from a mobile device, the request includes a recommended device configuration for providing position data to the server. For example, the server may request camera images, and provide a recommended mobile device configuration that includes activating the camera sensor of the mobile device, while de-activating WiFi, if sufficient WiFi data has already been collected by the mobile device or by other previous mobile devices.

A device <NUM> utilizing FGPDC functionality can automatically send/receive updates to/from a server. For example, the mobile device sends the server position data collected within the mobile device environment. Based on the position data received and type(s) of data to update in a particular situation, the server can provide mobile devices with an individualized Guideline (e.g., stored within a location database <NUM>) or configuration to optimize data collection for each respective mobile device in a set or crowd of mobile devices. The server can continue to iterate through multiple Guidelines or configurations to apply on each mobile device. For example, upon a first iteration of position data collection, the server may receive sufficient WiFi data collection and send an updated Guideline or configuration to request Bluetooth or NFC position data. At a later point in time, the server may revert back to requesting WiFi data collection based on one or more triggers discussed in greater detail below.

<FIG> is a flow diagram illustrating an exemplary method of Fine Grain Position Data Collection performed at a device (e.g., device <NUM>). At block <NUM>, an embodiment (e.g., FGPDC at a mobile device) collects position data at a mobile device according to a first positioning configuration.

At block <NUM>, the embodiment sends the position data collected according to the first positioning configuration, to a server (e.g., server <NUM>). For example, the device has one or more sensors available for data collection. One or more of the available sensors is configured to collect data in the first positioning configuration. The sensors may be configured to be always on, or alternatively the configuration may specify an interval time period when the sensor may collect data. For example, the first positioning configuration may specify that a device camera sensor can capture an image every <NUM> seconds and send the image to a server for processing. In another example, the device may determine RSSI or RTT from one or more WiFi access points every second and send the data to the server. At block <NUM>, the embodiment receives a second positioning configuration from the server. The mobile device can determine whether to use all or part of the second (recommended) positioning configuration for future data collection. For example, the server may request additional data collection using the mobile device's GPS sensor and camera sensor (or any other sensor configuration). However, the mobile device may accept, refuse, or modify, the suggested data collection configuration. For example, the mobile device can accept the recommended configuration by applying all of the recommended configuration changes (e.g., activate GPS and the camera sensor). The mobile device may also refuse the recommended configuration (e.g., keep GPS and camera sensors deactivated). In some embodiments, the mobile device may keep some aspects of the recommended configuration while applying other aspects of the recommended configuration (e.g., activating GPS while keeping a camera sensor deactivated). User settings or preferences may be one factor in determining whether all or some of a positioning configuration is implemented by the mobile device.

In one embodiment, FGPDC can read device sensor data to determine context or position. For example, a mobile device can create context data, or data related to the environment of the device by polling or extracting data from one or more of the mobile device sensors described above. As one example, the mobile device may receive positioning information from a GPS or from WiFi positioning to determine a location of the device. The mobile device may also read camera images or data from a camera sensor to determine information about the device environment (e.g., whether the device is indoors or whether any detectable landmarks are visible). Using the context data, FGPDC at the mobile device or server, can determine further information about the environment/location. For example, the mobile device may extract longitude and latitude coordinates from the GPS, and determine the coordinates are associated with a specific building or section of a building.

In one embodiment, based on positioning or location information received from each mobile device, the server can create a recommended positioning configuration or Guideline for mobile devices performing future data collections. To create the Guideline, the server may first determine what if any data gaps exist within the location database (e.g., location database <NUM> on the server <NUM>).

In one embodiment, Guidelines may be stored within a location database and can include Location Data and/or recommended data collection configurations. Mobile devices (e.g., device <NUM>) can receive a Guideline from the server. The Guideline may include information to assist the device in providing accurate positioning or localization. For example, within an indoor shopping mall, GPS positioning may be most accurate when the mobile device is positioned near windows or other openings. In this indoor shopping mall example, the FGPDC may send the device a Guideline that can include Location Data to help the device more accurately determine position within the shopping mall such that the mobile device can activate or deactivate one or more sensors as appropriate for the given location. The Location Data may include location specific features, landmarks, or identifiers as described above.

The mobile device can refer to the Guideline to optimize the positioning configuration of the mobile device. For example, if the mobile device receives a Guideline that indicates the mobile device location has few windows or other location features that promote efficient access to communication outside of the current building, the mobile device may automatically turn off GPS or other satellite communication features. If the Guideline indicates the respective location has some windows that may allow for a weak GPS signal, the mobile device may determine a GPS can be polled occasionally (e.g., reduced usage model) instead of being activated continuously (e.g., constant on model). The Guideline may include details to allow the mobile device to determine proximity to a window or open area that may potentially offer more accurate GPS signal reception.

In one embodiment, the positioning configuration or Guideline optimizes the data collection by the server, such that a mobile device can collect data on an as needed basis. The server may send a recommended positioning configuration or Guideline including specific position data collection requests from the mobile device. For example, the server may determine that Location Data for a location has incomplete or partial knowledge about the nearby WiFi access points to the mobile device. Although the mobile device may not necessarily need to collect WiFi data in order to perform user functions (e.g., navigation), the mobile device may nonetheless accept the server recommendations to help update the Location Data on the server (e.g., as part of location database). Therefore, the server may request individualized data collection from a group or "crowd" of mobile devices in order to maintain and update the location database on the server which can include various types of Location Data.

FGPDC (e.g., FGPDC functionality within the server <NUM>) may maintain updated location features/attributes based on crowdsourcing data collection from one or more devices (e.g., mobile devices/devices). For example, as a device navigates an indoor location (e.g., shopping mall) data collected during navigation may be sent to the FGPDC server to update and maintain location features. In one embodiment, the server can use FGPDC functionality in conjunction with one or more mobile devices to crowdsource Location Data. FGPDC can intelligently throttle or adjust the amount or type of subsequent Location Data updates sent by each respective mobile device. In one embodiment, FGPDC can send a recommended configuration or Guideline related to recommended frequency of data collection, which sensors to activate, how often to send updates to the server, or what type of data to collect.

In one embodiment, a mobile device can apply a recommended positioning configuration or Guideline upon determining whether the configuration or Guideline is compatible with the respective device settings. For example, user supplied settings may restrict the use of GPS when battery is low or have privacy settings to limit the use of camera sensors even though the FGPDC (e.g., configuration file sent from the server) may recommend GPS or camera activation.

In some embodiments, a recommended configuration or Guideline from a server also includes Location Data. As used herein, Location Data may include Location Context Identifiers (LCI) or other data related to a physical location. For example, Location Data can include: a map of the location (e.g., including building or floor layout and points of interest), number of known access points, historical data traffic, device activity associated with the position or location, or other known location features.

Location Data may be subdivided into multiple sub-locations such that a user or device can download or access the section of Location Data relevant to a current location. As the user or device moves from one location to another, the Location Data related to the current location may be accessed locally or downloaded from a server. In other embodiments, the server may automatically determine related Location Data that a device may need based on direction of movement or position of the device.

In one embodiment, the Location Data stored at the server (e.g., within the location database) may be determined by a baseline data collection sequence from one or more mobile devices or a pre-seeded database. During one or more initial position data collection sessions by one or more mobile devices, FGPDC at the server may obtain Location Data as described above. Subsequent mobile device data collection received by the server can be used to maintain and keep the location database up to date. For example, upon detecting a mobile device within a respective location, the server may compare incoming data collection at that location to current Location Data on the server. If the Location Data received by the server is more up to date or adds additional Location Data, the location database at the server may be updated. The updated Location data can be used to benefit subsequent mobile device connections when the Location Data is requested by a mobile device.

In one embodiment, FGPDC (e.g., FGPDC functionality on the server) can trigger creation and sending of a recommended configuration to a device when a change in the received position data (e.g., data related to a particular location) is detected. For example, a mobile device may determine three WiFi access points are detected in a location when ten access points are expected based on prior data collection (e.g., stored within the location database at the server). Based on a change in position data indicating the mobile device has position uncertainty, the server can trigger creation of a recommended configuration or Guideline. The server can create a configuration or Guideline to recommend the mobile device to turn on additional sensors or increase the frequency of positioning calculations for subsequent data collections by one or more devices.

In one embodiment, one or more trigger events can cause FGPDC functionality at the server to create and send a recommended configuration or Guideline to a mobile device. In one embodiment, the server may receive a direct request for Location Data associated with of a particular location. For example a location (e.g., venue, shopping mall, or place of business) may change a layout of the building or floors and request an update to Location Data associated with their real world physical space. In one example, the location may have remodeled and walls or rooms that influenced the effectiveness of WiFi positioning may be missing or added since the prior position data collection. Also access points may be added or removed which could change known location features storage at the server. Upon changing the layout or features of a location, access points send out notification directly to the server of an updated connection layout. Alternatively, the location owner or manager may send a request to update position data upon a change in layout of the venue. The FGPDC (e.g., server <NUM>) can send out the updated configuration when a mobile device approaches or enters an updated location.

In one embodiment, upon detecting a change in positioning performance of the device, FGPDC functionality at the server can trigger creation and sending of the recommended configuration or Guideline to a device. Positioning performance may relate to the ability of the mobile device to determine or infer a position or location of the mobile device (e.g., position or location may be relative to a landmark, map coordinates, or other physical space). For example, a user may complain about positioning performance in an application (e.g., a navigation application) on the device which. The poor positioning performance may be reported to the server by the application, or user. Upon receiving notification of potential degradation of positioning performance, the server can create and send a recommended configuration to improve device positioning or location determination. For example, the server may suggest turning on additional sensors to aid device positioning and navigation within the respective location (e.g., a building or floor of a building).

In one embodiment, the server triggers creation and sending of the recommended configuration to a device when a threshold amount of time has elapsed since a previous data collection. For example, the server can determine that Location Data of a particular location is outdated, and request one or more devices to provide updated Location Data. The server can send a recommended configuration or Guideline to collect the updated position data from one or more devices at the respective location outdated coverage.

In one embodiment, the FGPDC recommended configuration or Guideline can be different for each location or venue. For example, FGPDC may have a recommended configuration for a specific shopping mall and a different recommended configuration for a specific office building. Furthermore, different sections of a location may trigger different configurations or Guidelines. For example, the lobby of an office building may have different location features and higher foot traffic than an office space on a higher level of the building. Based on the different features of the respective location, the server can adjust the data collection parameters that are requested or sourced from the devices at the location.

In some embodiments, the FGPDC can determine a recommended configuration for the device according to the available features of the device (e.g., whether the device has Bluetooth, accelerometer, WiFi, or other capability used to determine position or context for the device environment). For example, one device may have Bluetooth and WiFi, while other devices may be lacking WiFi and Bluetooth but have multiple cameras or NFC. Depending on capability, different configuration settings can be sent from the server to the device (as a Guideline or configuration). For example, a GPS enabled device may be able to provide detailed positioning information to the FGPDC server. In another example, if no NFC data has been recorded for a particular location, upon determining a connected device has NFC capabilities, the FGPDC may request the device collect NFC data for the location.

In one embodiment, the FGPDC server determines a level of crowdsourcing based on amount of data collected over a period of time. Depending on the capture time of the most recent position data for a location, the next recommended configuration may be more or less data intensive, or occur earlier or later. For example, after <NUM> months without new or updated position data for a location, the FGPDC may resume requests for data collection at a location.

In one embodiment, when the FGPDC determines a change in positioning performance surpasses a predetermined threshold, a new recommended configuration for one or more devices can be created. For example, the FGPDC may monitor RSSI and RTT calculations for devices at a particular location. Based on changes in measurement of the RSSI and RTT for a location compared to historical levels of RSSI and RTT, the FGPDC can trigger additional or fewer sensors to aid in device positioning.

In alternate embodiments, the FGPDC may adjust the intensity or frequency of data collection for existing sensors based on a change in historical levels of RSSI and RTT. For example, an access point may fail or be removed from a location, resulting in different RSSI and RTT values from previous data collection sessions. The FGPDC may recommend additional data collection from devices based on the change in recorded RSSI and RTT. For example, additional data collection may include additional sensors or increased robustness for existing sensors.

In one embodiment, the server determines frequency of data collection. Data can be collected in any time increment, however the server can balance the need for data with the goal of minimizing the impact on client devices. Data collection may be adjusted by the server based on one or more of: time of day, day of a week, date, currently available position data collection, or time elapsed since a previous data collection. For example, the server may determine that during peak shopping hours, all of the mobile devices at a shopping mall do not need to collect and report positioning data at the same time. The server may determine that a small subset of all available mobile devices could be used to refresh position data at the server.

In one embodiment, the FGPDC can have devices store updated context data in local memory, and the devices send the data from memory to the server when a WiFi connection is available. For example, instead of immediately uploading data at the location (e.g., over a cellular data connection), a device may delay sending data until the device is connected to a network with WiFi. In some embodiments, data uploads may occur when the device is connected to a power source (e.g., charging cable is attached).

In one embodiment, devices connected to the FGPDC server can self configure with an updated configuration. Devices may use some or none of the recommended configurations from the server when implementing a new data collection configuration. For example, FGPDC functionality at the server may request in a recommended configuration, that a device collect GPS data and send to the server. However the device may be low on battery and the device may determine that GPS should remain deactivated until the device battery can be recharged. In some embodiments, the server can receive a battery level (e.g., or any other status) from the device and create a customized recommended configuration according to battery level (or other status) of the particular device.

FGPDC may be implemented as software, firmware, hardware, module, or engine. In one embodiment, the previous FGPDC description may be implemented by one or more general purpose processors (e.g., processor <NUM>) in device <NUM> in memory <NUM> to achieve the previously desired functions (e.g., the method of <FIG>). In one embodiment, the previous FGPDC description may be implemented by one or more general purpose processors (e.g., processor <NUM>) in memory <NUM> of server <NUM> to achieve the previously desired functions (e.g., the method of <FIG>).

The teachings herein may be incorporated into (e.g., implemented within or performed by) a variety of apparatuses (e.g., devices). For example, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone), a personal data assistant, a tablet, a mobile computer, a laptop computer, a tablet, an entertainment device (e.g., a music or video device), a headset (e.g., headphones, an earpiece, etc.), a medical device (e.g., a biometric sensor, a heart rate monitor, a pedometer, an EKG device, etc.), a user I/O device, a computer, a server, a point-of-sale device, an entertainment device, a set-top box, or any other suitable device. These devices may have different power and data requirements and may result in different power profiles generated for each interest point or set of interest points.

In some aspects a wireless device may comprise an access device (e.g., a Wi-Fi access point) for a communication system. Such an access device may provide, for example, connectivity to another network through transceiver <NUM> (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link. Accordingly, the access device may enable another device (e.g., a Wi-Fi station) to access the other network or some other functionality. In addition, it should be appreciated that one or both of the devices may be portable or, in some cases, relatively non-portable.

Those of skill would further appreciate that the various illustrative logical blocks, modules, engines, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, engines, circuits, and steps have been described above generally in terms of their functionality.

An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium.

Claim 1:
A method for crowdsourcing position data collection by a server (<NUM>), the method comprising:
receiving (<NUM>), at the server (<NUM>), first position data collected by a mobile device (<NUM>) using a first set of one or more mobile device sensors of a plurality of mobile device sensors according to a first positioning configuration, the first positioning configuration comprising parameters for the first set of one or more mobile device sensors to determine the first position data;
determining (<NUM>), from the first position data received at the server (<NUM>), a mobile device position;
creating (<NUM>), by the server (<NUM>), according to at least the mobile device position, a second positioning configuration for activating, at the mobile device (<NUM>), a second set of one or more mobile device sensors of the plurality of mobile device sensors to use to collect second position data, the second set of one or more mobile device sensors including at least one different mobile device sensor than the first set of one or more mobile device sensors used to collect the first position data;
sending (<NUM>), by the server (<NUM>), the second positioning configuration to the mobile device (<NUM>); and
receiving, at the server (<NUM>), the second position data collected by the mobile device (<NUM>) using the second set of one or more mobile device sensors according to the second positioning configuration.