KR20230131844A - Method and system for fraud detection reporting management routing - Google Patents

Abstract

Various embodiments of the method, fraud management system, and non-transitory processor-readable medium manage the generation, storage, and transmission of fraud reports from a vehicle-to-everything (V2X) onboard device to an associated entity, such as a fraud management organization. It provides something to do. Various embodiments may include detecting that a fraud condition has occurred and determining whether to generate a fraud report based on the aggregated importance value. The fraud management system may decide whether to store the generated fraud report. The fraud management system may also determine whether to forward the fraud report to a fraud management agency. In some embodiments, the fraud management system may determine which saved fraud reports may be deleted from storage.

Description

Method and system for fraud detection reporting management routing

This application claims the benefit of priority to U.S. Provisional Application No. 63/137,324, entitled “Method and System for Misbehavior Detection Report Management Routing,” filed January 14, 2021, the entire contents of which are hereby incorporated by reference for all purposes. It is incorporated by reference into the specification.

Cellular vehicle-to-everything (C-V2X) protocols serve as the foundation for vehicle-based wireless communications and can be used to support intelligent highways, autonomous and semi-autonomous vehicles, and improve the overall efficiency and safety of highway transportation systems. C-V2X defines two transmission modes that together provide 360° non-line-of-sight awareness and a higher level of predictability for improved road safety and autonomous driving. The first transmission mode includes direct C-V2X, which includes vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-pedestrian (V2P), and is independent of cellular networks. The dedicated ITS 5.9 gigahertz (GHz) spectrum provides improved communication range and reliability. The second transmission mode is third generation wireless mobile communications technologies (3G) (e.g., global system for mobile communications (GSM) evolution (EDGE) systems, Code Division Multiple Access (CDMA) 2000 systems, etc.), fourth generation Wireless mobile communication technologies (4G) (e.g., Long Term Evolution (LTE) systems, LTE-Advanced systems, mobile Worldwide Interoperability for Microwave Access (WiMAX) systems, etc.), fifth generation wireless mobile communication technologies (5G) vehicle-to-network communications (V2N) in mobile broadband systems and technologies such as NR) systems, etc.

IEEE 1609 is a standard under development for vehicle-based communication systems and functions. Part of the system is the ability for vehicles to broadcast basic safety messages (“BSM” in the figures) or cooperative awareness messages (CAMs) that can be received and processed by other vehicles to improve traffic safety. The processing of these messages in the sending and receiving vehicle occurs in on-board equipment that provides V2X functionality (hereinafter referred to as “V2X on-board equipment”).

In V2X communications, it is important to detect inaccurate, damaged, or hacked (i.e. bad) data to prevent such inaccurate data from being further distributed. However, as more and more vehicles are able to participate in these networks, the amount of potential fraud conditions data is large and growing exponentially. Therefore, in order to effectively utilize V2X messaging, management of detected fraud conditions may be controlled. Fraud detection systems are important to perform the function of detecting erroneous data as well as generating misbehavior reports (MBRs). The MBR must be created, stored locally, and transmitted to a trusted third party (e.g., a fraud management agency) for investigation. Therefore, the integrity and functionality of V2X onboard equipment will be an important design consideration when V2X systems are deployed.

Various aspects manage the generation, storage, and transmission of a fraud detection report (MBR in the figures) from a V2X or V2V onboard device to a fraud management authority (MA) after a fraud condition is detected by the V2X or V2V onboard device. Includes ways to do it. Various aspects include determining whether to generate a fraud report to identify the fraud condition based on an aggregated importance value in response to detection of the fraud condition; generating a fraud report identifying the fraud conditions in response to the decision to create a fraud report to identify the fraud conditions; Deciding whether to store the fraud reports generated; and transmitting the generated fraud report to a fraud management agency.

Some aspects may further include determining whether to transmit the generated fraud report to the fraud management organization, wherein transmitting the generated fraud report to the fraud management organization includes transmitting the generated fraud report. It is carried out in response to decisions made.

Some aspects may further include analyzing the sensor data using a machine learning model to determine whether a fraud condition is detected, wherein generating a fraud report identifying the fraud condition includes one or more of the following: It may include generating fraud reports that include: machine learning models; output of the machine learning model; Analysis of key components of machine learning models; Intermediate representation of a machine learning model; Or an identifier for a machine learning model.

Some aspects include classifying detected fraud conditions based on the potential safety impact of the fraud condition or the level of potential traffic congestion; determining the observed length of the cheating condition; determining the number of recurrences of the misconduct condition; or determining the number of neighboring vehicles experiencing the cheating condition, classifying the cheating condition, the observed length of the cheating condition, the number of recurrences of the cheating condition, and the cheating condition. The method may further include generating an aggregated importance value based on one or more of the number of neighboring vehicles experiencing the condition.

Some aspects include determining a level of confidence in detection of a fraud condition that is the subject of a fraud report; or determining whether additional messages from neighboring vehicles accompany reports of misconduct; It may further include one or more of determining whether a network communication link to a fraud management organization is available for transmitting the fraud report, wherein whether to store the generated fraud report to identify fraud conditions. Determining whether to do so depends on one or more of the following: the level of confidence in detection of the fraud condition, the number of additional messages neighboring vehicles may accompany the fraud report, and whether a network communications link to the fraud management agency is available for transmitting the fraud report. It may be based on

Some aspects include categorizing detected fraud conditions that are the subject of a generated fraud report based on the potential safety implications of the fraud condition; Assigning initial weight to fraud reports based on classification of fraud conditions; Assigning an attenuation factor to fraud reports; and multiplying the assigned initial weight by an attenuation factor at regular intervals to determine the determined weight of the fraud report, wherein determining whether to store the fraud report may also include multiplying the assigned initial weight by an attenuation factor to determine the determined weight of the fraud report. Based on weights.

Some aspects include categorizing detected fraud conditions that are the subject of a generated fraud report based on the level of potential traffic congestion; Assigning an initial weight to fraud reports based on classification of fraud conditions; Assigning an attenuation factor to fraud reports; and multiplying the assigned initial weight by an attenuation factor at regular intervals to determine the determined weight of the fraud report, wherein determining whether to store the fraud report may also include multiplying the assigned initial weight by an attenuation factor to determine the determined weight of the fraud report. Based on weights.

Some aspects include determining whether available storage space is below a storage space threshold level; The method may further include performing a flush operation in response to determining that the available storage space is below the storage space threshold level, wherein the flush operation includes the order in which the fraud reports are stored, the classification of the fraud conditions, and the number of duplicates stored. Detect stored fraud reports based on one of the number, and the determined weight of the fraud report.

In some aspects, determining whether to transmit a misconduct report may include classification of the misconduct condition; The order in which fraud reports are stored; Or it may be based on at least one of the fairness rules. Some aspects may further include transmitting the fraud report to a fraud pre-processing entity for pre-processing before being transmitted to the fraud management agency.

Some aspects may further include receiving feedback from a fraud management organization and performing one or more of the following: Generating, in response to the feedback, influencing a decision to generate a fraud report to identify fraud conditions; adjusting parameters; In response to the feedback, it is used to determine the level of confidence in detecting fraud conditions, the number of additional message neighboring vehicles accompanying the fraud report, and whether the network communication link to the fraud management agency will store the generated fraud report. adjusting one or more thresholds for whether a fraud report is available for transmission; or adjusting transmission parameters that affect the decision to transmit a fraud report to a fraud management agency in response to feedback.

Additional aspects include a fraud management system including a processor and memory configured to perform the operations of any of the methods outlined above. Additional aspects may include a fraud management system having various means for performing functions corresponding to any of the methods outlined above. Additional aspects may include a non-transitory processor-readable storage medium having processor-executable instructions stored thereon configured to cause a processor of a fraud management system to perform various operations corresponding to any of the methods outlined above.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the claims and, together with the general description and detailed description given, serve to illustrate the features of the invention.
1 is a system block diagram illustrating a subset of a V2X communication system suitable for implementing various embodiments.
Figure 2 is a component diagram of a fraud management network for managing fraud reports.
3 is a process flow diagram of an example method for managing the generation, storage, and transmission of fraud reports by a fraud management system.
4A and 4B are process flow diagrams of an example method for determining whether to generate a fraud report by a fraud management system.
5A and 5B are process flow diagrams of an example method for determining whether to store a fraud report by a fraud management system.
6 is a process flow diagram of an example method of calculating weights for fraud reports generated by a fraud management system.
7 is a process flow diagram of an example method for determining which stored fraud reports may be detected by a fraud management system.
8 is a process flow diagram of an example method of adjusting thresholds in a feedback signal by a fraud management system.
9 is a component block diagram illustrating an example mobile computing device suitable for use with various embodiments.
10 is a component block diagram illustrating an example mobile computing device suitable for use with various embodiments.
Figure 11 is a component block diagram illustrating an example server suitable for use with various embodiments.

Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or similar parts. References made to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

In the overview, various embodiments provide for fraud reporting (MBR in the diagram) from V2X or V2V onboard equipment following detection of fraud conditions to a management authority, such as a fraud management authority and/or a secure credential management system (SCMS). Includes methods and mechanisms for managing generation, storage, transmission, and preprocessing.

V2X systems and technologies improve traffic flow and vehicle safety by allowing vehicles to share information about location, speed, direction of travel, braking, and other factors that may be useful to other vehicles for collision avoidance and other safety functions. It presents great potential for improvement. Vehicles equipped with V2X/V2V onboard equipment frequently (e.g., up to 20 times per second) transmit vehicle information in packets called Basic Safety Messages (BSMs) or Collaborative Awareness Messages (CAMs). With every V2X-equipped vehicle sending these BSM/CAM messages, every receiving vehicle has the information it needs to control its speed and direction to avoid collisions and efficiently and safely position the vehicles relative to each other. V2X-equipped vehicles are expected to be able to improve traffic flow by safely reducing separation distances, grouping multiple vehicles together, and avoiding vehicle breakdowns.

For ease of reference, some embodiments are described in this application using a fraud management system operating within vehicle-to-everything (V2X) terminology. However, it should be understood that various embodiments include some or all of V2X or vehicle-based communication standards, messages, or technologies. As such, nothing in this application should be construed as limiting the claims to V2X and Basic Safety Message (BSM) unless explicitly stated in the claims. Additionally, embodiments described herein discuss onboard equipment for performing V2X communications. Other embodiments are also contemplated where V2X communications may include mobile devices, mobile computers, and road side units (RSUs) equipped to monitor road and vehicle conditions as well as participate in V2X communications.

To help illustrate the issues addressed by various embodiments, Figure 1 shows a portion of a V2X system 100 that includes three vehicles 12, 14, and 16. Each vehicle (12, 14, 16) is configured to periodically broadcast basic safety messages (112, 114, 116) for reception and processing by the other vehicle's onboard equipment (e.g., 102, 104, 106). Each configuration includes V2X onboard equipment (102, 104, and 106). By sharing vehicle location, speed, direction, braking and other information, vehicles can maintain a safe distance and identify and avoid potential collisions. For example, a following vehicle 12 receiving a basic safety message 114 from a preceding vehicle 16 can determine the speed and position of vehicle 16 so that vehicle 12 can adjust its speed and maintain a safe separation distance of 20. ) makes it possible to maintain. By receiving a notification through the basic safety message 114 when the preceding vehicle 16 applies the brakes, even if the preceding vehicle 16 suddenly stops, the V2X equipment 102 of the following vehicle 12 applies the brakes at the same time. A safe separation distance (20) can be maintained. As another example, the V2X equipment 104 within the truck vehicle 14 receives basic safety messages 112 and 116 from two vehicles 12 and 16 indicating that the truck vehicle 14 should stop at an intersection to avoid a collision. You can receive notifications. Each of the vehicle V2X onboard equipment 102, 104, and 106 can communicate with each other using any of a variety of proximity communication protocols. Additionally, vehicles may be connected to an Original Equipment Manufacturer (OEM) 132, 134 and/or remotely via communication links 122, 124 via a communication network 18 (e.g., cellular, WiFi, etc.). Data and information regarding detected basic safety messages as well as detected fraud reports may be transmitted to the fraud management agency 136. Fraud reports may be transmitted directly to fraud management organization 136 (e.g., via communications link 146). In other embodiments, fraud reports may first be transmitted to a fraud report preprocessing unit, such as an OEM server 132, 134, for preprocessing via communications links 122, 124. The preprocessed fraud report may then be transmitted from the fraud report preprocessing 132 and 134 to the fraud report management agency 136 via communication links 142 and 144.

Given the importance of the primary safety message to the safe operation of surrounding vehicles, care must be taken to ensure that the primary safety message is accurate and reliable for other vehicles. One measure used to ensure trustworthiness is to issue a certificate to each V2X onboard device that can be used to sign basic safety messages. Certificates issued to V2X onboard devices do not contain a permanent ID for the V2X onboard devices, so they are commonly referred to as pseudonym certificates. Fraud management systems operating within the V2X on-board equipment of nearby vehicles and highway monitoring systems of basic safety podcasts can verify the authenticity of the V2X on-board equipment issuing basic safety messages by verifying the signature of the broadcast message. V2X onboard devices that receive the basic safety message can verify the signature using the public key. To prevent hacking or interference with V2X system operations, V2X onboard equipment can be configured to ignore any received basic safety messages that are expired or signed using an invalid certificate.

Although signing default safety messages using certificates issued to V2X onboard devices protects against attempts to inject incorrect default safety messages, the signature verification process prevents incorrect default safety messages from being detected by failed V2X onboard devices using legitimate certificates. It may not be possible to detect when it is created. Various equipment failures can cause V2X onboard equipment to generate incorrect default safety messages. For example, a defect in the navigation sensor, speed sensor, and/or the cables connecting these sensors to the V2X onboard equipment may cause vehicle position (e.g., wrong lane or larger error) or speed to be reported inaccurately. V2X onboard equipment may be maliciously modified to generate incorrect default safety messages that are signed using legitimate certificates. Both cases are referred to as cheating.

In most cases, the receiving fraud management system can detect fraud through fraud detection in onboard processing. Incorrect default safety messages may also be recognized by fraud management systems operating in other vehicles when the information contained in those messages conflicts with trusted information available in the V2X onboard equipment. For example, the fraud management system may recognize that the location information in the received basic safety message is incorrect if the reported location of the reporting vehicle overlaps the location of the vehicle receiving the basic safety message. As another example, a fraud management system may recognize that speed information in a received basic safety message is inaccurate when the speed does not match the speed of the equipment's own vehicle and surrounding vehicles. Other methods can be used to recognize incorrect default safety messages.

To ensure the integrity and reliability of the V2X system, the fraud management system may be configured to notify other vehicle and highway systems or agencies of detected incorrect basic safety messages by sending messages notifying other systems of the detected problem. V2X onboard equipment receiving from existing systems can automatically generate fraud reports (MBR in the drawings) or fraud detection reports. Each fraud report may include a pseudonym certificate from the cheating V2X onboard device that signed an incorrect default safety message. A fraud management system that detects fraud may be configured to transmit the fraud detection report to a specific network backend entity for processing, referred to herein as the Fraud Authority (MA) of the SCMS. Since reporting V2X onboard devices are typically configured by OEMs, fraud reporting catchers are typically operated by or on behalf of the OEM of the reporting V2X onboard devices.

Fraud detection reports may be collected by a fraud agency, which may be a government agency, an independent third-party agency, or an entity operated by various parties such as service providers and/or OEMs. Fraud authorities can be formed to take steps to protect the reliability and integrity of V2X systems and equipment. For example, a fraud agency may add the certificate of a cheating V2X onboard device to a blacklist so that other V2X onboard devices know that they can ignore default safety messages containing the blacklisted certificate. Distributed fraud organizations may also notify certificate registrars of certificates so that appropriate action can be taken by the relevant registrars.

The term cheating V2X on-board device is used herein for the V2X on-board device where fraud occurred in the fraud detection report. However, in some cases, other components or entities, and V2X onboard equipment for which no liability is attributed, may use messages or credentials obtained from that V2X onboard equipment to cheat. For example, a defective sensor or equipment in the same vehicle as the V2X on-board equipment for which responsibility is attributed could cause incorrect information in the primary safety message, resulting in fraud detection, but it is also responsible for sending the incorrect primary safety message. There are other scenarios where there may be entities outside the vehicle.

Entities such as OEMs may use fraud reporting for a variety of reasons. For example, an OEM of V2X onboard equipment may be interested in seeing information about fraud reports about fraud caused by that V2X onboard equipment. In some cases, OEMs may want information purely for statistical purposes. In other cases, OEMs may take appropriate steps, including but not limited to any of the following: Attempting to correct errors in V2X onboard equipment implementation; Replacing V2X onboard equipment; Disabling V2X onboard equipment; letting owners know they need to bring their vehicles in for maintenance; Deleting certificates from V2X onboard equipment; Placing some V2X onboard equipment certificates on the withdrawal list; Issuing new certificates to V2X onboard equipment. OEMs can do this wirelessly in some cases, but in other cases they require physical access to V2X onboard equipment.

As more and more vehicles are equipped with V2X equipment, the amount of fraud that can be detected is increasing exponentially. If a fraud report is generated in response to every detected fraud, the OEM and/or any fraud agency will be overwhelmed with fraud reports. Accordingly, there may be a need to manage whether to generate a fraud report each time a fraud condition is detected based on the assigned severity of the detected fraud condition. Additionally, in cases where a fraud management system operating within a V2X device decides to generate a fraud report, the fraud management system determines whether to store the fraud report and/or sends the fraud report to a management agency within the SCMS. You may need to manage whether to send or not. Again, the decision as to whether to store a fraud report may be based on the importance assigned to the detected fraud condition. As fraud management systems become more sophisticated, they will receive feedback from fraud management organizations that provide the fraud management system with feedback that can allow the fraud management system to refine and improve its management of fraud events. You can receive In particular, feedback allows the fraud management system to refine instances of generating fraud reports in response to detecting fraud, storing the generated fraud reports, and/or transmitting the fraud reports to the fraud management organization. can be allowed. In some embodiments, feedback may allow the fraud management system to refine the level of importance that can be assigned to detected fraud conditions.

In V2X communication, it is advantageous to detect bad data to prevent useless data from spreading between vehicles. Fraud detection systems play this role and can generate fraud reports as a response after detection. Fraud reports may need to be generated, stored locally, and transmitted to a trusted third party (e.g., a fraud agency within SCMS) for investigation. The rules for creation, storage, and transmission are non-trivial and can be defined so that utility is maximized and overhead is minimized. For example, a fraud detection system should not generate a fraud report for every single fraud of the same type that occurs on the same remote vehicle; it may generate one report and attach an "occurrence" value. This saves creation time (and I/O operations), local storage space, and reduces the number of fraud reports to be transmitted and confirmed by the MA. The ITS community lacks such a set of rules/algorithms for fraud reporting management.

Various embodiments disclosed herein provide methods and mechanisms for managing fraud reporting after fraud conditions are detected. Various embodiments may determine when it is appropriate to generate a fraud report based on an assigned severity in response to a fraud condition being detected. Various embodiments may also determine when it is appropriate to store a generated fraud report at the time the fraud report is generated. The decision to store a fraud report may also be based on the level of importance assigned to the underlying fraud condition that is detected and the subject of the fraud report. Various embodiments may also determine when it is appropriate to delete previously stored fraud reports. Various embodiments may also determine when it is appropriate to transmit a fraud report to a governing body. In some embodiments, to more efficiently utilize the information in a fraud report, a fraud management system may pre-process the data included in the fraud report.

Various embodiments may include receiving feedback from an administrative agency to modify or optimize management of fraud reports. This may include refinement of assigned importance levels.

Various embodiments of fraud management systems can be deployed on any device that can directly or indirectly receive V2X messages. Accordingly, various embodiments disclosed herein may operate, for example, in an on-board unit mounted within a vehicle, a smartphone, a roadside unit, or even in the cloud.

To provide context and background for the various embodiments, the following background is provided on the IEEE 1609 fraud report processing system. The following description is high level and is primarily provided to explain the roles of the various entities and functions envisioned for the interaction between V2X onboard equipment and various entities. The various embodiments are not limited to the fraud reporting management process below.

The transmitting V2X equipment (e.g., on-board unit (OBU), RSU, ASD) may detect fraud conditions and generate, store, and/or provide fraud reports to the SCMS. You can decide whether to transmit it to MA). To authenticate fraud conditions, fraud reports, and basic safety messages, each transmitting V2X device can attach a public key signature to each cheating condition, cheating report, and basic safety message, which is issued to the transmitting V2X onboard device. It can be verified with the public signature key in the pseudonym certificate.

Figure 2 diagrammatically illustrates the various entities involved in communicating fraud reports between a fraud management agency and individual V2X onboard devices and the relationships between entities.

3 illustrates a method 300 of basic operations related to managing the generation, storage, and transmission of fraud reports from a fraud management agency and a fraud management system of a V2X device according to various embodiments. 1-3, operations of method 300 may be performed by a fraud management system (e.g., 102, 104, 106).

At block 302, a fraud management system included in the onboard V2X equipment 102, 104, 106 monitors various sensor data or their respective vehicles 12, 14, 16 to determine whether a fraud condition is detected. can do. In some embodiments, V2X equipment may also include roadside units and/or other mobile units that can monitor and observe the behavior of each other vehicle to determine whether fraud conditions exist. For example, a V2X device may receive basic safety messages from another vehicle that do not match observations the V2X device may make about the other vehicle. For example, the V2X equipment 102 mounted on the vehicle 12 receives a basic safety message (BSM) from the V2X equipment 106 mounted on the vehicle 16 that the vehicle 16 is initiating an emergency braking operation. can do. However, the fraud management system of the V2X equipment 102 mounted on the vehicle 12 may observe that the vehicle 16 does not decelerate or does not apply the emergency brake. In this situation, the V2X equipment 106 mounted on the vehicle 16 other sensor data that the BSM is monitoring that the emergency braking operation is occurring. Since it does not match, a cheating condition may be detected. In addition, the fraud management system of the V2X equipment 102 mounted on the vehicle 12 that receives the BSM from the fraud management V2X equipment 106 mounted on the vehicle 16 is also the V2X equipment mounted on the vehicle 16. A fraud condition can be detected because the BSM received from 106 does not match the observation made by the V2X equipment 102 mounted on the vehicle 12.

Both the V2X equipment 106 mounted on the vehicle 16 as well as the V2X equipment 102 mounted on the vehicle 12 can detect fraud conditions, but each V2X equipment 102 and 106 uses a decision block. At 304, a decision may be made as to whether a fraud report should be generated and, if so, what evidence to collect and attach to the generated fraud report. Creating a Fraud Report After Detecting Fraud Conditions A decision can be based on a number of factors. As discussed in detail below with reference to FIGS. 4A and 4B , the decision to generate a misconduct report may be based on: (i) (potential safety impacts or level of potential road traffic congestion) (ii) the severity of the detected cheating (i.e., the length of the observed cheating (helps to distinguish between temporary defects and persistent cheating); (iii) the number of times the remote vehicle was detected cheating (i.e. , helps deal with sporadic fraud), (iv) number of neighboring vehicles (with different certificates) detected performing similar fraud (this helps in aggregating and reporting larger problems), or (v) simply after at least one detector has been triggered.

In response to determining that a fraud report should be generated (i.e., decision block 304 = “Yes”), a fraud report may be generated at operation 306. Once a fraud report is generated, the V2X device can determine whether the generated fraud report should be stored and/or transmitted to a fraud management agency. In response to determining that a fraud report should not be generated (i.e., decision block 304 = “No”), the V2X device processor may return at block 302 to monitor various sensor data to determine if a fraud condition is detected. You can.

At decision block 308, the fraud management system may determine whether the fraud report should be stored in memory. The decision to save a fraud report after the report has been generated may be based on an assigned level of importance based on a number of criteria. As discussed in detail below with reference to FIGS. 5A and 5B , the decision to store a generated fraud report may also depend on the assigned level of importance based on a plurality of criteria, which may include: There are: (i) confidence level of detection of fraud conditions, (ii) determined message set size (e.g. fraud detected but a certain number of messages from neighboring devices are required), (iii) blacklist approach. determined storage space required (note that storing the hash of the remote vehicle certificate in a Counting Bloom filter (or Cuckoo filter) works), (iv) whether a network connection to the SCMS/PKI is available.

In response to determining that the fraud report should be stored (i.e., decision block 308 = “Yes”), the fraud report may be stored in memory storage of the fraud management system at block 310. Once the fraud report is stored, the fraud management system may determine at decision block 312 whether the generated fraud report should be sent to a fraud management organization.

In response to determining that the fraud report should not be stored (i.e., decision block 312 = “No”), the fraud management system monitors various sensor data to determine if a fraud condition is detected at block 302. You can come back for

In some embodiments, even if the fraud management system determines that the fraud report should not be stored (i.e., decision block 308 = “No”), the fraud management system determines at block 302 whether a fraud condition is detected. To do this, decision block 312 may optionally determine whether to transmit a fraud report to a fraud management agency before monitoring the various sensor data again. As shown in Figure 3, at the optional dashed line, if the fraud management system determines that the fraud report should not be stored (i.e., decision block 308 = "No"), the fraud management system determines optional decision block 312. You can optionally determine whether fraud reports generated in can be sent to a fraud management agency. The fraud management system may determine whether to forward the fraud report to the fraud management agency.

In response to determining that a fraud report should be sent (i.e., decision block 312 = “Yes”), a fraud report may be sent to the fraud management agency at block 314. After the fraud report is sent, the fraud management system may return at block 302 to monitor various sensor data to determine if a fraud condition is detected.

In some embodiments, a fraud management system may use artificial intelligence, neural networks, and/or machine learning techniques (generally referred to herein as “machine learning models”) to detect the occurrence of fraud conditions. The machine learning models It may also be used by a fraud management system to analyze vast amounts of data from a large number of sensors and data sources to obtain an indication or likelihood of whether fraud conditions exist. In embodiments that use a machine learning model to detect a fraud condition, the fraud management system may generate a fraud report that includes information about and/or generated by the machine learning model. This may reduce the amount of data to be included in, stored with, and/or transmitted in a fraud report compared to including all data associated with or characterizing the detected fraud condition. Accordingly, in embodiments where the fraud management system uses a machine learning model to detect a fraud condition, the fraud management system may be configured to generate a fraud report that includes one or more of the following: Machine learning model ; output of the machine learning model; Analysis of key components of machine learning models; Intermediate representation of a machine learning model; Or an identifier for a machine learning model. In embodiments where the fraud report includes an identifier of the machine learning model, the fraud management system and fraud management organization operating on the V2X device may have previously shared the machine learning model and agreed on the index values.

Additionally, in embodiments where there may be multiple stored fraud reports, the fraud management system may establish a priority order in which fraud reports are transmitted. For example, the priority order may be based on a weight determined for each fraud report (i.e., highest priority first). As discussed in detail below with reference to Figure 6, reports of misconduct may be assigned a weight that may vary depending on the relative age of the report of misconduct. If competing fraud reports have the same determined weight, the stored order of the fraud reports may be used to determine the transmission priority order. For example, a first-in-first-out (FIFO) or last-in-first-out (LIFO) scheme may be used, or if the weights determined are not related to the classification or severity of the underlying fraud condition, the assigned classification or severity value may be used as the priority order parameter. You can.

Another transmission priority rule may be a "fairness" rule whereby one's own vehicle may transmit fraud reports reporting to neighboring vehicles (i.e., vehicles with different IDs). These transmission priority rules can ensure that the own vehicle does not always report only one specific neighboring vehicle. Fairness can be implemented using a round robin scheduling technique. For example, the host vehicle can detect cheating conditions occurring within its own vehicle as well as cheating conditions occurring in neighboring vehicles. Referring to FIG. 1 , vehicle 12 (your vehicle) can detect fraud conditions occurring within vehicle 12 as well as fraud conditions occurring in vehicles 14 and 16. The fraud management system operating within the V2X equipment 102 may generate a series of fraud reports related to fraud conditions occurring in each of the vehicle 12, vehicle 14, and vehicle 16. For example, a fraud management system operating within V2X equipment 102 may generate three separate fraud reports related to fraud occurring in each of vehicle 12, vehicle 14, and vehicle 16. there is. Fraud reports can be identified as MBR12-1, MBR12-2, MBR12-3, MBR14-1, MBR14-2, MBR14-3, MBR16-1, MBR16-2, and MBR16-3. Embodiments that implement “fairness” rules may ensure that fraud reports associated with each different vehicle are reported equally within a given uplink budget. Therefore, reports can be transmitted in the following order: MBR12-1, MBR14-1, MBR16-1, MBR12-2, MBR14-2, MBR16-2, MBR12-3, MBR14-3, and MBR16-3.

Fraud reports generated may be sent to a central “Fraud Management Authority” (MA) that processes fraud reports. Fraud management agencies may perform further analysis of fraud reports and determine enforcement actions to be undertaken based on the analysis. In existing fraud management systems, fraud management organizations may not have sufficient knowledge about the reliability of the fraud reports they receive or about their capabilities, which may be due to the fact that the reporting fraud management systems may not have sufficient knowledge about their capabilities or their This is because they may not want to disclose proprietary information about what they have done, and the encryption overhead and redundant data processing can be a burden on fraud management agencies.

In some embodiments, fraud reports may be sent to a fraud preprocessing entity (also referred to as a fraud processor - MBRPre for short) at block 316 for preprocessing before being sent to a fraud management authority (MA). For example, MBRPre (eg, 132, 134) may be an OEM (for reports received from a vehicle) or a mobile network operator (for reports received from a smartphone). A key attribute of MBRPre may be that it has a separate relationship with V2X devices 102, 104, 106 and is trusted by a central fraud management authority 136. This relationship allows the fraud reporting processor (e.g., 132, 134) to update the fraud management system operating within the V2X device so that the fraud management system operating within the V2X device can submit a proprietary format of fraud reporting. Allows transmission to their MBPre (e.g. 132, 134). This relationship also allows MBPre to update fraud reporting forms or generate aggregate or statistical reports and potentially forward original reporting data. Accordingly, in some embodiments, the fraud report first transmitted from the V2X equipment (102, 104, 106) to MBPre (e.g., 132, 134) is transmitted from the V2X equipment (102, 104, 106) to the MA (136). It may include more information than if you were to send a fraud report directly. For example, first, a fraud report transmitted from the V2X equipment (102, 104, 106) to MBPre (e.g., 132, 134) allows MBPre (e.g., 132, 134) to monitor and/or calibrate the sensor. and/or may contain specific or proprietary information that allows recording proprietary information related to the operation of the vehicle. It may be unnecessary for MA 136 to receive such information. Accordingly, in some embodiments, such additional information may be stripped or removed from the fraud report before it is relayed to MA 136.

For example, onboard equipment (e.g., 102, 104, 106) within vehicles 12, 14, 16 may detect location overlapping fraud when two neighboring vehicles equipped with V2X are observed with overlapping locations. You can. The vehicle's OEM may be aware of faulty GNSS receivers and may therefore ignore or omit fraud reports due to these detected conditions to avoid sending faulty fraud reports to a central fraud management agency. As another example, if the OEM knows that the GNSS is not defective, the OEM may augment the fraud report with telematics data to provide richer evidence to the fraud management agency (e.g., 136).

FIG. 4A illustrates an embodiment method for determining, at decision block 304, whether a fraud report should be generated based on the assigned severity level of the underlying fraud condition. The assigned importance level may be based on multiple criteria. For example, the assigned severity level may determine the classification of the basic fraud condition that is the subject of the proposed fraud report, the observed length of the basic fraud condition, the number of occurrences of the basic fraud condition, as well as the number of neighbors that may experience the basic fraud condition. It may also be based on the number of vehicles. To conserve network resources, the generation of fraud reports may be limited to default fraud conditions with higher aggregated importance values. By limiting the generation of fraud reports to the more critical (i.e., having more importance) default fraud conditions, the overall system can prevent fraud that is widespread enough to impact user safety or affect a larger number of V2X system participants. It can be improved by focusing on the conditions of action.

Referring to Figure 4A, after the fraud management system detects that a fraud condition has occurred at block 302, the fraud management system determines whether to generate a fraud report based on whether the aggregated importance value exceeds a threshold. can be decided. The aggregated importance value may be based on one or more of the following: the cheating condition classification, the observed length of the cheating condition, the number of recurrences of the cheating condition, or the number of neighboring vehicles experiencing the cheating condition. Accordingly, Figure 4A shows a number of optional classification and decision blocks that can be aggregated to produce an aggregated importance value. Various embodiments may use any, some, or all of the optional sorting and decision operations. For example, the fraud management system may classify the fraud conditions detected in block 321. For example, cheating conditions can be classified into one of two categories: cheating related to potential safety issues or cheating related to potential road traffic congestion. An appropriate value can be assigned to it to identify the cheating condition, such as cheating related to potential safety issues or cheating related to potential road traffic congestion.

In the example discussed above, the fraud management system of the V2X equipment 102 mounted on the vehicle 12 receives the basic information from the V2X equipment 106 mounted on the vehicle 16 that the vehicle 16 is initiating an emergency braking operation. Safety messages (BSM) can be received. However, other sensor data as well as observations made by other external V2X devices, such as other vehicles or roadside units, may contradict emergency braking activation. These fraudulent conditions may cause other vehicles to perform hard braking actions that may lead to an accident unnecessarily. Accordingly, the cheating condition can be classified as involving a potential safety issue.

In another example, a vehicle's global positioning system (GPS) may incorrectly determine the vehicle's location. By miscalculating the location of vehicles, a particular road/street may incorrectly report more vehicles traveling on that road/street than are actually traveling on that road/street. These incorrect reports may also be related to potential road traffic congestion. Additionally, incorrectly determined vehicle positions may be associated with potential safety issues. For example, if a vehicle's GPS incorrectly determines and reports a vehicle's location as being in the wrong driving lane (i.e., on the wrong side of the road/street), other vehicles may evade to avoid the "phantom" vehicle that is reporting its location incorrectly. You may be instructed to perform maneuvers. This can cause potential safety issues.

In some embodiments, cheating conditions may be categorized as cheating related to potential safety issues or cheating related to potential road traffic congestion, while in other embodiments cheating conditions may be assigned values on a single sliding scale. . For example, a high value may be assigned to a cheating condition related to a safety issue that could result in serious harm. Cheating conditions related only to road traffic congestion may be assigned lower values. Other cheating conditions that may be associated with both potential safety issues and potential road traffic congestion may be assigned an intermediate value based on the relative potential harm of the cheating condition compared to the inconvenience.

At block 323, the fraud management system may determine the observed length of the fraud condition and assign a value based on the observed length. For example, in some cases the fraud condition may be a temporary anomaly that causes the detected fraud. However, in other cases, conditions of misconduct may persist. For example, if a fraud condition only occurs for a short period of time at a specific location, it may be evidence of malicious hacking in a specific area affecting vehicles moving in that area. Conversely, persistent fraud may be the result of faulty sensors that continually report incorrect data. Whether the fraud condition is short or long in duration can be important to the fraud management system. How the fraud management system decides to respond to the observed length (i.e., long or short) of the observed fraud condition may be subjective. In either case, the observed length of detected fraud may be assigned a value for consideration of whether to generate a fraud report.

At block 325, the fraud management system may determine the number of occurrences of the detected fraud and assign a value based on the number of occurrences of the detected fraud. For example, if a fraud management system detects the same fraud that has persisted repeatedly, it may indicate that the sensor needs repair or replacement. Accordingly, multiple occurrences of a detected fraud condition may be assigned a value (higher or lower) that may result in a decision that a fraud report be generated.

At block 327, the fraud management system may determine the number of neighboring vehicles that have experienced fraud. As discussed in the example above, the fraud management system of the V2X equipment 102 mounted on the vehicle 12 causes the vehicle 16 to initiate an emergency braking operation from the V2X equipment 106 mounted on the vehicle 16. You can receive a basic safety message (BSM) saying that you are doing something. However, other sensor data as well as observations made by other external V2X devices, such as other vehicles or roadside units, may contradict emergency braking activation. The fraud management system of the vehicle 12 informs the V2X equipment 102 mounted on the vehicle 12 of observations made by the V2X equipment 106 mounted on the vehicle 16. V2X communications may also be received from the fraud management system of 106. This indication of neighboring vehicles for the same detected fraud condition may further support the level of confidence of vehicle 12's fraud management system that the fraud condition was correctly detected. These indications of neighboring vehicles can be recorded and added as evidence of detection of a fraudulent condition. The fraud management system may assign values to fraud conditions based on the number of neighboring vehicles that have experienced the same fraud. For example, the greater the number of other neighboring vehicles experiencing the same misconduct, the greater the confidence that the misconduct condition is accurately detected.

At block 329, a classification of the detected fraud condition at block 321, the observed length of the detected fraud at block 323, the number of occurrences of the detected fraud at block 325, and The value assigned by the fraud management system based on the number of neighboring vehicles experiencing the fraud condition at block 327 may be aggregated to determine an aggregated importance value for the detected fraud condition. As described above, the aggregated importance value includes any, part, or all of the following: the cheating condition classification, the observed length of the cheating condition, the number of recurrences of the cheating condition, and the number of neighboring vehicles experiencing the cheating condition. can do.

At decision block 330, the fraud management system may determine whether the aggregated importance value exceeds a threshold. In some embodiments, the value assigned to each criterion used to determine whether to generate a fraud report may be a lower value for more severe conditions warranting the creation of a fraud report. In such an embodiment, an aggregation value lower than the threshold will exceed the threshold. In other embodiments, the value assigned to each criterion used to determine whether to generate a fraud report may be a higher value for more severe conditions warranting the creation of a fraud report. In this embodiment, an aggregation value higher than the threshold will exceed the threshold.

In response to determining that the aggregated importance value exceeds a threshold (i.e., decision block 330 = “Yes”), the fraud management system may generate a fraud report at block 306.

In response to determining that the aggregated importance value does not exceed the threshold (i.e., decision block 330 = “No”), the fraud management system may again monitor for other fraud conditions at block 302.

4B, an alternative embodiment is illustrated for determining whether to generate a fraud report at decision block 304 in response to detection of a fraud condition. 1-4B, alternative embodiments also classify the detected fraud condition at block 321, determine the observed length of the detected fraud at block 323, and block 325. Operations may be performed to determine the number of occurrences of the cheating detected at , and to determine the number of neighboring vehicles experiencing the cheating condition at block 327 . However, in contrast to the embodiment shown in Figure 4A, after each operation of classification or judgment, a separate determination may be made as to whether the value assigned to each criterion exceeds a threshold, resulting in a fraud report. It may be possible.

For example, after classifying the detected fraud conditions at block 321 and assigning a value based on the classification of the detected fraud conditions, the fraud management system may determine whether the assigned value is a threshold at block 332. You can decide whether the value is exceeded or not.

If the value assigned based on the classification exceeds a threshold (i.e., decision block 322 = “Yes”), the fraud management system may generate a fraud report at block 306. If the assigned value based on the classification of the detected fraud does not exceed the threshold (i.e., decision block 322 = “No”), the fraud management system may perform the actions of block 323 as described. You can.

After determining the observed length of the detected fraud condition at block 323 and assigning a value based on the observed length of the detected fraud condition, the fraud management system determines the observed length at decision block 324. Based on , it can be determined whether the assigned value exceeds a threshold.

In response to determining that the assigned value exceeds the threshold (i.e., decision block 324 = “Yes”), the fraud management system may generate a fraud report at block 306. In response to determining that the assigned value does not exceed the threshold based on the observed length of the detected fraud (i.e., decision block 324 = “No”), the fraud management system executes block 325 as described. ) operations can be performed.

After determining the number of occurrences of the detected fraud condition at block 325 and assigning a value based on the number of occurrences of the detected fraud condition, the fraud management system determines the number of occurrences at decision block 332. Based on , it can be determined whether the assigned value exceeds a threshold.

In response to determining that the assigned value exceeds the threshold (i.e., decision block 326 = “Yes”), the fraud management system may generate a fraud report at block 306. In response to determining that the assigned value does not exceed the threshold based on the number of occurrences of fraud detected (i.e., decision block 326 = “No”), the fraud management system determines at block 327 the fraud management system. The number of neighboring vehicles experiencing the condition can be determined.

After determining at block 327 the number of neighboring vehicles experiencing the same detected fraud condition and assigning a value based on the number of neighboring vehicles experiencing the same detected fraud condition, the fraud management system determines At block 328 it may be determined whether the assigned value exceeds a threshold based on the number of neighboring vehicles experiencing the same detected fraud condition.

In response to determining that the assigned value exceeds the threshold (i.e., decision block 328 = “Yes”), the fraud management system may generate a fraud report at block 306. In response to determining that the assigned value does not exceed the threshold based on the number of neighboring vehicles experiencing the same detected fraud condition (i.e., decision block 326 = “No”), the fraud management system again describes: As shown, other fraud conditions may be monitored at block 302.

After generating the fraud report at block 306, the fraud management system may determine whether to store the fraud report in local memory at decision block 308 or whether to transmit the fraud report at decision block 312. It is highly likely that there is, or both. In situations where the vehicle does not have a network connection to transmit the fraud report(s), the fraud management system may decide to store the fraud report(s). The decision to store a fraud report(s) may depend on multiple factors, such as: (i) fraud was detected but with low confidence (thereby allowing the collection of more evidence and increasing certainty); (ii) the detector requires a larger message set (e.g. fraud has been detected but requires a certain number of messages from neighboring devices), (iii) the storage requires a blacklist approach (you can store the hash of the remote vehicle certificate in a Counting Bloom filter or Cuckoo filter), and/or (iv) a network connection to the SCMS/PKI is not available.

5A illustrates an embodiment method 308a for determining whether a fraud report should be stored in decision block 308. 1-5A, after a fraud report is generated, a determination is made as to whether the fraud report should be stored in memory. In light of limited memory capacity and the amount of potential fraud conditions that can be detected, the fraud management system may determine which of the generated fraud reports should be stored in memory. In a manner similar to the decision of whether to generate a fraud report for a detected fraud condition shown in Figure 4, fraud reporting reviews and determines a number of criteria related to the storage of the generated fraud report and makes a decision based on the specific criteria. You can assign a value to the fraud report generated for you. The fraud management system may aggregate the assigned values and determine whether the aggregated values exceed a threshold. In response to determining that the threshold has been exceeded, the fraud management system may store the fraud report generated at block 310.

For example, after a fraud report is generated at block 306, the fraud management system may determine a confidence level of the detected fraud condition that is the subject of the fraud report generated at block 331. As mentioned above, multiple data points can support a higher level of confidence in the detected fraud condition. For example, multiple neighboring vehicles may provide an indication of observation that a basic safety message (BSM) received from another vehicle is incorrect. If a large number of neighboring vehicles provide evidence to support that the BSM is incorrect, the level of confidence that a cheating condition is detected can be high. In another example, conflicting sensor data among a plurality of sensors in a vehicle may lead a fraud management system to conclude that a fraud condition has occurred. If an overwhelming number of other sensor data contradicts data from a particular sensor, the fraud management system can conclude with relatively high confidence that a fraud condition has occurred. In any of these examples, a confidence value may be assigned to the detected fraud condition.

Additionally, the fraud management system may determine at block 333 whether additional messages from neighboring vehicles are needed to support fraud reporting. For example, as discussed above, the fraud management system may receive an indication from a neighboring vehicle that the respective observation contradicts the BSM received from the initial vehicle. Each of these indications can support and enhance the level of confidence that fraud conditions are accurately detected. However, each of these additional messages attached to the data supporting the fraud report increases the size of the fraud report that will be stored. Therefore, valuable storage space may be utilized. In some embodiments, it may be determined that such a large fraud report containing additional messages from neighboring vehicles is too large to store. In some embodiments, such fraud reports may be assigned a value that may not support the decision to save the fraud report because it is too large. However, in other embodiments, those fraud reports with supporting evidence may be assigned a value that supports a greater likelihood that the fraud report will be saved.

Additionally, the fraud management system may determine at block 335 whether a communication link to the fraud management organization is available. In cases where a communications link to the fraud management organization is available, the fraud management system may transmit the fraud report to the remote fraud management organization for analysis and storage. Therefore, there may be no need to store fraud reports locally on the V2X device. Accordingly, a fraud management system may assign a value to a fraud report that supports not storing the fraud report locally when a communication link to the fraud management organization is available.

At decision block 339, the fraud management system determines the confidence level of the detected fraud condition determined at block 331, the number of neighboring vehicles experiencing the fraud condition determined at block 333, and at block 337: The value assigned by the fraud management system may be aggregated based on whether a communication link to the determined fraud management organization is available and a determination may be made whether the aggregated value for the fraud report exceeds a threshold.

In response to determining that the aggregated value exceeds the threshold (i.e., decision block 339 = “Yes”), the fraud management system may store the fraud report at block 310.

In response to determining that the aggregated value does not exceed the threshold (i.e., decision block 339 = “No”), the fraud management system may continue to monitor other fraud conditions at block 302. In some embodiments, the value assigned to each criterion used to determine whether to store a fraud report may be a lower value for more severe conditions warranting storage of the fraud report. In such an embodiment, an aggregation value lower than the threshold will exceed the threshold. In other embodiments, the value assigned to each criterion used to determine whether to store a fraud report may be a higher value for more severe conditions warranting storage of the fraud report. In this embodiment, an aggregation value higher than the threshold will exceed the threshold.

5B illustrates an alternative embodiment method 308b for determining whether to store a fraud report at decision block 308. 1-5B, method 308b determines the confidence level of the detected cheating condition at block 331, determines the number of neighboring vehicles experiencing the cheating condition at block 333, and Block 337 of method 308a may include operations for determining whether a communication link to a fraud management organization is available, as described. However, in contrast to method 308a, after each decision operation, a separate determination may be made as to whether the assigned value for each criterion exceeds a threshold, resulting in a fraud report.

For example, after determining the confidence level of a detected fraud condition at block 331 and assigning a value based on the confidence level of the detected fraud condition, the fraud management system may determine the confidence level of the detected fraud condition at block 332. You can determine whether the assigned value exceeds a threshold. In response to determining that the assigned value based on the confidence level exceeds a threshold (i.e., decision block 332 = “Yes”), the fraud management system may store the fraud report in local memory at block 310. In response to determining that the assigned value does not exceed the threshold based on the classification of the detected fraud (i.e., decision block 332 = “No”), the fraud management system determines the fraud condition at block 333. The number of neighboring vehicles experienced can be determined.

After determining the number of neighboring vehicles experiencing the fraud condition at block 333 and assigning a value based on the number of neighboring vehicles experiencing the detected fraud condition, the fraud management system performs decision block 334 It may be determined whether the assigned value based on the number of neighboring vehicles exceeds a threshold. In response to a determination that the assigned value exceeds the threshold (i.e., decision block 334 = “Yes”), the fraud management system stores the fraud report in local memory at block 310 of method 300, as described. It can be saved in .

In response to determining that the assigned value based on the number of neighboring vehicles does not exceed the threshold (i.e., decision block 334 = “No”), the fraud management system sends a message to the fraud management agency at decision block 335. It may be determined whether a communication link to the network is available. In response to determining that a communication link to the fraud management organization is available (i.e., decision block 335 = “Yes”), the fraud management system reports fraud at block 314 of method 300 as described. You may decide to transmit it to a fraud management agency. In response to determining that a communication link to the fraud management organization is not available (i.e., decision block 335 = “No”), the fraud management system determines the fraud management authority at block 310 of method 300 as described. Reports can be saved to local memory.

In addition to determining whether to store a fraud report, the fraud management system may determine when to delete or flush stored fraud reports from local storage to make space for more recently created fraud reports. To facilitate this decision, a weight may be assigned to each stored fraud report. The weight assigned to each stored fraud report may also be used by the fraud management system to determine priority of transmission of specific fraud reports. For example, at decision block 312 of method 300 (FIG. 3), the fraud management system may prioritize one stored fraud report over another based on the respective weights of the stored fraud reports. there is.

Figure 6 illustrates a method 600 for calculating weights for generated fraud reports. 1-6, method 600 may be performed by a fraud management system after a fraud report is generated or after the generated fraud report is stored. As described above, detected fraud conditions that are the subject of a generated fraud report may be classified by the fraud management system at block 321. For example, cheating conditions can be classified into one of two categories: cheating related to potential safety issues or cheating related to potential road traffic congestion.

At block 343, the fraud management system may assign initial weight values to the fraud condition to identify it as fraud associated with potential safety issues or fraud associated with potential road traffic congestion. In some embodiments, cheating conditions may be categorized as cheating related to potential safety issues or cheating related to potential road traffic congestion, while in other embodiments cheating conditions may be assigned initial weight values on a single sliding scale. It may be possible. For example, cheating conditions related to safety issues that could result in serious harm may be assigned a high initial weight value. Cheating conditions related only to road traffic congestion may be assigned low initial weight values. Other cheating conditions that may be associated with both potential safety concerns and potential road traffic congestion may be assigned intermediate initial weight values based on the relative potential harm of the cheating condition compared to the inconvenience. Other factors may affect the assigned initial weight or trigger adjustments or modifications to the assigned initial weight. For example, if multiple instances of the same fraud are observed from the same source, each instance of fraud may be assigned a different weight. In some embodiments, if multiple instances of the same fraud are observed from the same source, this may prompt or trigger the fraud management system to aggregate each instance of fraud and give each instance a higher weight. In some embodiments, when the fraud management system receives a command from the fraud management authority 136 (or the fraud authority preprocessing entity unit 132, 134) to update the assigned initial weights, such command is a fraud management system. This can prompt or trigger the management system to adjust the weights accordingly. These updates by the fraud management system may increase or decrease the assigned initial weight. In some embodiments, a device or vehicle may experience an event that results in an increase in the initial weight assigned to the cheating condition.

As previously stated, the initial weight may depend on the fraud reporting classification as well as how severe the underlying fraud is, and/or may be based on how much it exceeds the reporting threshold. For example, if the rate must match velocity and lateral acceleration, a mismatch of 25% would get a higher initial weight than a mismatch of 5%.

In some embodiments, the aggregate value that may be determined at block 329 may be used as an assigned initial weight for the cheating condition at block 343. For example, the value assigned to a detected fraud condition by the fraud management system at block 329 shown in Figure 4A is the classification of the detected fraud condition made at block 321, as determined at block 323. Includes a value based on one or more of the observed length of the detected fraud, the number of occurrences of the detected fraud determined at block 325, and/or the number of neighboring vehicles experiencing the fraud condition determined at block 327. You may.

In addition to the initial weight values, the fraud management system may assign an attenuation factor to the fraud report at block 345. The attenuation factor may be a value greater than 0 and less than 1. The attenuation factor may be associated with a predetermined time interval. For example, the predetermined time interval can be hours, days, weeks, or months. In some embodiments, when the volume of fraud reports to be generated is large, the fraud management system may assign an attenuation factor at shorter, predetermined time intervals. In some embodiments, a smaller attenuation factor may be used to reduce the number of actionable fraud reports for storage and/or transmission. In some embodiments, the combination of a shorter predetermined time interval and a smaller attenuation factor may facilitate a reduction in the overall number of fraud reports determined by the fraud management system for storage and/or transmission.

At block 347, the fraud management system may determine the initial weight of the fraud report, for example, by multiplying the fraud report's assigned initial weight value by an attenuation factor.

At block 349, the fraud management system may store these determined weights along with the associated fraud report. The fraud management system may perform decision block 308 of method 300 (FIG. 3), decision block 330 of operations 304 (FIG. 4A), and/or determination of operations 308a (FIG. 5A). Block 339 may retrieve and use the stored determined weight as a factor to determine whether to store the associated fraud report.

A fraud management system may use counters, timers, and/or clocks to maintain predetermined time intervals. The fraud management system may determine at decision block 351 whether a predetermined time interval has elapsed. In response to determining that the predetermined time interval has not elapsed (i.e., decision block 351 = “No”), the fraud management system may return at a later time to determine whether the predetermined time interval has elapsed.

In response to determining that a predetermined time interval has elapsed (i.e., decision block 351 = “Yes”), the fraud management system may determine a new weight for the fraud report at block 353. To recalculate the weight of a fraud report, the fraud management system may retrieve the previously determined weight value from storage and multiply that value by the attenuation factor.

The fraud management system may store the redetermined weight value of the fraud report at block 349. Once the determined weight or re-determined weight value is stored, this value may be used by the fraud management system to determine whether to store, delete and/or transmit a fraud report based on the stored determined weight value.

Figure 7 illustrates a method 700 of the flush/delete process that can utilize the determined weight of the fraud report. 1-7, after a fraud report is stored at block 310 of method 300, the fraud management system audits the remaining available storage space in local memory and determines the remaining storage space at decision block 361. You can determine whether the space is below a critical amount. If the fraud management system detects insufficient storage space, the fraud management system can flush the fraud report in any of a variety of ways: (i) first-in-first-out (FIFO), (ii) least severe. /dangerous/destructive first, (iii) duplicates first (assuming fraud reports are created to report the same senderID and same fraud - the system may aggregate fraud reports before deleting older duplicates) ), and/or (iv) based on individual current fraud reporting weights.

In response to determining that the remaining storage space is below the threshold amount (i.e., decision block 361 = “Yes”), the fraud management system may delete the stored fraud report at block 363. Selection of fraud reports for deletion can be determined by storage order (e.g., FIFO or last-in-first-out (LIFO)), classification type of the fraud report, number of fraud reports reporting the same duplicate fraud condition, or method (600 ) may be based on one of the determined weights of the fraud determined in (Figure 6). Some embodiments of fraud management systems may choose to delete stored fraud reports in a FIFO or LIFO system. Some embodiments of the fraud management system may choose to delete stored fraud reports so that only the fraud reports that report potential traffic nuisances are deleted. In this way, reports of misconduct related to safety issues can be preserved. In some fraud management systems, reports containing duplicate fraud may be selected for deletion. In some embodiments, values representing any and all of these factors may be provided and aggregated. The decision on which misconduct report to delete may be made based on the aggregate value of these factors.

In response to determining that the remaining storage space is above the threshold (i.e., decision block 361 = “No”), the fraud management system may continue to monitor fraud conditions at block 302 of method 300, as described. there is.

An alternative to deleting fraud reports is to offload fraud report storage to another module (e.g., smartphone, edge device, other vehicle) as long as the fraud report is encrypted and signed. Decisions about which fraud reports to offload may follow the deletion or forwarding rules described here.

As the MBR is transmitted to a central fraud management organization, such as SCMS, the way the fraud management system generates fraud reports, stores fraud reports, and determines whether to forward a fraud report may be modified. 8 illustrates a method 800 for modifying the manner in which a fraud management system may be modified.

1-8, following the operations of block 314 of method 300, the fraud management system may receive feedback from a central fraud management organization, such as a SCMS, at block 371. This feedback may be a message sent from the central fraud management agency to the vehicle fraud management system confirming or denying the existence of a fraud condition event. For example, the feedback message may include a Boolean/binary value indicating whether the fraud report sent by the fraud management system is accurate (response value is true) or incorrect (response value is false). In some embodiments, the local fraud detection system (belonging to the final entity) may update its initial weight factors. For example, an end entity can lower the confidence level of its local detection system if the fraud management system does not agree with the local detection system.

As discussed above, in each of the various decisions, various weights and values may be assigned to the various factors based on how the fraud management system chooses to emphasize certain factors over others. For example, in some embodiments, a fraud management system may attribute repeated occurrences of the same fraud condition to a faulty sensor and ignore it as a minor inconvenience. In such embodiments, the fraud management system may assign lower priority values to repetitive occurrences. However, feedback received from the central fraud management agency can modify the factors that the fraud management system uses to make various decisions. Moreover, the thresholds that may result in decisions to create, store and/or transmit may be modified based on feedback from a central fraud management authority. In method 800, each of the generation, storage, and transmission thresholds that govern each of these decisions may be adjusted at blocks 373, 375, and 377. Once adjustments to the various values have been made, the fraud management system may again monitor the sensor data for additional fraud conditions at block 302 of method 300.

For example, referring to FIGS. 4A, 4B, and 8, the fraud management agency may ensure that only fraud conditions that are associated with the most severe safety conditions and/or persist for an extended length of time result in the generation of a fraud report. Feedback may be provided to change the values assigned to or the thresholds used by the fraud management system to evaluate specific detected fraud conditions. In some embodiments, feedback from a fraud management organization may inform a fraud management system operating on a particular vehicle's V2X equipment (i.e., 102, 104, 106) that certain types of fraud are no longer used; , which in turn means that the aggregated importance values can no longer be used and therefore no reports should be generated identifying that specific fraud condition.

Examples of embodiment methods are now described. A vehicle 12 with onboard V2X equipment 102 may receive basic safety messages with incorrect data. A local fraud detection system may analyze the BSM and conclude that remote transmitter A (e.g. vehicle 14) is cheating, noting that it is sending a fake location that is likely to trigger a false electronic emergency brake light warning. there is. The fraud management system decides to generate a fraud report (MBR-A). The fraud management system collects evidence (e.g., vehicle 12's own BSM, remote sender BSM, triggered detector list, etc.), classifies the fraud condition as a "fake kinematic condition" and assigns a severity level of "high". A value can be assigned. The fraud management system may decide to store MBR-A with an initial weight of 1 and an attenuation factor of 0.1. In this example, vehicle 12 with onboard V2X equipment 102 does not have a connection to the SCMS (to upload fraud reports), and therefore vehicle 12 with onboard V2X equipment 102 does not transmit it. You have to wait before doing it. The next day (i.e., predetermined time interval = days), the fraud management system applies an attenuation factor to MBR-A, reducing its priority to 0.9. Vehicle 12 with onboard V2X equipment 102 detects another fraud condition by a different remote transmitter B (e.g., vehicle 16). The tampering condition for transmitter B is a position jump within the communication range, but this is not critical to safety. Therefore, MBR-B can be stored with a priority value of and an attenuation factor of 0.2. A vehicle 12 equipped with onboard V2X equipment 102 establishes a connection with the SCMS and begins uploading its stored fraud reports according to priority values: MBR-A -> MBR-B. The fraud management system maintains a record of identifiers A and B for blacklisting purposes and deletes MBR-B after confirmation of a successful upload. (Optional) After two days, the fraud management agency has completed the fraud investigation and wishes to provide feedback to the fraud management system. Vehicle 12 with onboard V2X equipment 102 receives notification that MBR-A is accurate while MBR-B is incorrect. The fraud management system can then adjust its creation/storage/transmission parameters accordingly and inform the local fraud detection system to adjust its internal parameters.

Various embodiments (including, but not limited to, the embodiments described above with reference to FIGS. 1-8 ) can be implemented in a variety of computing systems, including mobile computing devices as well as on-board equipment, and the various embodiments and An example suitable for use together is shown in Figure 9. Mobile computing device 400 may include a processor 402 coupled to a touch screen controller 404 and internal memory 406. Processor 402 may be one or more multi-core integrated circuits designated for general or specific processing tasks. Internal memory 406 may be volatile or non-volatile memory, secure and/or encrypted memory, or non-secure and/or unencrypted memory, or any combination thereof. Examples of memory types that can be leveraged include, but are not limited to, DDR, LPDDR, GDDR, WIDEIO, RAM, SRAM, DRAM, P-RAM, R-RAM, STT-RAM, and embedded DRAM. Touchscreen controller 404 and processor 402 may also be coupled to a touch screen panel 412, such as a resistive detection touch screen, capacitive detection touch screen, infrared detection touch screen, etc. Additionally, the display of mobile computing device 400 need not have touch screen capability.

Mobile computing device 400 may include one or more wireless signal transceivers 408 (e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF radio) and coupled to each other and/or to processor 402 to transmit and communicate communications. It may have an antenna 410 for receiving. Transceivers 408 and antenna 410 may be used with the circuitry described above to implement various wireless transmission protocol stacks and interfaces. Mobile computing device 400 may include a cellular network wireless modem chip 416 coupled to a processor and enabling communication over a cellular network.

Mobile computing device 400 may include a peripheral device connection interface 418 coupled to processor 402. Peripheral device connection interface 418 may be configured solely to accept one type of connection, or may be configured to accommodate a variety of common or proprietary connections, such as Universal Serial Bus (USB), FireWire, Thunderbolt, or PCIe. Can be configured to accommodate any type of physical and communication link. Additionally, peripheral device connection interface 418 may be coupled to a similarly configured peripheral connection port (not shown).

Mobile computing device 400 may also include speakers 414 to provide audio output. Mobile computing device 400 may also include a housing 420 comprised of plastic, metal, or a combination of materials to contain all or some of the components described herein. Those skilled in the art will appreciate that housing 420 may be an instrument panel of a vehicle in an on-board embodiment. Mobile computing device 400 may include a power source 422 coupled to processor 402, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to a peripheral connection port to receive charging current from a source external to mobile computing device 400. Mobile computing device 400 may also include a physical button 424 for receiving user input. Mobile computing device 400 may also include a power button 426 to turn mobile computing device 400 on and off.

Various embodiments (including, but not limited to, those described above with reference to FIGS. 1-8 ) can be implemented in a variety of computing systems, including a laptop computer 500, an example of which is shown in FIG. 10 do. Many laptop computers include a touchpad touch surface 517 that functions as a pointing device for the computer and is thus equipped with a touch screen display and capable of receiving drag, scrolling and flick gestures similar to those implemented on the computing devices described above. . Laptop computer 500 will typically include a processor 502 coupled to volatile memory 512 and a large amount of non-volatile memory, such as a disk drive 513 of flash memory. Computer 500 may also have a cellular telephone transceiver 516 coupled to processor 502 and/or one or more antennas 508 for transmitting and receiving electromagnetic radiation, which may be coupled to a wireless data link. Computer 500 may also include a floppy disk drive 514 and a compact disk (CD) drive 515 coupled to processor 502. In a laptop configuration, the computer housing includes a touchpad 517, a keyboard 518, and a display 519, all coupled to a processor 502. Other configurations of a computing device may include a computer mouse or trackball coupled to a processor (e.g., via a USB input), as is well known, and may also be used with various embodiments.

Various embodiments (including, but not limited to, the embodiments described above with reference to FIGS. 1-8) also provide a fraud management organization utilizing a fixed computing system, such as any of a variety of commercially available servers. It may also be included. An example server 600 is shown in FIG. 11 . Such servers 600 typically include one or more multicore processor assemblies 601 coupled to volatile memory 602 and a large amount of non-volatile memory, such as disk drives 604. As shown in Figure 6, multi-core processor assemblies 601 can be added to server 600 by inserting them into a rack of assemblies. Server 600 may also include a floppy disk drive, compact disk (CD), or digital versatile disk (DVD) disk drive 606 coupled to processor 601 . Server 600 may also be connected to a local area network, the Internet, a public switched telephone network, and/or a cellular data network (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, and a network access port 603 coupled to the multi-core processor assembly 601 to establish a network interface connection with a network 607, such as 5G, LTE, or any other type of cellular data network. .

Implementation examples are described in the following paragraphs. While some of the following implementation examples are described with respect to example methods, additional example implementations include: a mobile, onboard unit comprising a processor configured with processor-executable instructions to perform the operations of the following implementation example methods; Example methods discussed in the following paragraphs implemented by a fraud management system operating in conjunction with V2X equipment, which may be a device unit, a mobile computing unit, or a fixed curbside unit; May include example methods discussed in the following paragraphs implemented by V2X equipment including means for performing the functions of the methods of the following implementation examples; And the example methods discussed in the following paragraphs may be implemented as a non-transitory processor-readable storage medium storing processor-executable instructions configured to cause the processor of the V2X device to perform the operations of the methods of the following implementation examples. You can.

Example 1. A method of managing fraud reports, comprising: determining whether to generate a fraud report to identify a fraud condition based on an aggregated importance value in response to detection of the fraud condition; generating a fraud report identifying the fraud conditions in response to the decision to create a fraud report to identify the fraud conditions; Deciding whether to save the generated fraud reports; and transmitting the generated fraud report to a fraud management agency.

Example 2. The method of Example 1, further comprising determining whether to transmit the generated fraud report to the fraud management organization, wherein sending the generated fraud report to the fraud management organization determines whether to transmit the generated fraud report to the fraud management organization. This is done in response to your decision to send .

Example 3. The of Examples 1 or 2, further comprising analyzing the sensor data using a machine learning model to determine whether a fraud condition is detected, wherein generating a fraud report identifying the fraud condition comprises: Includes generating fraud reports that include one or more of the following: machine learning models; output of the machine learning model; Analysis of key components of machine learning models; Intermediate representation of a machine learning model; Or an identifier for a machine learning model.

Example 4. The method of any of Examples 1-3, comprising: classifying detected fraud conditions based on the potential safety impact of the fraud condition or the level of potential traffic congestion; determining the observed length of the cheating condition; determining the number of recurrences of the misconduct condition; or determining the number of neighboring vehicles experiencing a cheating condition, wherein the method comprises a cheating condition classification, an observed length of the cheating condition, a number of recurrences of the cheating condition, and a cheating condition. It further includes generating an aggregated importance value based on one or more of the number of neighboring vehicles experiencing.

Example 5. The method of any of Examples 1-4, comprising: determining a confidence level of detection of a fraud condition that is the subject of a fraud report; determining whether additional messages from neighboring vehicles accompany the misconduct report; or determining whether a network communication link to a fraud management organization is available for transmitting a fraud report, wherein the method provides a level of confidence in detection of a fraud condition, a Accompanying additional messages include determining whether to store the fraud report based on one or more of the number of neighboring vehicles, and whether a network communication link to the fraud management agency is available for transmitting the fraud report.

Example 6. The method of Example 5, classifying detected fraud conditions that are the subject of a fraud report generated based on the potential safety implications of the fraud conditions; Assigning initial weight to fraud reports based on classification of fraud conditions; Assigning an attenuation factor to fraud reports; and multiplying the assigned initial weight by an attenuation factor at regular intervals to determine the determined weight of the fraud report, wherein determining whether to store the fraud report further includes multiplying the determined weight of the fraud report. It is based on

Example 7. The method of Example 5, classifying detected fraud conditions subject to fraud reports generated based on the level of potential traffic congestion; Assigning an initial weight to fraud reports based on classification of fraud conditions; Assigning an attenuation factor to fraud reports; and multiplying the assigned initial weight by an attenuation factor at regular intervals to determine the determined weight of the fraud report, wherein determining whether to store the fraud report further includes multiplying the determined weight of the fraud report. It is based on

Example 8. The method of examples 6 or 7, including determining whether available storage space is below a storage space threshold level; further comprising performing a flush operation in response to determining that the available storage space is below the storage space threshold level, wherein the flush operation includes: the order in which the fraud reports are stored, the classification of the fraud conditions, the number of duplicates stored; and detecting stored fraud reports based on one of the determined weights of the fraud reports.

Example 9. In Example 8, determining whether to transmit a fraud report may include classification of the fraud condition; The order in which fraud reports are stored; or based on at least one of the fairness rules.

Example 10. The method of Example 9, comprising: receiving feedback from a fraud management agency; and performing one or more of the following: adjusting generation parameters that influence the decision to generate a fraud report to identify fraud conditions in response to the feedback; The level of confidence in detecting fraud conditions in response to the feedback, the number of additional message neighboring vehicles accompanying the fraud report, and whether the network communication link to the fraud management agency will store fraud reports generated in response to the feedback. adjusting one or more thresholds for availability for sending a fraud report used to determine; or adjusting transmission parameters that affect the decision to transmit a fraud report to a fraud management agency in response to feedback.

Example 11. The method of any of Examples 1-10, further comprising sending the fraud report to a fraud pre-processing entity for pre-processing before being transmitted to the fraud management agency.

The foregoing method descriptions and process flow diagrams are provided as illustrative examples only and are not intended to require or imply that the blocks of the various embodiments must be performed in the order presented. As will be appreciated by those skilled in the art, the order of operations in the above-described embodiments may be performed in any order. Words such as "after", "after that", "next", etc. are not intended to limit the sequence of actions; These words are simply used to guide the reader through the description of the methods. Additionally, any reference to claim elements in the singular, for example, using the articles “a,” “or “the,” should not be construed as limiting that element to the singular.

The various example logic blocks, modules, circuits, and algorithmic operations described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate the interchangeability of such hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether this functionality is implemented in hardware or software depends on 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 construed as causing a departure from the scope of the claims.

The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein include general purpose processors, digital signal processors (DSPs), and application specific integrated circuits (ASICs). , a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. there is. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry specific to a given function.

In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable medium or non-transitory processor-readable medium. The operations of a method or algorithm disclosed herein may be implemented in a processor-executable software module, which may reside on a non-transitory computer-readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or processor. By way of example, and not limitation, such non-transitory computer-readable or processor-readable media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any desired storage device. It may be used to store program code in the form of instructions or data structures and may include any other medium that may be accessed by a computer. Disk and disc as used herein include compact disk (CD), laser disk, optical disk, digital versatile disk (DVD), floppy disk and Blu-ray disk, where disk ( A disk usually reproduces data magnetically, but a disc reproduces data optically using a laser. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside on a non-transitory processor-readable medium and/or computer-readable medium as one or any combination or set of codes and/or instructions, which may be It may also be incorporated into a computer program product.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Accordingly, 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 novel features and principles disclosed herein.

Claims (30)

As a method of managing reports of misconduct,
determining whether to generate a fraud report to identify the fraud condition based on an aggregated importance value in response to detecting the fraud condition;
in response to determining to generate a fraud report to identify the fraud condition, generating a fraud report identifying the fraud condition;
determining whether to store the generated fraud report; and
A method of managing fraud reports, comprising transmitting the generated fraud report to a fraud management organization. According to claim 1,
Further comprising the step of determining whether to transmit the generated misconduct report to the fraud management agency, wherein the step of transmitting the generated misconduct report to the fraud management agency includes transmitting the generated misconduct report. How to manage reports of misconduct, carried out in response to your decision to do so. According to claim 2,
further comprising analyzing the sensor data using a machine learning model to determine whether a fraud condition is detected, wherein generating a fraud report identifying the fraud condition comprises: the machine learning model, the machine Generating fraud reports comprising one or more of the output of a learning model, an analysis of key components of the machine learning model, an intermediate representation of the machine learning model, or an identifier of the machine learning model. How to manage. According to claim 1,
classifying the detected fraud condition based on its potential safety impact or level of potential traffic congestion;
determining an observed length of the cheating condition;
determining a number of recurrences of the cheating condition; or
further comprising one or more of the steps of determining a number of neighboring vehicles experiencing the cheating condition;
generating the aggregated importance value based on one or more of a cheating condition classification, an observed length of the cheating condition, a number of recurrences of the cheating condition, and a number of neighboring vehicles experiencing the cheating condition. A method for managing fraud reports, further comprising: According to claim 1,
determining a level of confidence in detection of the fraud condition that is the subject of the fraud report;
determining whether there are additional messages from multiple neighboring vehicles accompanying the misconduct report; or
further comprising determining whether a network communication link to the fraud management organization is available for transmitting the fraud report;
One or more of the following: the confidence level of detection of the fraud condition, the number of additional message neighboring vehicles accompanying the fraud report, or whether a network communication link to the fraud management agency is available for transmitting the fraud report. A method for managing fraud reports, further comprising determining whether to store the fraud report based on: According to claim 5,
classifying the detected fraud condition that is the subject of the generated fraud report based on the potential safety impact of the fraud condition;
assigning an initial weight to the fraud report based on the classification of the fraud condition;
assigning an attenuation factor to the fraud report; and
determining a weight of the fraud report at regular intervals based on the assigned initial weight and the attenuation factor, wherein determining whether to store the fraud report also includes determining the determined weight of the fraud report A method for managing fraud reports, further comprising determining the weight based on . According to claim 5,
classifying the detected fraud conditions that are the subject of the generated fraud report based on potential safety implications of the level of potential traffic congestion;
assigning an initial weight to the fraud report based on the classification of the fraud condition;
assigning an attenuation factor to the fraud report; and
determining a weight of the fraud report at regular intervals based on the assigned initial weight and the attenuation factor, wherein determining whether to store the fraud report also includes determining the determined weight of the fraud report A method for managing fraud reports, further comprising determining the weight based on . According to claim 7,
determining whether available storage space is below a storage space threshold level; and
In response to determining that the available storage space is below a storage space threshold level, performing a flush operation, wherein the flush operation is dependent on the order in which the fraud reports are stored, the classification of the fraud conditions, and the types of overly stored copies. A method for managing fraud reports, further comprising performing the flush operation, deleting stored fraud reports based on either a number or a determined weight of the fraud report. According to claim 8,
Wherein determining whether to transmit the fraud report is based on at least one of a classification of the fraud conditions, an order in which the fraud reports are stored, or a fairness rule. According to clause 9,
receiving feedback from the fraud management agency; and
A method of managing fraud reports, further comprising performing one or more of the following:
adjusting generation parameters affecting the decision to generate the fraud report to identify the fraud condition in response to the feedback;
In response to the feedback, the level of confidence in detection of the fraud condition, the number of additional message neighboring vehicles accompanying the fraud report, and a network communication link to the fraud management agency to send the generated fraud report. adjusting one or more thresholds for availability to transmit the fraud report used to determine whether to store; or
In response to the feedback, adjusting transmission parameters affecting the decision to transmit the fraud report to the fraud management agency. According to claim 1,
A method for managing fraud reports, further comprising transmitting the fraud report to a fraud pre-processing entity for pre-processing before being transmitted to the fraud management agency. As a fraud management system for use in vehicle-to-everything (V2X) equipment,
a transmitter configured to wirelessly transmit and receive data related to fraud reports to and from the fraud management agency;
a memory storage coupled to the transmitter and configured to store fraud reports; and
comprising a processor coupled to the transmitter and the memory storage,
The processor,
determine whether to generate a fraud report to identify a fraud condition based on an aggregated importance value in response to detecting the fraud condition;
in response to determining to generate a fraud report to identify the fraud condition, generate a fraud report identifying the fraud condition;
determine whether to store the fraud report generated; and
To transmit the generated fraud report to the fraud management agency
A fraud management system for use in V2X equipment, consisting of processor-executable instructions. According to claim 12,
The processor also:
determine whether to transmit the generated fraud report to the fraud management agency;
transmitting the generated fraud report to the fraud management agency in response to determining to transmit the generated fraud report.
A fraud management system for use in V2X equipment, consisting of processor-executable instructions. According to claim 13,
The processor also:
Analyze sensor data using machine learning models to determine whether fraud conditions are detected;
The fraud by generating a fraud report that includes one or more of the machine learning model, an output of the machine learning model, an analysis of key components of the machine learning model, an intermediate representation of the machine learning model, or an identifier of the machine learning model. to generate said misconduct reports identifying the conditions of conduct;
A fraud management system for use in V2X equipment, consisting of processor-executable instructions. According to claim 12,
The processor also:
classifying the detected fraud condition based on its potential stability impact or level of potential traffic congestion;
determining the observed length of the cheating condition;
determining the number of recurrences of the misconduct condition; or
Determining the number of neighboring vehicles experiencing the cheating condition
Consists of processor-executable instructions to perform one or more of the following:
The processor may further determine the cheating condition based on one or more of a cheating condition classification, an observed length of the cheating condition, a number of recurrences of the cheating condition, and a number of neighboring vehicles experiencing the cheating condition. A fraud management system for use in V2X equipment, comprising processor-executable instructions for determining whether to generate the fraud report to identify a. According to claim 12,
The processor also:
determining a level of confidence in detection of the fraud condition that is the subject of the fraud report;
determining whether additional messages from neighboring vehicles accompany the misconduct report; or
determining whether a network communications link to the fraud management agency is available for transmitting the fraud report;
Consists of processor-executable instructions to perform one or more of the following:
The processor may also determine the confidence level of detection of the fraud condition, the number of additional message neighboring vehicles accompanying the fraud report, and the network communication link to the fraud management agency used to transmit the fraud report. A fraud management system for use in V2X equipment, comprising processor-executable instructions for determining whether to store the fraud report based on one or more of availability. According to claim 16,
The processor also:
classify the detected fraud condition that is the subject of the generated fraud report based on the potential safety impact of the fraud condition;
assign an initial weight to the fraud report based on the classification of the fraud condition;
assign an attenuation factor to the fraud report; and
determining the weight of the fraud report at regular intervals based on the assigned initial weight and the attenuation factor, wherein determining whether to store the fraud report is also based on the determined weight of the fraud report. To determine the weight,
A fraud management system for use in V2X equipment, consisting of processor-executable instructions. According to claim 17,
The processor also:
classify the detected fraud conditions that are the subject of the generated fraud report based on the potential safety implications of the level of potential traffic congestion;
assign an initial weight to the fraud report based on the classification of the fraud condition;
assign an attenuation factor to the fraud report; and
determining the weight of the fraud report at regular intervals based on the assigned initial weight and the attenuation factor, wherein determining whether to store the fraud report is also based on the determined weight of the fraud report. To determine the weight,
A fraud management system for use in V2X equipment, consisting of processor-executable instructions. According to claim 17,
The processor also:
determine whether available storage space is below a storage space threshold level; and
Performing a flush operation in response to determining that the available storage space is below a storage space threshold level, wherein the flush operation includes the order in which the fraud reports are stored, the classification of the fraud condition, and the number of duplicates stored. , or to perform the flush operation, deleting stored fraud reports based on one of the determined weights of the fraud report.
A fraud management system for use in V2X equipment, consisting of processor-executable instructions. According to claim 19,
The processor further comprises processor-executable instructions for determining whether to transmit the fraud report based on at least one of a classification of the fraud condition, an order in which the fraud report is stored, or a fairness rule. , a fraud management system for use in V2X equipment. According to claim 20,
The processor also:
receive feedback from said fraud management agency; and
A fraud management system for use in V2X equipment, comprising processor-executable instructions to perform one or more of the following:
adjusting generation parameters that affect the decision to generate the fraud report to identify the fraud condition in response to the feedback;
In response to the feedback, the level of confidence in detection of the fraud condition, the number of additional message neighboring vehicles accompanying the fraud report, and a network communication link to the fraud management agency to send the generated fraud report. adjusting one or more thresholds for availability to transmit the fraud report used to determine whether to store; or
In response to the feedback, adjusting transmission parameters affecting the decision to transmit the fraud report to the fraud management agency. According to claim 12,
The processor may also provide a fraud management for use in V2X equipment, comprising processor-executable instructions for transmitting the fraud report to a fraud pre-processing entity for pre-processing before being transmitted to the fraud management agency. system. As a fraud management system for use in vehicle-to-everything (V2X) equipment,
means for determining whether to generate a fraud report to identify the fraud condition based on the aggregated severity value in response to detection of the fraud condition;
means for generating a fraud report identifying the fraud condition in response to determining to generate a fraud report to identify the fraud condition;
means for determining whether to store said fraud report generated; and
A fraud management system for use in V2X equipment, comprising means for transmitting the generated fraud report to a fraud management agency. According to claim 23,
further comprising means for determining whether to transmit the generated fraud report to the fraud management organization, wherein the means for transmitting the generated fraud report to the fraud management organization transmits the generated fraud report. A fraud management system for use in V2X equipment, comprising means for transmitting the generated fraud report to the fraud management organization in response to determining to do so. According to claim 23,
means for classifying the detected fraud condition based on its potential stability impact or level of potential traffic congestion;
means for determining the observed length of the cheating condition;
means for determining the number of recurrences of the cheating condition; or
further comprising one or more means for determining the number of neighboring vehicles experiencing the cheating condition;
Means for generating the aggregated importance value based on one or more of a cheating condition classification, an observed length of the cheating condition, a number of recurrences of the cheating condition, or a number of neighboring vehicles experiencing the cheating condition. A fraud management system for use in V2X equipment, further comprising: According to claim 23,
means for determining a level of confidence in detection of the fraud condition that is the subject of the fraud report;
means for determining whether there are additional messages from multiple neighboring vehicles accompanying the misconduct report; or
further comprising one or more means for determining whether a network communication link to the fraud management organization is available for transmitting the fraud report;
The means for determining whether to store the fraud report includes: the level of confidence in detection of the fraud condition; the number of additional message neighboring vehicles accompanying the fraud report; and the network communication link to the fraud management agency. A fraud management system for use in V2X equipment, based on one or more of the availability for sending fraud reports. According to claim 26,
means for classifying the detected fraud condition that is the subject of the generated fraud report based on the potential safety impact of the fraud condition;
means for assigning an initial weight to the fraud report based on the classification of the fraud condition;
means for assigning an attenuation factor to the fraud report; and
means for determining the weight of the fraud report at regular intervals based on the assigned initial weight and the attenuation factor, wherein determining whether to store the fraud report also depends on the determined weight of the fraud report. Based on, a fraud management system for use in V2X equipment, further comprising means for determining the weight. According to clause 27,
means for classifying the detected misconduct conditions that are the subject of the generated misconduct reports based on potential safety implications of the level of potential traffic congestion;
means for assigning an initial weight to the fraud report based on the classification of the fraud condition;
means for assigning an attenuation factor to the fraud report; and
means for determining the weight of the fraud report at regular intervals based on the assigned initial weight and the attenuation factor, wherein determining whether to store the fraud report also depends on the determined weight of the fraud report. Based on, a fraud management system for use in V2X equipment, further comprising means for determining the weight. According to clause 28,
The means for determining whether to transmit the fraud report may include means for determining whether to transmit the fraud report based on at least one of a classification of the fraud conditions, an order in which the fraud report is stored, or a fairness rule. Fraud management system for use in V2X equipment, including. A non-transitory processor-readable storage medium storing processor-executable instructions, comprising:
The above instructions cause the processor of the fraud management system to:
determining whether to generate a fraud report to identify the fraud condition based on the aggregated importance value in response to detecting the fraud condition;
generating a fraud report identifying the fraud condition in response to determining to generate a fraud report to identify the fraud condition;
determining whether to store said fraud report generated; and
Sending the above-generated fraud report to the fraud management agency.
A non-transitory processor-readable storage medium configured to perform operations comprising: