FIG. 13 illustrates an exemplary method in accordance with one or more embodiments of processing the data that has been placed in queue by the Device API shown in FIG. 12. After the data has been Queued, the First-In-First-Out (FIFO) approach is implemented and scalability will be executed depending on the latency of the last queued message. As the latency increases, more resources are allocated to process 1302 the queued data in parallel. Once the device message is retrieved 1304 from the queue, another function also retrieves the last stored message for that particular device from cache 1308. In order to minimize cellular data usage, duplicate data from device are ignored and only data that changed from the previous message are sent to cloud. This reduces data charges and creates a de-duplication algorithm from which the device operates in. In order to support this approach to data de-duplication, the API receiving the data requires an additional function 1310, which compares the received message with the last cached message. The new data from the comparison then is saved in place of the last cached message. After this step, the data is extracted 1320 into multiple fields using a JSON parser or a delimiter parser depending on the data format used during transmission, and each field will be stored in its appropriate data table 1340 1338 1328 1326 1324 1322 1344. Prior to storing the data on tables, all external APIs are called to extracted further data, such as street address and mapping points 1312 from longitude and latitude data received from the device's GPS/GNSS. Another external API that is the cellular based location API (such as Combain, UnwiredLabs, OpenCellID, and/or others) 1314 is called to obtain an approximate location based on the Local Area Code (LAC), Mobile Network Code (MNC), Mobile Country Code (MCC), and CellID information obtained from base-stations near the device, providing additional information on the location of the device if there is no GPS availability. In addition to data related APIs, other APIs 1316 could also be called to further enrich the raw data received from the device. Another example of additional APIs would be temperature, humidity, and pressure related API. Based on raw location data, outside temperature, pressure, and humidity can be obtained using an external API (such as Accuweather, Weather.Com, and/or others) and that data can be stored for future or immediate correlative comparison to determine whether the device is outdoors or indoors. In addition, device connectivity management APIs 1342 are also utilized to observe connectivity session times, data usage, network carrier information, and others. These data points are then combined and stored into multiple tables. Raw data from the device is stored in a raw data table 1340. Spectrum monitoring data is stored in a separate table 1338, and all the environmental data are stored in table 1326. An additional aggregation function is also performed on the environmental data in order to improve the performance and reduce latency at the end user application as shown in FIG. 20. This aggregated data is then stored in multiple tables 1336 for various time steps. The same also occurs for the Inertial Measurement Unit (IMU) data 1328 1334, location and speed data 1324 1332, network characteristics data 1322 1330, connectivity related data 1344 1346, motion detection data and other data that goes into processing queue.