Privacy filtering of distributed traffic sign inferences

Abstract

The present disclosure relates to a computer-implemented method for processing and storing traffic sign inferences at the cloud server. It involves receiving a traffic sign inference from an edge device, which includes details such as the type, subtype, value, orientation, and location of the traffic sign. The cloud server maps the inference to a way or road ID based on the location, and determines if it meets predefined quality configurations. If met, the cloud server evaluates the number of similar sign detections on the same way ID, considering road coverage thresholds. The decision to store the inference, based on historical data, leads to the creation of a cluster for training a machine learning model.

Description

PRIVACY FILTERING OF DISTRIBUTED TRAFFIC SIGN INFERENCESCross-Reference to Related Applications[0001.1] This application claims the benefit of priority to IN Provisional Application No. 202411083190, filed October 30, 2024, the entirety of which is incorporated by reference herein.Technical Field

[0001] The present disclosure is generally related to distributed edge computing systems for real-time object detection and data transmission optimization, and more specifically, to the methods and systems for privacy-preserving sampling of traffic sign inference data generated by vehicle-mounted edge devices.Background

[0002] In recent years, advancements in edge computing and machine learning have enabled the development of systems that can detect and recognize traffic signs in real-time. These systems typically involve edge devices installed in vehicles that capture images of the road and use machine learning algorithms to identify traffic signs. The detection data is then transmitted to a central server for further processing and use.

[0003] One of the challenges with such systems at scale relates to handling the large volume of detection data generated in real-time while maintaining data quality, ensuring comprehensive road coverage, and preserving privacy.

[0004] Furthermore, given the dynamic nature of traffic and road conditions, the same traffic sign may be detected by multiple devices at different times of the day. This leads to a need for a mechanism to decide which detections to store and transmit, to avoid unnecessary duplication of data and optimize the use of storage space and bandwidth.Summary

[0005] The present disclosure provides methods and systems for privacy-preserving processing of traffic sign inferences in distributed detection networks. In one embodiment, a computer-implemented method comprises receiving traffic sign inferences at a server from edge devices installed in vehicles, wherein each inference includes detection data associated with detected traffic signs. The server associates each inference with a road segment identifierbased on vehicle’s location information and evaluates the inference against quality criteria before determining transmission disposition.

[0006] According to various embodiments, the detection data comprises sign type identifiers, sign subtype identifiers, sign values where applicable, the vehicles bearing at the time of detection, and the vehicle’s GPS coordinates when the sign was detected. The quality criteria evaluation encompasses multiple validation parameters including GPS accuracy thresholds, confidence score requirements, and device status verification. In one example implementation, the server requires vehicle’s GPS accuracy within 15 meters, confidence scores exceeding 0.85, and confirmation of proper edge device operational status.

[0007] In certain embodiments, the method implements a filtering function based on historical data associated with road segment identifiers to generate transmission decisions. The filtering function comprises a historical frequency function that analyzes temporal distribution patterns of previous inferences and generates probability values for receiving future inferences at specific times of day. The transmission decision results from comparing calculated probability values against dynamic thresholds that adapt based on system parameters.

[0008] According to another embodiment, the historical frequency function segregates historical data across multiple temporal dimensions including day / night periods, weekday / weekend patterns, and seasonal variations. The segregated analysis enables adaptation to traffic pattern variations while maintaining consistent privacy protection across different temporal contexts.

[0009] In some embodiments, the method maintains transmission counters tracking previously transmitted inferences for identical traffic signs at specific road segments within defined time periods. When transmission counts exceed predefined limits, the system bypasses the filtering function to enforce hard constraints on maximum daily transmissions. The transmission limits vary based on road type classifications, with one example implementing five transmissions per day for expressways, three for urban roads, and two for residential segments.

[0010] Various embodiments implement selective transmission mechanisms that distribute inferences temporally across different time periods and vary source edge devices for consecutive transmissions. This distribution prevents reconstruction of vehicle trajectories from transmitted inference sequences by ensuring that the vehicle location data associated with consecutive sign detection cannot be correlated. In one implementation, the probability of consecutive transmissions from a single edge device remains below 20% for adjacent traffic signs on the same road segment.

[0011] According to certain embodiments, the server receives configuration parameters from recipient systems specifying requirements including sign types of interest, geographic regions, and temporal preferences. These parameters enable dynamic adjustment of filtering criteria based on mapping service provider requirements while maintaining privacy preservation constraints.

[0012] In some embodiments, the method stores all received inferences regardless of transmission decisions, maintaining comprehensive datasets for machine learning model training. The storage architecture separates real-time transmission decisions from persistent data retention, enabling subsequent analysis and model refinement using complete inference populations.

[0013] Various embodiments incorporate asynchronous clustering operations that aggregate stored inferences into spatial-temporal clusters. Each cluster represents multiple detections of identical physical signs within geographic radius thresholds, typically 15-20 meters, and temporal windows, typically 24 hours. The clustering facilitates quality validation sampling without impacting real-time processing latency.

[0014] In certain embodiments, the system implements validation pipelines utilizing large language models for automated quality assessment. The validation process involves selecting cluster subsets based on sampling criteria, requesting supplemental data including video footage from contributing edge devices, and extracting frames corresponding to detection moments for LLM-based verification.

[0015] According to one embodiment, the LLM validation comprises submitting extracted video frames with expected detection parameters and receiving validation responses indicating agreement or discrepancy between detected and actual sign content. The validation results enable calculation of accuracy metrics, identification of systematic detection errors, and generation of feedback for edge device model refinement.

[0016] In various embodiments, the validation pipeline operates parallel to real-time processing, sampling between 0.01% and 5% of processed inferences for quality verification. The validation outcomes inform dynamic adjustment of quality criteria thresholds and filtering function parameters, creating continuous improvement loops while maintaining system responsiveness.

[0017] The disclosed methods achieve privacy preservation through mathematical constraints on transmission patterns while maintaining data utility for recipient systems. The multi-layered approach combining quality filtering, transmission limits, and probabilistic selection based onhistorical patterns prevents vehicle tracking while ensuring comprehensive geographic coverage and temporal currency of transmitted data.Brief Description of Figures

[0018] Non-limiting embodiments of the present disclosure are described by way of example with reference to the accompanying figures, which are schematic and are not intended to be drawn to scale. Unless indicated as representing the background art, the figures represent aspects of the disclosure. For purposes of clarity, not every component may be labeled in every drawing.

[0019] FIG. 1 illustrates an environment depicting one or more edge devices in communication with a cloud server, according to an embodiment of the disclosure.

[0020] FIG. 2 illustrates a block diagram of an edge device, according to an embodiment of the disclosure.

[0021] FIG. 3 illustrates a block diagram of a cloud server, according to an embodiment of the disclosure.

[0022] FIG. 4 illustrates a process flow for privacy sampling at the cloud server, according to an embodiment of the disclosure.

[0023] FIG. 5 illustrates a historical frequency function, according to an embodiment of the disclosure.

[0024] FIG. 6 illustrates Privacy Preservation Mechanism, according to an embodiment of the disclosure.

[0025] FIGS. 7A-7G illustrate sampling of detected traffic sign inferences in real-time, according to an embodiment of the disclosure.Detailed Description

[0026] The detailed description set forth below, in connection with the appended drawings, is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid obscuring such concepts.

[0027] Based on the teachings, one skilled in the art should appreciate that the scope of the disclosure is intended to cover any aspect of the disclosure, whether implementedindependently of or combined with any other aspect of the disclosure. For example, an apparatus may be implemented, or a method may be practiced using any number of the aspects set forth. In addition, the scope of the disclosure is intended to cover such an apparatus or method practiced using other structure, functionality, or structure and functionality in addition to or other than the various aspects of the disclosure set forth. Any aspect of the disclosure disclosed may be embodied by one or more elements of a claim.

[0028] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.

[0029] Although particular aspects are described herein, many variations and permutations of these aspects fall within the scope of the disclosure. Although some benefits and advantages of the preferred aspects are mentioned, the scope of the disclosure is not intended to be limited to particular benefits, uses or objectives. Rather, aspects of the disclosure are intended to be broadly applicable to different technologies, and system configurations, some of which are illustrated by way of example in the figures and in the following description of the preferred aspects. The detailed description and drawings are merely illustrative of the disclosure rather than limiting, the scope of the disclosure being defined by the appended claims and equivalents thereof.

[0030] Modem vehicles equipped with advanced driver assistance systems may continuously generate vast amounts of data about their surroundings, particularly regarding traffic infrastructure such as road signs. These vehicles employ edge computing devices with cameras and artificial intelligence to detect and identify traffic signs in real-time, creating valuable information for navigation and mapping services. However, sharing this continuous stream of detection data could create a significant privacy vulnerability. When a vehicle travels along a route detecting multiple traffic signs in sequence, each detection contains timestamp and location information that, when transmitted together, may reveal the exact path, speed, and timing of that specific vehicle's journey. Such data may enable anyone receiving the data to track individual vehicles, potentially exposing personal travel patterns, home and work locations, and daily routines.

[0031] The present disclosure addresses this privacy challenge through a filtering mechanism that maintains the utility of traffic sign detection data while preventing vehicle tracking. The system operates on a fundamental principle of selective transmission, wherein not every detected traffic sign results in data being sent to external mapping services (or more generally, downstream applications). Instead, the system implements multiple layers of intelligentselection to determine which detections should be transmitted and which should be stored locally without external sharing.

[0032] In operation, when an edge device in a vehicle detects a traffic sign, it generates an inference containing information about the sign type, the vehicle’s location at the time of sign detection, confidence level, and other relevant parameters including the orientation of the vehicle when the sign was detected. This inference is sent to a cloud server that serves as the central decision point for all connected vehicles. According to certain aspects of the present disclosure, the cloud server first evaluates the quality of the detection, checking factors such as GPS accuracy and the confidence score from the artificial intelligence model. Only high- quality detections proceed to the next evaluation stage, ensuring that any transmitted data meets reliability standards.

[0033] The privacy preservation mechanism employs a historical frequency function that analyzes patterns of previous detections for the same traffic sign at the same location. This function considers the specific road segment, the history of recent detections and transmissions, and optionally other factors such as time of day, to calculate a probability value. For instance, if a particular stop sign on a residential street has already been reported twice today, the system might determine that additional reports have low probability of transmission, even if the detection quality is perfect. This probabilistic approach ensures that transmissions are distributed across different times and different vehicles, making it impossible to link sequential detections from the same vehicle.

[0034] In various embodiments, the system may implement road-type-specific transmission limits that reflect the different privacy considerations across various environments. Highways with dense traffic might allow up to five transmissions per day for the same sign, as the high volume of vehicles provides natural anonymity. Urban roads might permit three daily transmissions, while quiet residential streets might allow only two, recognizing that lower traffic volumes increase the risk of individual vehicle identification. In addition to the probabilistic approach, these limits create hard constraints that prevent excessive reporting regardless of other factors.

[0035] The privacy-enhancing selective transmission mechanism involves distributing transmissions across different vehicles. When multiple vehicles detect the same sequence of traffic signs along a route, the system ensures that different vehicles contribute different pieces of the overall picture. One vehicle might report the speed limit sign, another might report the stop sign, and a third might report the no parking sign, even though all three vehicles detectedall three signs. This distribution (sourcing inferences across different vehicles) prevents any single vehicle's complete route from being reconstructed from the transmitted data.

[0036] A temporal distribution strategy may add another layer of privacy protection by spreading transmissions across different time periods. Even if the same vehicle regularly travels the same route, the system varies which detections get transmitted on different days and at different times. This temporal randomization prevents patterns from emerging that could be used to identify regular commuters or frequent travelers on specific routes.

[0037] While implementing these privacy protections, the system may maintain comprehensive data storage for all detections, regardless of transmission decisions. Every inference, or substantially every inference, whether transmitted or not, may be stored in the cloud server's database. This complete or substantially complete dataset serves multiple purposes: training and improving the artificial intelligence models, validating detection accuracy through sampling of low confidence detections that are not transmitted, and maintaining full coverage for internal analytics. The separation between storage and transmission ensures that privacy protection doesn't compromise the system's ability to learn and improve from accumulated data.

[0038] The system architecture may further include an asynchronous validation mechanism that operates independently of the real-time transmission decisions. Stored detections are periodically grouped into clusters, each cluster representing GPS locations of multiple observations of the same physical sign. These clusters may undergo quality validation using advanced techniques, including large language model analysis of captured images corresponding to cluster points, to verify detection accuracy. This validation process provides feedback for improving the edge device models while operating entirely on the stored data and without affecting privacy-filtered transmissions of inferences.

[0039] For example, a commuter driving the same route daily generates dozens of traffic sign detections during each trip. Without privacy filtering, these repeated detections could create a pattern revealing the driver's home location, workplace, departure times, and route preferences. With the described filtering mechanism, the transmitted data might include only a few randomly selected detections from different days, mixed with detections from numerous other vehicles, making it impossible to reconstruct any individual's travel pattern while still providing mapping services with accurate, current information about traffic sign locations.

[0040] In various embodiments, an edge device is installed in vehicles to monitor the driving behavior of a driver. The driving behavior is characterized by processing data generated by various sensors included in the edge device. The edge device may include one or more camerasto capture visual data. The edge device may include machine learning models to identify objects in the captured visual data. The objects may include traffic signs, other vehicles, lanes of the road, and the like. The edge device communicates information about inferences to a cloud server that processes the inferences. Each inference includes the vehicle’s GPS coordinates at the moment of detection and the vehicle's bearing, providing precise spatial- temporal context for the detected sign. The cloud server may receive multiple inferences with respect to the same traffic sign. In order to manage the storage efficiently, only a sampling of inferences may be stored based on processing of the inferences in real-time at the cloud server.

[0041] The cloud server may map a traffic sign inference to a road ID / way ID based on the GPS coordinates of the vehicle at time of detection. Upon mapping the traffic sign inference to a way ID, the cloud server may determine whether there is an existing traffic sign inference that was already processed for the same sign. This determination may be performed by comparing the GPS coordinates of the two or more traffic sign inferences received. The cloud server may check the number of traffic sign inferences received for the same traffic sign. If the number of traffic sign inferences is less than a sign detection threshold, the newly received traffic sign may be processed for privacy sampling. In privacy sampling, the traffic sign inferences received in real-time may be filtered such that vehicles involved in capturing traffic signs are difficult to track.

[0042] In one embodiment, a predefined limit may be set on the number of traffic sign inferences for the same sign that can be sent to a downstream application, such as a mapping service provider, within a single day (or other appropriate time window). This limit may be determined based on the type of road where the traffic sign is detected. For example, if a traffic sign is detected near an expressway, a maximum of five inferences of the same sign may be transmitted to the provider in one day. The cloud server may skip further inferences of the same sign for the rest of the day once this limit is reached. The cloud server may deliver sufficient and accurate data to the customer for map updates while preserving vehicle privacy. Furthermore, the cloud server may effectively manage the volume of data transmitted, particularly in high-traffic areas like expressways where increased detections are expected. The predefined limit can be adjusted as per the needs of the mapping service provider , considering factors such as traffic volume and significance of the sign.

[0043] The cloud server then evaluates the volume of inferences stored for an identical traffic sign on the same road, identifiable by a unique Way ID and time of day. Based on this historical data, the cloud server generates a historical function, which may be a probability distribution function, machine learning model, or any other suitable predictive algorithm. As part of thecloud server’s data management and privacy protection protocol, the traffic sign inferences of the same sign sent to the customer may be distributed across different times of the day. This distribution is guided by the historical function, which is based on the history of inferences received for that particular road sign for day / night.

[0044] The cloud server ensures that the inferences sent to the mapping service provider are diverse and do not follow a predictable pattern that may be used to track a vehicle’s movement. By distributing the inferences from the same sign across different times of the day, the cloud server prevents the possibility of a mapping service provider, or other downstream application, being able to track a vehicle by analyzing consecutive days of data, thereby maintaining the accuracy and relevancy of the data but also enhances the privacy protection of the vehicle’s data.

[0045] The generated historical function is then utilized to determine whether to retain or discard the current inference. If the function predicts a high probability of receiving additional inferences for the same traffic sign at the specific Way ID and time of day, the cloud server may discard the current inference to optimize storage space and uphold privacy standards. Conversely, if the probability is low, the cloud server may choose to store the current inference for future use.

[0046] The historical function is a crucial part of the data management process. It is configured to keep track of the number of sign inferences that the cloud server has received for a particular road over a specified period (e.g., recent months, during day or night).

[0047] The historical function can help in determining the frequency of a particular sign’s appearance in the edge device pool, which can be useful in making decisions about whether to skip or stream a sign inference. For instance, if the historical function indicates that a certain sign inference is frequently detected on a particular road, the cloud server may decide to skip some of these inferences to avoid storing the redundant data.

[0048] Moreover, the historical function may also be time-dependent, and a method or system in accordance with the present disclosure factors in the time (of day, of week, of year) when making these decisions. This adds another layer of granularity to the data filtering process, allowing for more precise and efficient data management.

[0049] Finally, the cloud server transmits selected inferences to the mapping service provider in real-time. This ensures timely and accurate updates for their map databases, crucial for various applications such as navigation services, autonomous driving systems, and traffic management systems.

[0050] Further, to uphold privacy standards, the cloud server restricts the number of inferences per sign sent to the mapping service provider. Certain inferences of identical signs are selectively skipped or streamed to the provider based on the historical frequency of inferences received for that road at a specific time of day. This prevents the mapping service provider from tracing a vehicle’s path based on the timestamps of the inferences, ensuring the preservation of user privacy.

[0051] In one embodiment, the cloud server may provide real-time updates about road conditions (such as weather) and / or traffic signs. Application of certain aspects of the present disclosure to road conditions may be especially useful for fleet management applications or in the context of autonomous driving. Rather than detecting traffic signs, detections of weather and road conditions such as rain, snow, ice, fog, and the like, may be analyzed and subject to privacy filtering. In a dynamic road condition context, inference and image recency may be more valuable relative to regular signage. Accordingly, certain aspects of the present disclosure may enable low latency transmission of weather / road condition inferences while protecting the privacy of individual drivers.

[0052] Further, information about objects may be used to create a map or update an existing map. The information about inferences of traffic signs and other objects is stored in a database to train or improve the accuracy of machine learning models. Furthermore, information about inferences can be provided to the mapping service provider to keep their maps up to date with real-time data. However, to maintain privacy while providing the data to the mapping service provider, the cloud server may sample the inferences received in real-time based on the quality of the inferences and historical frequency. A path can be traversed by a vehicle for multiple days. The same vehicle can detect the traffic sign on that path for all the days. However, sending the traffic sign inferences for all the days without any filtration can lead to tracking that vehicle. Therefore, traffic sign inferences are sampled in real-time based on historical frequency to safeguard the privacy of the vehicle.

[0053] FIG. 1 depicts an illustration of an environment 100 in which one or more embodiments of the present disclosure may be implemented. The environment 100 includes a cloud server 102, vehicles 104, 106, and a network 108 for communication between the cloud server and edge devices 104a, 106a installed in the vehicles 104, 106.

[0054] The network 108 can be radio access networks such as GSM, LTE, 5G or the like. In one embodiment, the network can be Wi-Fi or other wireless broadband networks.

[0055] The cloud server 102 provides configuration settings and software related services to the edge devices. The cloud server may store the data received from the edge devices. Further,the cloud server may send inference data upon receiving queries from a user and / or as per an established transmission protocol.

[0056] In one embodiment, each edge device 104a, 106a may be an advanced driver assistance system (ADAS) that includes one or more cameras and sensors. Further, each edge device 104a, 106a may include a processor and communication circuitry that includes radio interfaces and antennas. The radio interfaces may correspond to a plurality of radio access technologies including one or more of GSM, NB-IoT, LTE, 5G, WLAN, Bluetooth, BT-LE, NFC, radio frequency identifier (RFID), ultra-wideband (UWB), and the like. Each edge device 104a, 106a is installed in a vehicle 104, 106, respectively, to monitor driver behavior, which may include capturing a cabin of the vehicle with a driver-facing camera and includes capturing a driving (or parking) environment of the vehicle with other sensors and / or a forward-facing camera. Further, each edge device 104a, 106a may include an audio speaker or other output devices to provide notifications and alerts to the driver, or may be connected to devices, such as a driver’s smartphone, that may be used to convey generated alert notifications to the driver. Each edge device 104a, 106a may be a standalone device or a combination of devices.

[0057] The mapping service provider 110 is an organization that offers online or digital mapping services. These services often include features such as satellite imagery, street maps, route planning, and location tracking. The mapping service provider 110 may request cloud server 102 for provision of real-time traffic sign inferences to update their maps.

[0058] FIG. 2 depicts a block diagram of the edge device 200 (similar to edge devices 104a, 106a) including various components. The edge device 200 includes a processor 202, a communication module 204, input / output (I / O) module 206, memory 208, a camera module 210 and a sensor module 212. In one embodiment, the edge device 200 may not include a camera module 210 and in those scenarios, the camera module 210 may be connected to edge device 200 through wired or wireless connection. The edge device 200 may include input sensors (which may include a forward-facing camera, a driver facing camera, connections to other cameras that are not physically mounted to the device, inertial sensors, car OBD-II port sensor data (which may be obtained through a Bluetooth connection), and the like) and compute capability. The compute capability may be a CPU or an integrated System-on-a-chip (SOC), which may include a CPU and other specialized compute cores, such as a graphics processor (GPU), gesture recognition processor, and the like. In some embodiments, the edge device 200 for determining, transmitting, and / or providing alerts to an operator of a vehicle and / or a device of a remote driver monitoring system may include wireless communication to cloud services, such as with Long Term Evolution (LTE) or Bluetooth communication to other devices nearby.For example, the cloud server 102 may provide real-time analytics assistance. In an embodiment involving cloud services, the cloud server 102 may facilitate aggregation and processing of data for offline analytics. The edge device 200 may also include a global positioning system (GPS) either as a separate module or integrated within a system-on-a-chip (e.g., included in sensor module 212).

[0059] The camera module 210 may include an outward facing camera to capture visual data related to the environment ahead of the vehicle, and optionally include an inward facing camera to capture visual data related to the cabin of the vehicle, respectively. The outward facing camera is configured to capture visual data related to the environment around the vehicle and the visual data is relayed to the processor 202.

[0060] The processor 202 may process the captured visual data using machine learning (ML) models deployed on the edge device 200. The ML models may include image classifiers to classify objects captured in the visual data. The ML models may be configured to identify traffic signs in the captured visual data. The processor 202 may generate a traffic sign inference including type, sub class, value, orientation of the vehicle and location of the vehicle, upon detection of traffic sign in the visual data. The communication module 204 may send the traffic sign inference to the cloud server 102.

[0061] The cloud server 102 may receive traffic sign inferences from edge devices installed in the vehicles. The cloud server 102 may process the traffic sign inferences to verify the accuracy and quality of the traffic sign inferences. The cloud server 102 may receive traffic sign inferences related to the same sign from multiple vehicles. In one embodiment, the cloud server 102 may determine whether to store a traffic sign inference or not store the traffic sign inference in a database associated with the cloud server. In another embodiment, the cloud server 102 may determine whether to skip or stream the traffic sign inference to a mapping service provider.

[0062] In one embodiment, the combined system of cloud server 102 and edge devices 104a, 106a may facilitate real-time detection of traffic signs and secure data transmission, while preserving user privacy. The system employs edge computing devices, which are integrated into vehicles. These devices are equipped with imaging sensors and global positioning systems (GPS) to capture visual data of surrounding environments.

[0063] Upon identification of a traffic sign, the edge devices may generate inferences, which include key data such as the type (and subtype of the sign if applicable), the depicted value (e.g., speed limit), the timestamp of the detection, GPS coordinates of the vehicle at the timeof detection, and the vehicle's bearing indicating the direction of travel when the sign was detected. This data may be subsequently transmitted to a cloud server in real-time.

[0064] In one embodiment, the cloud server may receive a request from a mapping service provider to provide traffic sign inference data. The request may include sign types, region of interest (ROI), time of the day. The cloud server may process the traffic sign inferences prior to sending them to the mapping service provider to maintain the privacy of the vehicles capturing these traffic sign inferences. The traffic sign inferences may have to be sent in realtime to keep the maps accurate and relevant in real-time.

[0065] FIG. 3 illustrates a block diagram of a cloud server architecture 300 according to an embodiment of the present disclosure. The cloud server 300 comprises a plurality of interconnected modules configured to process traffic sign inferences received from distributed edge devices while implementing privacy-preserving transmission mechanisms and quality validation protocols.

[0066] In an embodiment, the cloud server 300 includes an inference reception module 302 that is configured to receive real-time traffic sign inference data streams from a plurality of edge devices installed in vehicles traversing a road network. Each received inference comprises detection data including one or more of, but not limited to, sign type identifiers, sign subtype identifiers, sign values where applicable, vehicle bearing parameters at the time of detection, GPS coordinates of the vehicle when the sign was detected, timestamp information, confidence scores, and device identifiers. The inference reception module 302 implements concurrent stream processing to handle multiple simultaneous data transmissions while maintaining temporal ordering of received inferences.

[0067] A road segment mapping module 304 is communicatively coupled to the inference reception module 302. The road segment mapping module 304 performs spatial indexing operations to convert vehicle’s GPS coordinates associated with each traffic sign inference into corresponding road segment identifiers, also referred to as way identifiers or way IDs. In one embodiment, the road segment mapping module 304 utilizes a spatial database comprising preindexed road network geometries to achieve 0(1) lookup performance for vehicle location-to- way-ID conversion operations.

[0068] The cloud server 300 further comprises a quality validation module 306 configured to evaluate each received traffic sign inference against predetermined quality criteria. The quality validation module 306 implements a multi-criteria assessment framework comprising GPS accuracy verification, confidence score threshold evaluation, and device status validation. In one embodiment, the quality validation module 306 rejects inferences exhibiting GPS accuracydegradation beyond 15 meters, confidence scores below 0.85, or originating from edge devices tagged with installation or orientation issues.

[0069] The cloud server 300 performs quality filtering to validate the accuracy and reliability of the traffic sign inferences. Upon receipt of the traffic sign inferences, the cloud server may verify the vehicle’s GPS accuracy by evaluating the precision of the vehicle’s position when matched to a road ID. The cloud server may check object detection and classification confidence of the traffic sign inference. The edge device may send a confidence value of the inference along with key data including the vehicle’s location and bearing associated with traffic sign inference. The confidence value may indicate the confidence of the machine learning model in classification of an object in the visual data. The cloud server may group traffic sign inferences with low confidence values for improving and recalibrating the machine learning models. The traffic sign inferences that have GPS accuracy greater than a GPS threshold and confidence value greater than a confidence threshold will be further processed prior to storing in a database or streaming to a mapping service provider. Further, the cloud server may determine whether the edge device from which a traffic sign inference is received is tagged with any label related to its installation in the vehicle. For example, the cloud server may determine that an edge device is tagged with an orientation issue. The cloud server may skip the traffic sign inference if the edge device is tagged with any label that indicates faulty installation, orientation issues, etc.

[0070] A historical database 308 stores temporal patterns, road segment indices, and transmission history data for all (or substantially all) processed inferences. The historical database 308 maintains indexed records organized by road segment identifiers and temporal parameters, enabling rapid retrieval of historical inference patterns for specific road segments. In certain embodiments, the historical database 308 implements a time-series data structure optimized for temporal pattern analysis across multiple granularities including hourly, daily, weekly, and seasonal variations.

[0071] In one embodimetn, the privacy filtering engine 310 of the cloud server 300, implements the privacy-preserving transmission decision mechanism. The privacy filtering engine 310 comprises three sub-modules: a frequency function processor 310a, a transmission counter 310b, and a decision generator 310c. The frequency function processor 310a retrieves historical data from the historical database 308 and generates a time-dependent probability distribution representing the likelihood of receiving future inferences for a specific traffic sign at a given road segment during particular time periods. The transmission counter 310b maintains real-time counts of transmitted inferences for each unique traffic sign per roadsegment, implementing road-type-specific thresholds wherein expressway segments permit up to five transmissions per day, urban segments permit three transmissions per day, and residential segments permit two transmissions per day.

[0072] The decision generator 310c within the privacy filtering engine 310 synthesizes outputs from the frequency function processor 310a and transmission counter 310b to generate a binary transmission decision for each inference. In one embodiment, the decision generator 310c determines whether to transmit the traffic sign inference to a mapping service provider through a transmission module 312. In another embodiment, which may be implemented alternatively or concurrently, the decision generator 310c determines whether to store the inference exclusively in a storage module 314 without external transmission. These embodiments are not mutually exclusive; the system may implement both decision pathways wherein all (or substantially all) inferences are stored in the storage module 314 while only selected inferences satisfying privacy preservation criteria are transmitted via the transmission module 312.

[0073] The transmission module 312 implements selective streaming protocols for transmitting approved traffic sign inferences to one or more mapping service providers. The transmission module 312 maintains API interfaces configured to accommodate mapping provider-specific (downstream application specific) data formats and transmission protocols while ensuring privacy filtering of transmitted inferences to prevent pattern-based vehicle tracking.

[0074] The storage module 314 provides persistent storage for all received traffic sign inferences regardless of or without transmission decisions. In the illustrated embodiment, the storage module 314 maintains comprehensive inference records including both transmitted and non-transmitted inferences, thereby preserving complete datasets for subsequent machine learning model training and system performance analysis.

[0075] A clustering module 316 operates asynchronously from the real-time processing pipeline, aggregating stored traffic sign inferences into spatial-temporal clusters. Each cluster generated by the clustering module 316 represents multiple detections of an identical physical traffic sign within a predefined geographic radius, typically 15-20 meters, and temporal window, typically 24 hours. The clustering module 316 facilitates quality validation sampling and statistical analysis of detection patterns without impacting real-time inference processing latency.

[0076] The cloud server 300 includes a validation module 318 configured to interface with external validation systems including large language models (LLMs) for automated quality assessment. The validation module 318 receives extracted video frames corresponding tosampled traffic sign detections and submits these frames along with expected detection parameters to LLM-based validation services. The validation module 318 processes validation responses to generate accuracy metrics, identify systematic detection errors, and provide feedback for edge device machine learning model refinement.

[0077] An ML model training module 320 implements feedback loops utilizing both stored inference data and validation results from the validation module 318. The ML model training module 320 generates updated model parameters for deployment to edge devices, enabling continuous improvement of detection accuracy based on accumulated real-world inference data and validation outcomes.

[0078] A configuration interface 322 provides parameter management capabilities for the cloud server 300. The configuration interface 322 receives and processes configuration parameters from mapping service providers specifying requirements including sign types of interest, geographic regions of interest, temporal filtering preferences, and data format specifications. The configuration interface 322 propagates these parameters to relevant modules within the cloud server 300, enabling dynamic adjustment of filtering criteria and transmission protocols based on provider-specific requirements.

[0079] In one embodiment, the cloud server 300 implements a multi-stage processing pipeline where each received inference traverses the inference reception module 302, road segment mapping module 304, and quality validation module 306 in sequence. Upon successful quality validation, the privacy filtering engine 310 determines transmission disposition based on historical patterns and current transmission counts. The architecture of the cloud server 300 enables independent scaling of processing components while maintaining data consistency across the distributed processing pipeline.

[0080] The cloud server architecture 300 achieves privacy preservation through temporal and spatial distribution of transmitted inferences while maintaining comprehensive data storage for internal uses such as system optimization. The separation of real-time processing modules from asynchronous analysis modules ensures minimal latency for transmission decisions while enabling validation and training operations without impacting system responsiveness.

[0081] FIG. 4 illustrates a privacy filtering process flow 400 executed by the cloud server for determining transmission disposition of traffic sign inferences according to an embodiment of the present disclosure. The process flow 400 implements a multi-stage decision pipeline incorporating quality validation, transmission count verification, and historical frequencybased filtering to achieve privacy-preserving selective transmission.

[0082] At step 402, the cloud server receives a traffic sign inference from an edge device through the inference reception module. The received inference comprises detection data including sign type identifier, sign subtype identifier, sign value where applicable, vehicle bearing at detection time, vehicle GPS coordinates when the sign was detected, timestamp, confidence score, and device identifier. In certain embodiments, step 402 implements buffered reception wherein multiple inferences are queued for sequential processing while maintaining temporal ordering based on detection timestamps.

[0083] At step 404, the cloud server maps the received traffic sign inference to a road segment identifier based on the vehicle’s GPS coordinates contained within the detection data. The mapping operation utilizes a spatial indexing algorithm to convert vehicle’s latitude-longitude coordinates at detection time to a unique way identifier or road identifier corresponding to the specific road segment where the traffic sign was detected. In one embodiment, step 404 employs a pre-computed spatial database containing road network geometries indexed using R-tree structures to achieve sub-millisecond mapping performance.

[0084] Decision step 406 represents a quality criteria evaluation gateway where the cloud server determines whether the traffic sign inference satisfies predetermined quality thresholds. The quality criteria evaluation encompasses three primary validation components: vehicle’s GPS accuracy verification, confidence score assessment, and device status validation. In one embodiment, the quality criteria require vehicle’s GPS accuracy within 15 meters, confidence score exceeding 0.85, and absence of device operational issues.

[0085] The quality criteria comprise parameters for the evaluation performed at decision step 406. For example, the GPS accuracy threshold of less than 15 meters ensures spatial precision sufficient for accurate sign localization. The confidence score threshold greater than 0.85 filters inferences with high uncertainty from the edge device machine learning models. The device status validation confirms the originating edge device is not tagged with installation issues, orientation problems, or other operational anomalies that could compromise inference reliability.

[0086] When the quality criteria evaluation at decision step 406 yields a negative determination, the process flow 400 proceeds to step 408, where the cloud server stores the inference exclusively in the storage module without transmission to external systems. Step 410 represents a data preservation path ensuring all received inferences, including those failing quality validation, are retained for subsequent analysis, model training, or system diagnostics. In certain embodiments, step 408 additionally tags stored inferences with quality failure codes indicating specific criteria violations.

[0087] When the quality criteria evaluation at decision step 406 yields a positive determination, the process flow 400 advances to step 410, where the cloud server checks the daily transmission count for the specific traffic sign at the identified road segment. Step 410 queries the transmission counter to determine how many inferences for the identical sign at the same road segment have been transmitted to the mapping service provider within the current 24-hour period.

[0088] At step 412, the cloud server evaluates whether the current transmission count remains below the applicable threshold for the road segment type. The transmission count comparison considers road-type-specific limits wherein different road classifications permit varying numbers of daily transmissions for the same sign. In one embodiment, the thresholds are dynamically adjusted based on traffic density patterns and mapping provider requirements.

[0089] For example, the road-type-dependent transmission limits can be: a five-transmissions- per-day limit reflecting higher traffic volumes and increased sign detection frequency for expressway segments, a three-transmissions-per-day limit balancing data coverage with privacy preservation for urban road segments, and a two-transmissions-per-day limit providing maximum privacy protection in low-traffic areas for residential segments.

[0090] When the transmission count evaluation at decision step 412 indicates the daily limit has been reached, the process flow 400 proceeds directly to step 408 for storage without transmission. This path ensures strict adherence to daily transmission limits regardless of inference quality or temporal distribution, providing a hard constraint on maximum daily transmissions per sign.

[0091] When the transmission count evaluation at decision step 412 confirms available transmission capacity, the process flow 400 continues to step 414 wherein the cloud server applies the historical frequency function by retrieving historical inference patterns for the specific road segment from the historical database. The historical frequency function H(t, way id) generates a detection frequency value representing the expected rate of traffic sign detection at the current time of the day for this road segment. The frequency value, expressed in detections per hour, quantifies the temporal density of the vehicle traffic detecting a traffic sign.

[0092] The historical frequency function applied at step 414 is mathematically expressed as H(t, way id) = E[detections | hour of day, road segment, historical data], wherein the function calculates the expected detection rate based on accumulated historical patterns. The cloud server then applies an inverse transformation to derive the transmission probability: P(transmit) = fA(-l)(H(t, way id)), establishing an inverse relationship between detectionfrequency and transmission likelihood. In exemplary embodiments, this inverse function ensures that high-frequency periods (e.g., 80-100 detections / hour) yield low transmission probabilities (e.g., 0.1-0.2), while low-frequency periods (e.g., 10-20 detections / hour) yield high transmission probabilities (e.g., 0.8-0.9).

[0093] At step 416, the cloud server determines transmission decision by applying the inverse probability function to the calculated frequency value. When the historical frequency H(t, way id) exceeds a threshold (indicating dense traffic), the resulting transmission probability decreases proportionally, reducing the likelihood of transmission to protect vehicle privacy during high-traffic periods. Conversely, when H(t, way id) falls below the threshold (indicating sparse traffic), the transmission probability increases, ensuring adequate data coverage during low-detection periods. The binary transmission decision results from comparing this inverse probability against a minimum transmission threshold.

[0094] When decision step 416 generates a positive transmission decision, the process flow 400 proceeds to step 418, where the cloud server transmits the traffic sign inference to the mapping service provider. Step 418 implements the actual data transmission using providerspecific protocols and formats while logging the transmission event for count tracking and audit purposes. Following transmission, the inference is stored in the database and the transmission history is updated to reflect the completed transmission.

[0095] When decision step 418 generates a negative transmission decision, the process flow 400 bypasses transmission and proceeds to step 420, where the cloud server stores the inference and updates the historical database. Step 420 ensures all inferences, regardless of transmission decision, contribute to the historical patterns used by future frequency function calculations. The storage operation at step 420 maintains complete inference records including metadata indicating whether transmission occurred, enabling subsequent analysis of filtering effectiveness and privacy preservation metrics.

[0096] The illustrated process flow 400 implements privacy preservation through systematic distribution of transmission decisions across temporal and vehicular dimensions. By combining hard constraints (quality criteria and daily limits) with probabilistic filtering (historical frequency function), the process achieves privacy protection while maintaining sufficient data transmission for mapping service requirements. The multi-stage architecture ensures each inference undergoes comprehensive evaluation before transmission, preventing trajectory reconstruction while preserving data utility. The above method may ensure that the data shared with the mapping service provider is accurate, relevant, and does not overwhelm the customerwith excessive inferences of the same sign. It also helps to maintain the privacy of the drivers by not sending data from the same vehicle if it travels on the same path for consecutive days.

[0097] FIG. 5 illustrates a graphical representation of a historical frequency function 500 employed by the privacy filtering engine for implementing privacy-preserving transmission control according to an embodiment of the present disclosure. The historical frequency function 500 quantifies the temporal distribution of traffic sign detections along specific road segments, wherein the detection frequency inversely determines the transmission likelihood to downstream applications such as mapping service providers or fleet management applications. In various embodiments, each traffic sign inference comprises detection parameters including the sign type, sub-type, displayed value, the vehicle’s orientation (bearing) at the time of detection, and the vehicle’s geographic coordinates when the sign was detected.

[0098] The graphical representation 500 comprises a coordinate system wherein the horizontal axis represents time of day measured in hours from 0 to 24, and the vertical axis represents historical detection frequency measured in detections per hour, ranging from 0 to 100 detections. Grid lines are provided at three-hour intervals along the horizontal axis and 25- detection increments along the vertical axis to facilitate visual interpretation of the frequency distribution. In exemplary embodiments, the detection frequency represents aggregated historical data from multiple vehicles traversing the same road segment, thereby establishing baseline patterns for privacy-preserving sampling decisions.

[0099] A continuous curve labeled as element 500 depicts the historical frequency function H(t, way id) calculated from aggregated historical inference data for a representative road segment. The curve exhibits characteristic temporal variations wherein detection frequency reaches minimum values during nighttime periods (0-6 hours) at approximately 10-15 detections per hour, increases progressively through morning commute hours (6-9 hours) to approximately 40-50 detections per hour, achieves maximum values during midday periods (10-14 hours) at approximately 80-100 detections per hour, and subsequently decreases through evening hours returning toward baseline nighttime values. In certain embodiments, the function H(t, way id) incorporates seasonal variations, day-of-week patterns, and special event adjustments to refine the frequency predictions.

[0100] A horizontal threshold line is positioned at the 50 detections per hour level, representing a frequency threshold that inversely influences transmission decisions through the privacy filtering mechanism. The threshold line is depicted using a dashed pattern with 10-unit dash and 5-unit gap sequences to distinguish it from the continuous frequency curve 500. In various embodiments, when the historical frequency exceeds this threshold, the system implementsaggressive privacy filtering by reducing transmission likelihood, thereby preventing potential vehicle tracking through temporal correlation of consecutive detections. Conversely, when the frequency falls below the threshold, the system increases transmission likelihood to ensure adequate map coverage during periods of sparse detection.

[0101] The graphical representation 500 includes a plurality of sample inference points illustrating the inverse relationship between detection frequency and transmission decisions. Filled circular markers represent transmitted inferences, predominantly appearing during low- frequency periods when H(t, way id) falls below the threshold, indicating that the privacy risk is minimal due to sparse traffic. Open circular markers represent skipped inferences, predominantly appearing during high-frequency periods when H(t, way id) exceeds the threshold, indicating heightened privacy protection requirements due to dense traffic patterns. In exemplary implementations, this inverse relationship ensures that vehicles traveling during high-traffic periods cannot be tracked through consecutive day patterns while maintaining sufficient data transmission during low-traffic periods for map accuracy.

[0102] The function H(t, way id) is defined as the expected detection rate E[detections | hour of day, road segment, historical data], wherein the rate calculation incorporates multiple factors including: the specific hour within a 24-hour cycle, the unique road segment identifier (way id), accumulated historical inference patterns for that road segment over configurable time windows (e.g., 30-day, 90-day periods), and road classification parameters (e.g., highway, arterial, residential). The transmission decision implements an inverse probability function P(transmit) = fA(-l)(H(t, way id)), wherein higher detection frequencies yield lower transmission probabilities. In certain embodiments, the transmission criteria require both the inverse probability exceeding a minimum threshold and the daily transmission count for the specific sign remaining below the road-type-specific limit, thereby implementing duallayer privacy protection through temporal distribution and volume limitation.

[0103] In various embodiments, the privacy filtering mechanism addresses the distinction between sign location and vehicle location at detection time. The system records the vehicle’s GPS coordinates at the moment of sign detection rather than attempting to estimate the physical sign location, as the vehicle position provides more reliable and privacy-relevant data for the filtering algorithm. Similarly, the recorded orientation parameter represents the vehicle’s bearing (compass heading) at the detection moment, which enables the system to differentiate between signs detected while traveling in opposite directions on the same road segment. This vehicle-centric data collection approach ensures consistent and verifiable location parameters while maintaining the privacy objectives of the filtering system.

[0104] FIG. 6 illustrates a comparative analysis 600 of traffic sign inference transmission patterns with and without privacy filtering mechanisms according to embodiments of the present disclosure. FIG. 6 demonstrates the vulnerability of unfiltered transmission systems to trajectory reconstruction attacks and the efficacy of the disclosed privacy preservation mechanisms in preventing vehicle tracking.

[0105] Section A of FIG. 6 illustrates transmission patterns in a system operating without privacy filtering. A timeline spans from time T1 to time T5, representing sequential temporal positions during a vehicle’s traversal of a road segment. Vehicle A generates and transmits inferences for Sign 1 through Sign 5 at corresponding temporal positions T1 through T5, with each transmitted inference containing the vehicle’s position and bearing at each detection moment, represented by a filled circular marker positioned at the respective temporal coordinates.

[0106] A continuous trajectory line connects the sequential inference points, visually demonstrating the re-constructable path of Vehicle A based on the transmitted inference sequence. The result indicator demonstrates ‘VEHICLE TRAJECTORY EXPOSED’ with the explanatory notation that sequential detections enable tracking. This vulnerability arises because consecutive transmissions from a single vehicle create a temporal-spatial signature that may be unique to that vehicle's movement pattern.

[0107] Section B of FIG. 6 illustrates transmission patterns in a system implementing the disclosed privacy filtering mechanisms with inverse frequency-based selection. The privacy preservation operates on the principle that high detection frequency periods are largely unaffected by reduced transmission rate, while low frequency periods permit higher transmission rates for coverage in accordance with the benefit of transmitting low latency inference or other data at these times. Multiple vehicles contribute to the transmission of inferences for the same set of traffic signs, with transmission decisions inversely correlated to the temporal detection density at each sign location.

[0108] The distributed transmission pattern demonstrates the inverse relationship in practice: during high-frequency detection periods when many vehicles pass through, the system reduces transmission probability, resulting in most detections being stored but not transmitted. During low-frequency periods with sparse traffic, the system increases transmission probability to ensure coverage. .

[0109] The illustrated privacy preservation mechanism 600 demonstrates quantifiable privacy protection through systematic distribution of transmissions across multiple vehicles. The mechanism achieves k-anonymity where k > 5 in the example illustrated, ensuring each vehicleremains indistinguishable from at least four other vehicles within any road segment transmission pattern, thereby preventing correlation-based tracking while maintaining data utility for mapping service requirements.

[0110] FIGS. 7A-7G illustrate a temporal sequence of traffic sign detection scenarios demonstrating the privacy-preserving transmission mechanism in operation according to an embodiment of the present disclosure. The figures depict an aerial view of a highway segment 700 with traffic sign 702 positioned adjacent to the roadway, showing progressive detection and transmission patterns over sequential time periods.

[0111] FIG.7A depicts the initial state at time TO wherein the traffic sign 702 is positioned on the right side of a multi-lane highway segment. The highway comprises northbound and southbound lanes separated by a median barrier, with the traffic sign 702 oriented to face northbound traffic. At this initial temporal position, no vehicles have yet traversed the detection zone associated with traffic sign 702.

[0112] FIG. 7B illustrates the detection scenario at time T1 wherein a first vehicle equipped with an edge device traverses the highway segment and detects traffic sign 702. A detection marker 704 appears at the vehicle’s position when it detected the traffic sign 702, indicating the generation of a traffic sign inference by the vehicle’s edge device. The inference generated at marker 704 undergoes quality validation and privacy filtering evaluation at the cloud server. In this instance, the historical frequency function indicates low historical frequency at this time period with the inverse probability function yielding a high transmission likelihood and transmission count criteria result in transmission of this first inference to the mapping service provider, represented by the filled detection marker 704.

[0113] FIG. 7C depicts the detection scenario at time T2 wherein additional vehicles have traversed the highway segment. Multiple detection events occur as indicated by detection markers 704 and 706. The marker 704 represents a previously transmitted inference from time Tl, while marker 706 indicates a new detection by a different vehicle at a different position. The cloud server evaluates the inference associated with marker 706 against the privacy filtering criteria. Due to temporal proximity to the previous transmission and / or current transmission count status, this inference is stored but not transmitted, as indicated by the open circle representation of marker 706.

[0114] FIG. 7D illustrates the accumulation of detection events at time T3, showing the progressive build-up of both transmitted and non-transmitted inferences. The detection pattern demonstrates markers 704 representing transmitted inferences and markers 706 representing stored but non-transmitted inferences, each marked indicating where a vehicle was positionedwhen it detected the traffic sign 702. The spatial distribution of markers illustrates how multiple vehicles detect the same traffic sign 702 from different positions while traversing the highway segment, with the privacy filtering mechanism selectively determining which inferences are transmitted to prevent vehicle tracking.

[0115] FIG. 7E depicts the detection scenario at time T4 during a high-traffic period wherein the accumulated markers demonstrate the inverse frequency principle in operation. The high density of vehicle detections during this period triggers the inverse relationship mechanism, causing the historical frequency function H(t, way id) to indicate high detection rates (e.g., 70+ detections / hour). Consequently, the transmission probability decreases significantly, resulting in more vehicle position markers 706 being stored but not transmitted (open circles), while only occasional detections 704 are transmitted (filled circles) to maintain minimum coverage requirements.

[0116] FIG. 7F illustrates the detection scenario at time T5 showing continued accumulation of detection events with maintained privacy preservation. The pattern of markers demonstrates how the historical frequency function influences transmission decisions based on temporal factors and accumulated transmission history. The distribution achieves a balance between data utility and privacy protection, with transmitted inferences providing sufficient coverage while preventing pattern-based vehicle identification.

[0117] FIG. 7G depicts the final state at time T6 representing a complete detection cycle for the highway segment. The comprehensive pattern of detection markers 704 and 706 illustrates that during high-frequency detection periods (when many vehicles detected the sign), fewer transmissions occurred (more open markers 706), while during low-frequency periods, more transmissions occurred (more filled markers 704). This inverse relationship between detection frequency and transmission probability ensures that high-traffic periods don’t enable vehicle tracking through dense sequential position data, while low-traffic periods maintain adequate coverage through higher transmission rates. The filled markers 704 show transmitted inferences including vehicle locations distributed across different temporal positions and likely originating from different vehicles, while open markers 706 represent the stored inference population that maintains complete detection history without external exposure.

[0118] The progression illustrated in FIGS. 7A-7G demonstrates the practical implementation of the privacy-preserving transmission mechanism over a representative time period. The selective transmission pattern, as evidenced by the distribution of filled markers 704 versus open markers 706, achieves the dual objectives of providing real-time traffic sign data to mapping service providers while preventing the correlation of sequential vehicle positions thatwould enable vehicle tracking. The temporal spacing and selective transmission ensure that even with multiple vehicles detecting the same sign 702, the transmitted data pattern remains sufficiently distributed to maintain k-anonymity across the detection population.Map creation and management

[0119] Traffic sign inferences may provide vital information about the road network, including the location and type of traffic signs, the speed limit of certain roads, and other rules (such as no U-turn or stop signs). This data may be used by the cloud server 102 to create a detailed and accurate digital map that reflects the real-world road network. The roads and traffic rules change over time, and these changes are often reflected in the traffic signs. By continuously collecting and analyzing traffic sign inferences, the cloud server may regularly update the digital maps with the changes. For example, if a new stop sign is detected, or the speed limit on a road changes, these updates can be immediately reflected on the map by the cloud server upon receiving real-time traffic sign inferences.

[0120] Further, the cloud server may verify the traffic sign inferences based on the accuracy of the GPS data collected along with traffic sign inferences and improve the accuracy of the digital maps. For example, if the GPS data associated with a certain traffic sign doesn’t match with the current map, the discrepancy may be scrutinized, and the map can be updated accordingly.

[0121] The maps created with information from traffic sign inferences may enhance the navigation features of the maps. By knowing the exact locations and types of traffic signs, the map may provide more accurate and context-aware navigation instructions to the users.

[0122] A computer program product may include a non-transitory computer-readable medium having instructions stored thereon, the instructions being executable by one or more processors configured to carry out any of the systems and / or methods described herein.

[0123] The various illustrative logical blocks, modules, 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 illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of this disclosure or the claims.

[0124] Embodiments implemented in computer software may be implemented in software, firmware, middleware, microcode, hardware description languages, or any combination thereof. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc., may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0125] The actual software code or specialized control hardware used to implement these systems and methods does not limit the claimed features or this disclosure. Thus, the operation and behavior of the systems and methods were described without reference to the specific software code being understood that software and control hardware can be designed to implement the systems and methods based on the description herein.

[0126] When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in a processor executable software module, which may reside on a computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable media includes both computer storage media and tangible storage media that facilitate transfer of a computer program from one place to another. A non-transitory processor-readable storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such non-transitory processor-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storage medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer or processor. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable medium and / or computer-readable medium, which may be incorporated into a computer program product.

[0127] The operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[0128] The terms “data processing apparatus”, “data processing system”, “client device”, “client computing device”, “computing platform”, “computing device”, “computing system”, “user device”, or “device” can encompass all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing. The apparatus can include special purpose logic circuitry, e.g., an FPGA or an ASIC. The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them.

[0129] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0130] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory or both. The elements of a computer include a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or videoplayer, a game console, a GPS receiver, a digital camera device, a video camera device, or a portable storage device (e.g., a universal serial bus (USB) flash drive), for example. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0131] To provide for interaction with a user, implementations of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube), plasma, or LCD monitor, for displaying information to the user; a keyboard; and a pointing device, e.g., a mouse, a trackball, or a touchscreen, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can include any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user.

[0132] In certain circumstances, multitasking and parallel processing systems may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. For example, the computing devices described herein can each be a single module, a logic device having one or more processing modules, one or more servers, or an embedded computing device.

[0133] Having now described some illustrative implementations and implementations, it is apparent that the foregoing is illustrative and not limiting, having been presented by way of example. In particular, although many of the examples presented herein involve specific combinations of method acts or system elements, those acts and those elements may be combined in other ways to accomplish the same objectives. Acts, elements, and features discussed only in connection with one implementation are not intended to be excluded from a similar role in other implementations or implementations.

[0134] The phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” “having,” “containing,” “involving,” “characterized by,” “characterized in that,” and variations thereof herein, is meant to encompass the items listed thereafter, equivalents thereof, and additional items, as well as alternate implementations consisting of the items listed thereafter exclusively.In one implementation, the systems and methods described herein consist of one, each combination of more than one, or all of the described elements, acts, or components.

[0135] Any references to implementations or elements or acts of the systems and methods herein referred to in the singular may also embrace implementations including a plurality of these elements, and any references in plural to any implementation or element or act herein may also embrace implementations including only a single element. References in the singular or plural form are not intended to limit the presently disclosed systems or methods, their components, acts, or elements to single or plural configurations. References to any act or element being based on any information, act, or element may include implementations where the act or element is based at least in part on any information, act, or element.

[0136] Any implementation disclosed herein may be combined with any other implementation, and references to “an implementation,” “some implementations,” “an alternate implementation,” “various implementation,” “one implementation,” or the like are not necessarily mutually exclusive and are intended to indicate that a particular feature, structure, or characteristic described in connection with the implementation may be included in at least one implementation. Such terms as used herein are not necessarily all referring to the same implementation. Any implementation may be combined with any other implementation, inclusively or exclusively, in any manner consistent with the aspects and implementations disclosed herein.

[0137] References to “or” may be construed as inclusive so that any terms described using “or” may indicate any of a single, more than one, and all of the described terms.

[0138] Where technical features in the drawings, detailed description or any claim are followed by reference signs, the reference signs have been included for the sole purpose of increasing the intelligibility of the drawings, detailed description, and claims. Accordingly, neither the reference signs nor their absence have any limiting effect on the scope of any claim elements.

[0139] The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the embodiments described herein and variations thereof. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the principles defined herein may be applied to other embodiments without departing from the spirit or scope of the subject matter disclosed herein. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

[0140] While various aspects and embodiments have been disclosed, other aspects and embodiments are contemplated. The various aspects and embodiments disclosed are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims

Claims

AMENDED CLAIMS received by the International Bureau on 07 May 2026 (07.05.2026)1. A computer-implemented method for processing traffic sign inferences in a distributed detection system, the method comprising: receiving, at a server, a traffic sign inference from an edge device installed in a vehicle, wherein the traffic sign inference comprises detection data associated with a detected traffic sign and location information identifying a position of the vehicle at a time of detection of the detected traffic sign; associating the traffic sign inference with a road segment identifier based on the location information; evaluating the traffic sign inference based on one or more quality criteria; upon the traffic sign inference satisfying the one or more quality criteria, generating a transmission decision by applying a filtering function to historical data associated with the road segment identifier, wherein applying the filtering function comprises calculating, from the historical data, a transmission probability that decreases with increasing historical detection frequency at the road segment identifier for a current time period, and comparing the transmission probability to a threshold to generate the transmission decision; and in accordance with the transmission decision, transmitting or withholding transmission of the traffic sign inference to a recipient system.

2. The method of claim 1, wherein the detection data comprises: a sign type identifier; a sign subtype identifier; a sign value when applicable to the sign type; a vehicle orientation / bearing at the time of detection; andGPS coordinates of the vehicle at the time of traffic sign detection.

3. The method of claim 1, wherein evaluating the traffic sign inference comprises: verifying GPS accuracy falls within a predefined range; confirming a confidence score exceeds a threshold value; and validating absence of device operational issues.

4. The method of claim 3, further comprising: mapping the GPS coordinates to the road segment identifier; and checking device status tags in a device registry.

5. The method of claim 1, wherein applying the filtering function comprises: analyzing temporal distribution patterns of previous inferences for the road segment identifier; calculating a probability value based on historical inference frequency at a current time period; and comparing the probability value to a threshold to generate the transmission decision.

6. The method of claim 5, further comprising: segregating the historical data by day periods and night periods; categorizing patterns by weekday and weekend occurrences; and adjusting the probability calculation based on the segregated categories.

7. The method of claim 1, further comprising: maintaining a counter of transmitted inferences for each unique traffic sign at the road segment identifier; incrementing the counter upon each transmission; and when the counter exceeds a predefined limit for a current time period, bypassing the filtering function and withholding transmission of the traffic sign inference to the recipient system.

8. The method of claim 7, wherein the method comprises: setting different predefined limits based on road type classifications; applying higher limits for expressway classifications; applying medium limits for urban road classifications; and applying lower limits for residential road classifications.

9. The method of claim 1, wherein selectively transmitting comprises: distributing transmissions temporally across different time periods for inferences of an identical traffic sign; and varying source edge devices for consecutive transmissions of the identical traffic sign.

10. The method of claim 1, further comprising: receiving multiple inferences from different edge devices detecting an identical traffic sign; applying the filtering function to each received inference independently; and maintaining separate transmission histories for each edge device.

11. The method of claim 1, further comprising: receiving configuration parameters from the recipient system specifying sign types of interest, geographic regions of interest, and temporal preferences; and applying the configuration parameters to filter inferences before applying the filtering function.

12. The method of claim 1, wherein applying the filtering function comprises: generating a probability distribution from the historical data; sampling a value from the probability distribution using current temporal parameters; and37determining the transmission decision based on the sampled value.

13. The method of claim 1, wherein selectively transmitting comprises: limiting consecutive transmissions from a single edge device for the road segment identifier within a time window; and adding temporal delays between transmissions from the same edge device.

14. The method of claim 1, further comprising: indexing historical data by road segment identifiers and temporal parameters in a database; calculating updated filtering parameters from accumulated historical patterns; and modifying the filtering function based on the updated parameters.

15. The method of claim 1, further comprising: identifying conflicting sign information from multiple edge devices for an identical location; comparing confidence scores of conflicting inferences; and selecting the inference with highest confidence score for transmission.

16. The method of claim 1, further comprising: storing received traffic sign inferences in a database, including both inferences transmitted to the recipient system and inferences withheld from transmission to the recipient system in accordance with the transmission decision; and maintaining stored inferences for machine learning model training.

17. The method of claim 16, further comprising: aggregating stored traffic sign inferences into spatial-temporal clusters asynchronously from realtime processing; wherein each cluster represents multiple detections of a same physical sign within a geographic radius and time window.

18. The method of claim 17, further comprising: selecting a subset of clusters based on sampling criteria; identifying edge devices that contributed inferences to selected clusters; and transmitting requests for supplemental data to the identified edge devices.

19. The method of claim 18, wherein the supplemental data comprises video footage, the method further comprising: receiving video footage from the edge devices; extracting frames corresponding to detection timestamps; and storing extracted frames with associated cluster identifiers.

20. The method of claim 19, further comprising: submitting an extracted frame to a large language model (LLM) with corresponding detection data;receiving a validation response from the LLM; and storing the validation response with quality metrics.

21. The method of claim 20, wherein submitting to the LLM comprises: transmitting the extracted frame; transmitting an expected sign type and value from the traffic sign inference; transmitting a list of detectable sign types; and transmitting a validation query requesting sign identification.

22. The method of claim 21, further comprising: comparing the LLM validation response with the original traffic sign inference; calculating accuracy metrics from comparisons across multiple clusters; and initiating model retraining when accuracy metrics fall below a threshold.

23. The method of claim 19, further comprising: analyzing multiple frames from video footage to identify optimal frames based on detection confidence scores; selecting frames with highest visibility metrics; and aligning frame timestamps with GPS coordinates.

Images