Techniques for managing data distribution in a V2X environment

Abstract

Techniques described herein include utilizing a mobile device as a proxy receiver and / or transmitter for vehicles in a V2X network. In some embodiments, a mobile device function associated with the mobile device may be configured to obtain vehicle capabilities and store such data in memory at the mobile device. The mobile device may obtain any suitable combination of reception authentication information and one or more transmission authentication information. In some embodiments, the one or more transmission authentication information may be generated by an authentication authority based at least in part on determining that the vehicle and / or mobile device functions indicate that sensors and / or processing resources of the vehicle and / or mobile device meet a transmission requirement threshold for the network. The mobile device may then use at least one of the transmission authentication information to transmit any suitable data message on behalf of the vehicle.

Description

Background Art

[0001]

[0001] Vehicle-to-everything (V2X) communication is a communication standard for vehicles and related entities to exchange information about the traffic environment. V2X can include vehicle-to-vehicle (V2V) communication between V2X-enabled vehicles, vehicle-to-infrastructure (V2I) communication between a vehicle and an infrastructure-based device (commonly called a roadside unit (RSU)), vehicle-to-person (V2P) communication between a vehicle and nearby people (pedestrians, cyclists, and other road users), and so on. Further, V2X can use any of various wireless radio frequency (RF) communication technologies. For example, Cellular V2X (CV2X) is a form of V2X that uses cellular-based communication such as Long-Term Evolution (LTE (registered trademark)), 5th Generation New Radio (5G NR), and / or other cellular technologies in a direct communication mode defined by the 3rd Generation Partnership Project (3GPP (registered trademark)). Components or devices on a vehicle, RSU, or other V2X entity used to communicate V2X messages are generally called V2X devices or V2X user equipment (UE).

[0002]

[0002] Autonomous / semi-autonomous vehicles, including vehicles with Advanced Driver-Assistance Systems (ADAS), can use V2X to communicate and adjust their maneuvers. To assist V2X-enabled vehicles (「V2X vehicles」) in safely maneuvering on the road, a V2X vehicle can communicate its intended maneuvers to other V2X vehicles. This can include maneuvers such as lane changes, intersections crossings, and the corresponding time windows of the behavior trajectories.

[0003]

[0003] Legacy vehicles not configured with ADAS may not utilize valuable data being communicated or their involvement may not be optimal. Many of the benefits of a vehicle-to-vehicle / vehicle-to-infrastructure communication (V2X) environment rely on knowing the exact inter-vehicle distance and relative position and having awareness of the environment and situation. However, legacy vehicles are unable to transmit such information. The drivers of both legacy vehicles and autonomous (or semi-autonomous) vehicles can benefit from these types of shared interactions and communications.

Summary of the Invention

[0004]

[0004] The techniques described herein provide for sending data by a mobile device instead of a vehicle.

[0005]

[0005] Some embodiments may include a method for transmitting data by a mobile device instead of a vehicle. The method may comprise obtaining, by the mobile device, a vehicle capability related to the vehicle, where the vehicle capability represents one or more sensors of the vehicle. The method may further comprise determining, by the mobile device, a mobile device capability representing one or more sensors, processing resources, or both of the mobile device. The method may further comprise obtaining, by the mobile device, from a credential authority, one or more transmission credentials for vehicle-to-everything transmission, based at least in part on the vehicle capability and the mobile device capability. The method may further comprise, in response to obtaining one or more transmission credentials for vehicle-to-everything transmission, transmitting, by the mobile device via one or more transceivers, one or more data messages on behalf of the vehicle using the one or more transmission credentials.

[0006]

[0006] Some embodiments may include a mobile device. The mobile device may include a memory storing executable instructions for transmitting data by the mobile device instead of a vehicle, and one or more processors communicatively coupled to the memory. In some embodiments, the one or more processors are configured to execute instructions to cause the mobile device to perform an operation. The operation may include obtaining vehicle functions related to the vehicle by the mobile device, where the vehicle functions indicate one or more sensors of the vehicle. The operation may further include determining, by the mobile device, mobile device functions indicating one or more sensors, processing resources, or both of the mobile device. The operation may further include obtaining, by the mobile device from a certification authority, one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, at least partially based on the vehicle functions and the mobile device functions. The operation may further include transmitting, by the mobile device via one or more transceivers, one or more data messages on behalf of the vehicle using the one or more transmission authentication information in response to obtaining the one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission.

[0007]

[0007] Some embodiments may include a non-transitory computer-readable medium. The non-transitory computer-readable medium may store instructions for transmitting data by a mobile device instead of a vehicle. In some embodiments, when the instructions are executed by one or more processors of the mobile device, the one or more processors are caused to perform operations. The operations may include obtaining, by the mobile device, vehicle functions related to the vehicle, where the vehicle functions indicate one or more sensors of the vehicle. The operations may further include determining, by the mobile device, mobile device functions that indicate one or more sensors, processing resources, or both of the mobile device. The operations may further include obtaining, by the mobile device, from a certification authority, one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, at least partially based on the vehicle functions and the mobile device functions. The operations may further include transmitting, by the mobile device, via one or more transceivers, one or more data messages on behalf of the vehicle using the one or more transmission authentication information, in response to obtaining the one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission.

[0008]

[0008] Some embodiments may include a mobile device that transmits data by the mobile device instead of a vehicle. In some embodiments, the mobile device includes means for obtaining vehicle functions related to the vehicle by the mobile device, and the vehicle functions indicate one or more sensors of the vehicle. The mobile device may further include means for determining mobile device functions indicating one or more sensors of the mobile device, processing resources, or both. The mobile device may further include means for obtaining, from a certification authority, one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, at least partially based on the vehicle functions and the mobile device functions. In response to obtaining the one or more transmission authentication information, the mobile device may further include means for transmitting one or more data messages to at least one other vehicle via one or more transceivers, instead of a vehicle that utilizes the one or more transmission authentication information.

Brief Description of the Drawings

[0009]

Figure 1

[0009] A simplified block diagram showing an exemplary V2X environment according to one embodiment.

Figure 2

[0010] A flowchart showing a method for obtaining transmission authentication information instead of a vehicle according to one embodiment.

Figure 3

[0011] A flowchart showing a method for obtaining transmission authentication information instead of one or more third-party sensors according to one embodiment.

Figure 4

[0012] A flowchart showing a method for using a plurality of mobile devices to determine V2X transmission data according to one embodiment.

Figure 5A

[0013] A diagram showing a technique for assigning a trust value to one or more entities in a V2X environment according to one embodiment.

Figure 5B

Figure 5C

Figure 6

[0014] Diagram showing an exemplary technique for providing a real-time traffic model according to at least one embodiment.

Figure 7

[0015] Diagram showing an exemplary technique for utilizing messages directed in a V2X environment according to at least one embodiment.

Figure 8

[0016] Flowchart showing a method for managing data transmission by a mobile device in place of a second device in a V2X environment.

Figure 9

[0017] Diagram of a system in which a V2X-enabled device (e.g., a vehicle, a proxy device, an RSU, a server, etc.) can communicate via various networks according to an embodiment.

Figure 10

[0018] Functional block diagram of a vehicle according to an embodiment.

Figure 11

[0019] Block diagram of various hardware and software components of a vehicle according to an embodiment.

Figure 12

[0020] Perspective view of an exemplary vehicle according to an embodiment.

Figure 13

[0021] Functional block diagram of an exemplary mobile device (e.g., a proxy device) according to an embodiment.

DETAILED DESCRIPTION OF THE INVENTION

[0010]

[0022] According to some exemplary implementations, like reference numerals in the various drawings indicate like elements. Additionally, multiple instances of an element can be indicated by following a first number and a second number for an element having a letter or a hyphen. For example, multiple instances of element 109 can be indicated as 109-1, 109-2, 109-3, etc., or as 109, 109, 109, etc. When indicating such an element using only the first number, any instance of the element should be understood (e.g., element 110 in the previous example refers to elements 109-1, 109-2, and 109-3, or elements 109a, 109b, and 109c).

[0011]

[0023] Next, some exemplary embodiments will be described with respect to the accompanying drawings that form a part of this specification. Specific embodiments in which one or more aspects of the present disclosure can be implemented are described below, but other embodiments may be used and various modifications can be made without departing from the scope of the present disclosure or the spirit of the appended claims.

[0012]

[0024] A V2X-enabled vehicle can execute a vehicle-to-vehicle (V2V) safety application centered around the Society of Automotive Engineers (SAE) J2735 BSM that communicates position and motion data about the vehicle's position, time, heading direction, speed, acceleration, predicted path, path history, etc. Other V2X messages can include, but are not limited to, cooperative awareness messages (e.g., used to inform about the position, movement, and basic attributes of the transmitting device), distributed environment notification messages (e.g., utilized to report the detection of traffic events or road hazards), signal phase and timing messages (e.g., information about one or more traffic signals), in-vehicle information messages (e.g., used to provide static or dynamic road sign information for in-vehicle display), map messages (e.g., used for road terrain and geometry information), etc.

[0013]

[0025] Not all vehicles are V2X - compliant. Vehicles lacking the ability to send and / or receive V2X messages are referred to herein as legacy vehicles (LV). Some of the techniques provided herein are directed to the use of a mobile device as a proxy device that receives and / or sends and / or processes data on behalf of a legacy vehicle. A mobile device (e.g., a smartphone, smartwatch, laptop, tablet, etc.) can be a device separate from the vehicle when manufactured. In some embodiments, the mobile device can be an after - market - added sensor. The mobile device can be a device different from any of the legacy vehicle's devices when manufactured. V2X - compliant vehicles and proxy devices may be collectively referred to herein as V2X user devices.

[0014]

[0026] In addition to sending position and motion data about the V2X user device itself / its corresponding V2X vehicle, the V2X user device can send position and motion data and / or any suitable sensor data that it acquires about other vehicles and / or objects. In some embodiments, one or more sensors of the vehicle function may be associated with corresponding trust values indicating the accuracy associated with the sensor data collected by these devices. These corresponding trust values may be initially verified based at least in part on predetermined data stored in the V2X user device, or these values may be assigned to the data by another V2X participant and / or a certification authority of the V2X environment, as will be described in more detail below. The V2X user device can send the corresponding trust values along with the sensor data it transmits.

[0015]

[0027] In some embodiments, the V2X user device may be configured to obtain and transmit vehicle capabilities. As used herein, "vehicle capabilities" may describe one or more attributes of a V2X vehicle (e.g., the V2X vehicle itself, a V2X vehicle in which the mobile device operates as a proxy). By way of example, vehicle capabilities may include one or more images of the vehicle, one or more identifiers associated with the vehicle (e.g., license plate, vehicle identification number (VIN), model, make, year of manufacture, type of vehicle (e.g., SUV, passenger car, truck, sedan, etc.)), one or more functions of the vehicle (e.g., one or more ADAS functions, braking distance, sensors of the vehicle when manufactured, aftermarket sensors added to the vehicle), one or more physical attributes of the vehicle (e.g., color, dents and dent locations (e.g., within the left rear fender), rust / rust locations, cracked rear glass, 4 doors, hatchback, presence and state of sunroof (e.g., open, closed), presence and state of moonroof (e.g., open, closed), roof rack / roof rack configuration, bike rack / bike rack configuration, presence of trailer hitch, towing of trailer (and in some embodiments aspects of the trailer, etc.), or any suitable combination thereof. In some embodiments, vehicle capabilities may be provided by a user via a user interface of the vehicle and / or via a mobile device that is separate from the vehicle but communicates with a V2X-enabled vehicle.

[0016]

[0028] In some embodiments, the V2X user device may be further configured to transmit occupant metadata (also referred to herein as "occupant data"). As used herein, "occupant metadata" includes an identifier of the occupant (e.g., alphanumeric identifier, first name, middle name, last name, prefix, suffix, etc.), one or more driving credentials associated with the occupant (e.g., driver's license, commercial driver's license, driving certificate, driving permit, etc.), one or more attributes of the occupant (e.g., height, hair length, skin color, age, vision, reflexes, etc.), driving experience data associated with the occupant (e.g., number of years of experience, driving aggressiveness, number of accidents, number of at-fault accidents, etc.), one or more co-occupant attributes of the occupant (e.g., tendency to get car sick, sensitivity (e.g., sensitive to light, speed, temperature, traffic, noise, etc.)), etc., or any suitable combination of the above. In some embodiments, the occupant metadata may be provided via the vehicle's user interface and / or via a mobile device that is separate from the vehicle but is communicating with a V2X-enabled vehicle. Various techniques for obtaining vehicle functions and / or occupant metadata are more fully described below.

[0017]

[0029] Each V2X-enabled device in a V2X environment (e.g., a V2X vehicle, a proxy device, a roadside unit, etc.) may be required to obtain a transmission authority before it can be enabled to send data to other devices. In some embodiments, a V2X-enabled device may be required to register its functions (e.g., an ADAS function, one or more sensors, etc.) with a certification authority in order to obtain a registration certificate. In some embodiments, the registration certificate may be stored on the V2X-enabled device during manufacturing. The certification authority may determine whether the functions of the V2X-enabled device meet any suitable combination of transmission requirement thresholds related to the V2X environment (e.g., an accuracy threshold, a latency threshold, a throughput threshold, etc.). If so, the certification authority may provide a registration certificate. The registration certificate may include a device identifier, a trust value corresponding to those devices, an identifier of the certification authority, or any suitable one of the above. The V2X-enabled device may provide its registration certificate in order to obtain one or more transmission certificates (from, for example, a registration authority that may be the same as or different from the certification authority). The certification authority and the registration authority may be collectively or individually referred to as a "credential authority", and the various certificates provided by the certification authority and / or the registration authority may be individually referred to as "credentials". The credential used for transmission may be referred to as transmission credential, and the credential used for reception may be referred to as reception credential. In some embodiments, these transmission certificates are provided within the message sent by the V2X-enabled device and can be used by the recipient to verify the message. If the V2X-enabled device does not obtain the transmission certificate first, it may be configured not to send location data and movement data, vehicle functions, and / or passenger data. In some embodiments, a proxy device may be mainly used to receive V2X data but not used to send via the V2X network (perhaps because it does not meet the transmission requirement threshold).In these scenarios, the VCD may request a receipt certificate from the registration authority. If the VCD does not obtain the receipt certificate initially, it may be configured to discard V2X messages.

[0018]

[0030] A V2X - enabled device (VCD) can receive V2X messages from remote devices (e.g., nearby V2X - enabled vehicles within the communication range, roadside units, nearby proxy devices (PD), etc., which are called remote vehicles (RV) in this specification). For example, a nearby VCD can broadcast BSM messages up to 10 times per second (10 Hz). Thus, if a VCD is surrounded by 200 VCDs (within the threshold distance of the VCD) and each communicates up to 10 BSMs per second, the VCD may need to process up to 2000 BSM messages per second. This processing can include verifying the digital signature of the message and, based on the content of the message, determining whether to provide driver assistance information (e.g., alerts, alarms, graphical data, and / or audible data, etc.) to the driver, whether to change or execute maneuvers, whether to store the received data element, whether to re - transmit the received data element, whether to assign a trust value, and / or whether to adjust the trust value, etc. Further, additional message types (e.g., non - BSM safety messages) may also be communicated to the VCD from nearby VCDs, and other communications can be received from other remote devices such as roadside units (RSU), traffic - related servers, etc. Moreover, the information communicated by BSMs and other messages is often extremely time - constrained and must be processed quickly by the VCD before it becomes irrelevant. Thus, VCDs often have limited capabilities to delay the processing of these incoming messages. This can impose a high processing load on the hardware blocks of the PD (e.g., central processing unit (CPU), digital signal processor (DSP), and / or elliptic curve digital signature algorithm (ECDSA)). Generating and / or providing driver assistance information (e.g., alerts, alarms, graphical displays, audible displays, maps, models, etc.) from V2X messages utilizes the processing resources of the VCD (and potentially the processing resources of the LV if the output device of the LV is utilized for the display of driver assistance information).Storing data elements from received messages (e.g., additional vehicle capabilities provided by a remote device) can utilize the memory resources of a mobile device. Assigning and / or adjusting trust values corresponding to sensors and / or sensor data can utilize the processing resources of the VCD. Therefore, it is important for the VCD to include a function to filter out irrelevant messages in order to prevent unnecessary waste of the VCD's processing and / or memory resources.

[0019]

[0031] Using the techniques disclosed herein, a V2X network can include mechanisms to ensure that only approved devices can receive data via the V2X network. Additionally, the V2X network can be managed such that only devices that meet some threshold level of accuracy, latency, and / or throughput can transmit data via the V2X network, thus ensuring at least a threshold performance level of the network. By transmitting the data described herein, a message recipient can be made aware of other vehicles (and potentially information regarding the vehicle and its occupants) even if the device lacks line of sight, is not collecting any sensor data corresponding to that vehicle, and / or is outside the reception range for receiving the message from its original source. Additionally, the receiving device can be enabled to confirm the degree to which the data should be trusted (e.g., how accurate the data can be). By leveraging this information from multiple sources, a device can be made aware of not only its own attributes but also those of others. These attributes, or identifiers agreed upon by some V2X participants, are used such that V2X messages can be directed to specific recipients, thus potentially reducing the number of messages processed by individual devices of the network. The data received via V2X messages can be used to inform the movement and execution of maneuvers of nearby vehicles. As a result, the accuracy, latency, and network throughput of the data are extremely important.

[0020]

[0032] FIG. 1 is a simplified block diagram showing an exemplary environment 100 (e.g., a V2X environment) according to one embodiment. By way of example, FIG. 1 shows a mobile device 102 being utilized as a proxy device for vehicle 104. In the example given in FIG. 1, mobile device 102 may be configured to receive and / or transmit data via network 108 (e.g., a cellular network, a WiFi® network, any suitable network configured for V2X communication, etc.) on behalf of vehicle 104. In some embodiments, vehicle 104 lacks communication functions and / or components for environment 100. That is, vehicle 104 (an example of a legacy vehicle) is unable to transmit and / or receive V2X data messages (e.g., data message 106, V2X messages) via network 108. Data message 106 may be transmitted by any suitable remote device (e.g., RV 110, roadside unit 112, or any suitable V2X capable device (VCD) different from mobile device 102, a device being utilized to transmit and receive V2X messages for vehicle 104). It should be understood that mobile device 102 may be temporarily placed within vehicle 104 and utilized as a proxy device to transmit and / or receive V2X messages on behalf of vehicle 104. In other embodiments, vehicle 104 may be a V2X capable vehicle configured to transmit and receive V2X messages via network 108. In any scenario, mobile device 102 and vehicle 104 may be communicatively coupled (e.g., via network 108, Bluetooth® pairing, etc.) such that data may be exchanged between the mobile device and the vehicle. In some embodiments, vehicle 104 may be configured with one or more third party sensors 105 (e.g., one or more aftermarket sensors).

[0021]

[0033] In some embodiments, mobile device 102 and / or vehicle 104 may be utilized to obtain registration data 114. Registration data 114 may include, in some embodiments, any suitable combination of vehicle functions that describe the attributes of vehicle 104 and / or passenger metadata that describes one or more passengers (e.g., a driver, one or more passengers) of vehicle 104.

[0022]

[0034] In some embodiments, registration data 114 may be obtained during the generation of a trip session or at any suitable time. A trip session may be initiated by mobile device 102 and / or vehicle 104 (each referred to as a registration device) via any suitable graphical interface and / or audible interface (e.g., voice commands) using the input and / or output devices of the registration device. Mobile device 102 and vehicle 104 may be communicatively connected via any suitable communication channel (e.g., WiFi, Bluetooth, cellular, etc.) and may communicate registration data 114 between each other. Either or both devices may store registration data 114 in local memory.

[0023]

[0035] In some embodiments, a trip session may be automatically generated based on context (e.g., as a result of one or more determinations). For example, any registered device may be configured to determine that it is being used or may be used for transportation. By way of example, any registered device may be determined to be used for navigation based at least in part on determining that a Bluetooth pairing procedure (e.g., a pairing procedure performed using mobile device 102 and vehicle 104) has been completed, based on determining that the speed at which the registered device is moving exceeds a threshold, based on detecting a voice signature in a vehicle cabin, etc., and / or may be determined to be used for transportation. In some embodiments, a registered device may generate a trip session in response to determining, via any of the determinations described above, that it is being used or may be used for transportation.

[0024]

[0036] Registration data from previous trip sessions may be stored in the registration device, may be selectable, or the user may select an option to create new registration data. Any selected registration data may be modifiable by the user via the registration device. The registration device may then be used to obtain any suitable portion of the vehicle functions using one or more interfaces and / or one or more input / output devices (e.g., keyboard, microphone, camera, display, speaker, etc.). For example, in some embodiments, the registration device may display a graphical interface that may provide any suitable user input for the user to identify any suitable portion of the vehicle functions. In some embodiments, the registration device may be configured to audibly request the user to provide the vehicle functions of the vehicle (e.g., by voice, via a graphical interface). The mobile device and / or the vehicle may be configured to receive such user input and store the received data in an object (or another suitable storage container) associated with the vehicle as a vehicle function.

[0025]

[0037] In some embodiments, the camera of the mobile device 102 can be utilized to capture one or more images of the vehicle 104. The mobile device 102 can be configured to utilize any suitable image recognition technique to identify one or more vehicle attributes from one or more images (e.g., still images, videos, etc.). By way of example, the mobile device can store a machine learning model that has been pre-trained to identify vehicle attributes from input data (e.g., one or more images of a vehicle). In some embodiments, the machine learning model can be pre-trained using any suitable supervised, unsupervised, semi-supervised, and / or reinforcement learning techniques. By way of non-limiting example, the machine learning model may be trained using a supervised learning technique (e.g., classification algorithms, regression analysis, etc.), in which a model (e.g., a function) for predicting an output from an input is determined by analyzing a training data set that includes examples in which vehicle attributes have been previously identified. For example, the training set can include an exemplary set of one or more images that have been previously labeled as indicating one or more vehicle attributes and / or images that have been previously identified as lacking one or more vehicle attributes. Any suitable number of vehicle attributes (e.g., color, make, model, year, dents, broken windows, scratches, license plate number, VIN number, registration tab data, etc.) can be captured at least partially based on the images captured by the mobile device 102.

[0026]

[0038] Rider data can be obtained using one or more graphical interfaces and / or audible interfaces of the registration device in a manner similar to that described above with respect to vehicle functions. By way of example, the registration device can be utilized to provide rider information that may be stored in the mobile device 102 and / or the vehicle 104 to the driver of the vehicle 104 and / or one or more passengers. In some embodiments, the registration device may communicate with a plurality of mobile devices (e.g., the mobile devices of a number of passengers). Each of these plurality of mobile devices may store rider data for its corresponding user. Thus, the registration device can obtain rider data from one or more of the other mobile devices via any suitable communication channel (e.g., Bluetooth, WiFi, cellular).

[0027]

[0039] Any suitable combination of the vehicle functions and / or passenger metadata of the registration data 114 can be used to process data messages and / or operate the vehicle and / or execute operations. As an example, any suitable combination of the registration data can be used to determine whether a received data message is relevant to the vehicle. For example, the physical attributes and / or identifiers of the previously stored vehicle functions can be compared with the attributes provided in the message to identify whether a portion of the data provided in the message is relevant to the vehicle (e.g., more than a threshold number of the message's attributes match the vehicle attributes of the vehicle function). If so, the message can be processed (e.g., by a receiving device that can be the vehicle 104 in some embodiments or a mobile device 102 that operates as a proxy for the vehicle in other embodiments). Otherwise, the message (or a portion of the message) can be discarded and / or ignored. As another example, a data message can be considered relevant if the data corresponding to the vehicle attributes indicates a location within a threshold distance of a known location of the vehicle. Thus, the vehicle and / or proxy device can store vehicle functions and / or passenger metadata obtained from multiple sources (e.g., input by the user, received from a remote device, etc.). Thus, the received vehicle and / or passenger data can be used to extend the registration data 114. Any suitable rule set can be used to determine which data should be used when conflicting data occurs. In some embodiments, data input by the user can be prioritized over data received from V2X data messages. Thus, in some embodiments, the received data may not overwrite the data input by the user. In other embodiments, the data input by the user can be prioritized until a threshold number of conflicting information is received and / or received from a threshold number of sources. If either or both of these thresholds are met, the received data can be used to replace the data input by the user stored in the registration device.

[0028]

[0040] Any suitable portion of the registration data 114 may be classified by an indicator that specifies how the data persists. Some data may be classified as being valid only during a trip session (e.g., until the vehicle 104 reaches its destination, is turned off, etc.) and may be deleted when the trip session is complete. Other data (e.g., driver's license number, license plate number, driving experience, etc.) may typically be classified as persistent and may remain until manually deleted and / or modified by the user.

[0029]

[0041] In some embodiments, the environment 100 may include a certification authority 116. The certification authority 116 may be any suitable entity (e.g., a state or federal government agency, a network provider of the network 108, etc.). In some embodiments, a device (e.g., the vehicle 104, the mobile device 102) may provide to the certification authority 116 a portion of the registration data (e.g., one or more functions, and / or one or more sensors, and / or data indicating one or more components such as the processing and memory resources of the device) in exchange for a registration certificate (not shown). In some embodiments, the registration certificate may be stored in the memory of the device during manufacture or at any suitable time. In some embodiments, the registration certificate may include authentication information related to the certification authority 116 (e.g., the public key of a public / private key pair related to the certification authority, an identifier of the certification authority, an identifier of the device, etc.). The registration certificate may be utilized by the device to request one or more transmission certificates and / or reception certificates from the registration authority 118. In some embodiments, the certification authority 116 and the registration authority 118 may be provided by the same entity (e.g., a government agency) and / or system. The method for obtaining the registration certificate, the transmission certificate, and / or the reception certificate will be described in further detail with respect to FIGS. 2-4.

[0030]

[0042] In some embodiments, each transmitting device of network 108 may be required to provide its respective certificate along with each data message transmitted via network 108. In some embodiments, a portion of the data of each data message may be encrypted and / or digitally signed (e.g., using the private key of the transmitting device). A certificate issued by certificate authority 116 may comprise the public key of the transmitting device signed by the private key of the certificate authority. In some embodiments, the public / private key may be generated by the transmitting device and provided to certificate authority 116 when requesting a registration certificate or at any suitable time. In some embodiments, a device that receives a data message may utilize the public key of certificate authority 116 (e.g., known from a registration certificate) to obtain the public key of the transmitting device in order to decrypt a portion of the data message encrypted with the private key of the transmitting device. Additionally or alternatively, the public key of the transmitting device may be utilized to verify the digital signature of the data message, the digital signature being generated using the private key of the transmitting device.

[0031]

[0043] Although only one mobile device, vehicle, remote vehicle, and roadside unit are shown in FIG. 1, it should be understood that any suitable number of such devices may be utilized. In some embodiments, RV110 may transmit data message 106. Data message 106 may be broadcast (e.g., via a network identifier by which vehicle 104 is known within network 108 and / or through including one or more vehicle attributes of vehicle 104 that are different from the network identifier) and / or may be directed to vehicle 104. Vehicle 104, or mobile device 102 operating as a proxy for vehicle 104 (a set referred to as the “receiving device”), may be configured to receive data message 106. The receiving device may compare vehicle attributes received via one or more data elements (e.g., data fields) of data message 106 with vehicle functions stored in the receiving device. In some embodiments, the receiving device may be configured to process the data message when the network identifier of the message matches the network identifier stored in registration data 114 and / or when a threshold number of data elements of the received message match vehicle attributes stored as registration data 114. In some embodiments, the receiving device may discard (or process fewer data elements of the data message) when the network identifier of data message 106 does not match the network identifier stored in registration data 114 and / or when the number of vehicle attributes of data message 106 cannot match the threshold number of vehicle attributes stored in registration data 114.

[0032]

[0044] In some embodiments, the receiving device may process or discard the received data message based at least in part on the passenger metadata of the registration data 114. By way of example, certain types of messages may be processed (or discarded) when the driver is a relatively inexperienced driver (e.g., the passenger is the current driver and the passenger data indicates that the driver has less than one year of driving experience), but these messages may be discarded (or processed) when it is known that the driver is an experienced driver (e.g., a driver with more than one year of experience). In some embodiments, the receiving device is configured to process (or discard) a particular type of data message (e.g., data message 106) when the driver of the vehicle 104 is associated with passenger data indicating that the driver has been in a threshold number of accidents (e.g., one or more, two or more, etc.) and / or a threshold number of a particular type of accident (e.g., an accident where the driver rear-ended another vehicle, an accident where the driver came into contact with another vehicle, etc.). The receiving device may be configured to discard the data message if those conditions are not met, as indicated by the passenger metadata.

[0033]

[0045] The receiving device may be configured to perform any suitable operation based at least in part on processing the data message 106. By way of example, the receiving device (e.g., a mobile device or vehicle 104 that operates as a proxy for vehicle 104 if vehicle 104 is V2X compliant) may be configured to generate driver assistance information 122. The driver assistance information 122 may include any suitable combination of graphical and / or audible presentations that inform the driver of any suitable conditions (e.g., weather conditions, road conditions, other driver actions such as hard braking, all V2X devices within the environment 100 within a threshold distance of vehicle 104 or mobile device 102 when mobile device 102 is functioning as a proxy for vehicle 104, and at least the position of the sensed vehicles), and a real-time model. The driver assistance information 122 may be displayed via one or more output devices (e.g., a display and / or a speaker) of the mobile device 102 and / or via one or more output devices of the vehicle 104. The real-time traffic model is described later with respect to FIG. 6. The real-time traffic model of FIG. 6 is intended to be an example of the driver assistance information 122.

[0034]

[0046] In some embodiments, additional vehicle functions may be provided via data message 106. As an example, mobile device 102 operating as a proxy for vehicle 104 may not currently store the color (or any suitable physical attribute) of vehicle 104. However, RV110 may utilize one or more of its sensors (e.g., a camera) to identify that vehicle 104 is white. RV110 may transmit this vehicle attribute (and / or any suitable number of vehicle attributes identified by sensor data collected by its sensors) in data message 106. The receiving device may be configured to store this additional vehicle function (e.g., as part of the vehicle functions of registration data 114, separately from the vehicle functions of registration data 114) upon receipt. The receiving device may be configured to store this additional vehicle function when it is determined that the received vehicle function is relevant to the receiving device (e.g., describes either the manner of the receiving device or the manner of the vehicle for which the receiving device operates as a proxy). Determining such a relationship is described in more detail below. In some embodiments, if the receiving device can identify that it is the only device within the threshold distance of RV110, the receiving device may determine that any vehicle attributes provided in the message are relevant and may immediately store the received vehicle attributes in local memory along with the vehicle function.

[0035]

[0047] In some embodiments, the receiving device may be configured to temporarily store vehicle functions received from a remote device until it receives the same data more than a threshold number of times from a threshold number of sources (e.g., a threshold number of remote devices). In some embodiments, the data temporarily stored may be stored separately from more reliable data (e.g., data provided by the user, pre-verified data, etc.). By way of example, the data temporarily stored may be stored in a separate object, log, or data container different from the data container used to store the currently known registration metadata (including vehicle functions) of the vehicle. In some embodiments, the receiving device may be configured to store additional vehicle functions (e.g., white) with the registration data 114 only after being received by at least a threshold number of different sources with the same attribute (e.g., three different V2X vehicles, two V2X vehicles and one roadside unit, one V2X vehicle and two proxy devices, four different sources, etc.). Thus, the receiving device may be configured to obtain vehicle functions from other devices in the environment 100. In some embodiments, the vehicle metadata provided by the user may be prioritized over vehicle functions provided by any other source. That is, in some embodiments, the data provided by the user may not be overwritten by vehicle functions received from a remote device. In some embodiments, the data provided by the user may remain until the same vehicle function value is received from a plurality of different sources and is determined to correspond to the receiving device (or its associated vehicle).

[0036]

[0048] It should be understood that the mobile device 102 need not transmit any V2X messages in place of the vehicle 104. In other embodiments, the mobile device 102 may transmit a V2X message indicating that the mobile device 102 is functioning as a proxy for the vehicle 104. In some embodiments, other transmitting devices (e.g., RV 110 and / or roadside unit 112, other proxy devices) may utilize this knowledge when transmitting messages (e.g., via a real-time model presented in those vehicle / proxy devices) and / or when displaying information regarding the vehicle 104. One example may include displaying an indication that the vehicle 104 is a legacy vehicle in a real-time traffic model, based at least in part on receiving from the mobile device 102 a message indicating that the mobile device 102 is operating as a proxy in place of the vehicle 104. In some embodiments, the transmitting device may be configured with a rule set that may cause the transmitting device to modify one or more data elements within the message (or transmit different data elements) if the receiving device is known to be a proxy device (rather than a V2X-capable vehicle).

[0037]

[0049] In some embodiments, a transmitting device (e.g., the mobile device 102 and / or the vehicle 104 operating as a proxy device) may transmit, via the network 108, any suitable combination of registration data and / or sensor data collected from any suitable sensors of the mobile device 102, the vehicle 104, and / or the third-party sensor 105. By way of example, the transmitting device may transmit any suitable combination such as vehicle functions, passenger metadata, position and movement data of the vehicle 104, sensor data indicating the position and / or movement data of one or more vehicles sensed by sensors of the mobile device 102, the vehicle 104, and / or the third-party sensor, sensor data such as one or more images provided by the mobile device 102, and the like.

[0038]

[0050] As a non-limiting example, the transmitting device may transmit data indicating which sensors are being utilized (e.g., by mobile device 102 and / or vehicle 104) to collect sensor data that is also being transmitted within the message. Thus, the receiving device (e.g., RV110) may be able to confirm the degree of accuracy and / or reliability of the provided sensor data (e.g., based at least in part on the particular sensors being used for collection). Thus, if RV110 (or any suitable receiving device) receives sensor data from two sources regarding a common entity (e.g., vehicle 104), the receiving device may be configured to prefer the sensor data provided by the source having the more accurate sensors. In some embodiments, each device in environment 100 may be configured with a set of rules for identifying the accuracy of a predefined number of sensors. In other embodiments, the accuracy is provided within the transmitted data message and may be utilized by the receiver to assess whether the provided sensor data should be used.

[0039]

[0051] FIG. 2 is a flowchart showing a method 200 for obtaining a transmission certificate (e.g., a temporary transmission certificate) in place of a vehicle, according to one embodiment. The method may be performed using any suitable combination of the certificate authority 116, registration authority 118, vehicle 104, mobile device 102, and RV110 of FIG. 1. As described above, in some embodiments, the certificate authority 116 and the registration authority may be provided by the same system. The example shown in FIG. 2 is intended to illustrate a use case in which the mobile device 102 is configured to operate as a proxy device in place of the vehicle 104 for transmission and / or reception purposes. That being said, the operations performed by the mobile device 102 may equally be performed by the vehicle 104 in a scenario where the vehicle 104 is V2X capable.

[0040]

[0052] This method may start at 202, where mobile devices 102 and 104 may execute any suitable connection procedure (e.g., Bluetooth pairing procedure) to establish a communication connection between mobile device 102 and vehicle 104.

[0041]

[0053] At 204, the registration data may be obtained by mobile device 102 using the techniques described above with respect to FIG. 1. It should be understood that all or part of the registration may alternatively be obtained by vehicle 104 and communicated to mobile device 102 via the connection established at 202.

[0042]

[0054] At 206, mobile device 102 may send any suitable portion of the vehicle functionality to certification authority 116. In some embodiments, the sent vehicle functionality may include identifiers of any suitable hardware and / or software ADAS functionality of vehicle 104, any suitable sensors of vehicle 104 and / or any suitable sensors of mobile device 102 (or any other device paired with vehicle 104), any suitable identifiers of one or more processing devices (e.g., processors) of the device used for transmission (in this case, mobile device 102), and / or any suitable attributes of vehicle 104 and / or mobile device 102. In embodiments where vehicle 104 includes one or more third-party sensors (e.g., third-party sensor 105 of FIG. 1), a sensor identifier for each of those third-party sensors may be sent to certification authority 116 at 206. In use cases where vehicle 104 is V2X compliant and the mobile device is not used as a proxy or for sensor data collection, vehicle 104 may provide certification authority 116 with identifiers of any suitable combination of its ADAS functionality, on-board sensors, and / or third-party sensors.

[0043]

[0055] At 208, the certification authority 116 may be configured to determine whether various functions, sensors, and / or processing devices meet the threshold requirements for participation in the V2X network (e.g., network 108 of FIG. 1) according to a predefined set of rules. In some embodiments, the certification authority 116 may enforce different threshold requirements for registration as a receiving device of network 108 than for registration as a transmitting device of network 108. By enforcing a transmission threshold requirement, the certification authority 116 can ensure that the processing devices and sensors being utilized for transmission meet the predefined accuracy, latency, and throughput requirements of the V2X network. In some embodiments, enforcing a reception threshold requirement may enable the certification authority 116 to ensure that only a certain type of device can reliably receive data from the V2X network.

[0044]

[0056] The requirements at 206 may indicate whether registration is required for reception and / or transmission. In some embodiments, a reception registration certificate may be provided to enable a device to receive data via the V2X network, and a different transmission registration certificate may be provided to enable a device to transmit data via the V2X network. In some embodiments, the reception registration certificate and / or the transmission registration certificate may be associated with several certificate levels. By way of example only

[0057] In some embodiments, mobile device 102 may include a request type identifier within the data transmitted at 206. The request type identifier may indicate the type of certificate being requested. In some embodiments, different types of registration certificates may be requested from and provided by certification authority 116. By way of example, a received registration certificate may specify a particular type of data that can be received and processed by the holder of the received registration certificate. The receiving device (e.g., mobile device 102) may be configured to discard all or a portion of a data message that includes data not permitted by its received registration certificate.

[0045]

[0058] Similarly, a transmitted registration certificate may specify a transmission level corresponding to a particular type of data that the transmitting device (e.g., mobile device 102) is permitted to transmit. By way of example, a transmitted registration certificate may specify that the holder of the registration certificate is given an extended passive transmission level, an active transmission level, or an extended active transmission level. A transmitting device given an extended passive transmission level is granted permission to transmit data indicating that it is a proxy device listening on the V2X network. Transmitting data indicating that a proxy device is listening may enable mobile device 102 to affect the data transmitted by other nearby devices. For example, nearby V2X devices may restrict the data they transmit (e.g., due to privacy, power usage, heat concerns, etc.) until a device is recognized as listening. In some embodiments, the data transmitted when it is known that a proxy device is listening and / or the protocol used by other V2X devices for transmission may be different from the data / protocol used when it is not known that a proxy device is listening.

[0046]

[0059] In some embodiments, the active transmission level may provide the certificate holder with permission to transmit any suitable combination of any data permitted by the extended passive transmission level, as well as registration data (e.g., registration data 114 of FIG. 1) including vehicle functions and passenger metadata, sensor data collected by any suitable sensors of the mobile device 102, and / or any suitable data verified by the mobile device 102 via one or more images (e.g., images of vehicle gauges and / or consoles where speed, turn signal usage, warning lights, etc. can be determined using any suitable image recognition technique). In some embodiments, a proxy device such as the mobile device 102 may be restricted from transmitting some types of data that are permitted to be transmitted by a V2X-enabled vehicle.

[0047]

[0060] In some embodiments, the extended active transmission level may provide the certificate holder with permission to transmit any suitable data permitted by the extended passive transmission level and the active transmission level, as well as any suitable sensor data collected by one or more third-party sensors of the vehicle 104. In some embodiments, the mobile device 102 may be configured to authenticate sensor data that is being routed through the sensor data for transmission. Authenticating the sensor data may include adding a registration certificate to the sensor data prior to transmission. The registration certificate may be described in more detail below.

[0048]

[0061] In some embodiments, the certification authority 116 may store different accuracy, latency, and / or throughput thresholds depending on the transmission level. In some embodiments, at 206, a particular transmission level may be required, and at 208, the certification authority 116 may be configured to determine whether the data received at 206 meets the accuracy, latency, and / or throughput thresholds for the required transmission level. In other embodiments, the certification authority 116 may be configured to identify the highest transmission level at which the corresponding accuracy, latency, and / or throughput requirements are met. The data received at 206 may, additionally or alternatively, include a request for a received registration certificate. The certification authority 116 may be configured to determine whether to grant the requesting device (e.g., mobile device 102) permission to receive data via the V2X network in response to receiving a request for a received registration certificate. In other embodiments, the certification authority 116 may determine whether a received registration certificate should be granted regardless of whether the data received at 206 indicates a request for a received registration certificate.

[0049]

[0062] At 210, the certification authority 116 may transmit any suitable combination of received registration certificates and / or transmitted registration certificates provided as a result of the operations performed at 208. In some embodiments, the certificate may include an identifier of the certification authority 116 and may be individually encrypted with a private key associated with the certification authority 116 (e.g., the private key of a public / private key pair). In some embodiments, the public key of the certification authority may be provided to the registration authority 118 and / or the mobile device 102 at any suitable time.

[0050]

[0063] In some embodiments, it should be understood that the functionality provided by the certification authority 116 can be provided, additionally and / or alternatively, by any suitable V2X-enabled device. That is, any suitable V2X-enabled device can store predefined accuracy, latency, and / or throughput thresholds, as well as any suitable predefined data indicative of the accuracy, latency, and / or throughput associated with the sensors and / or processing devices. Thus, the data transmitted by the mobile device 102 at 206 can alternatively be transmitted (or broadcast) to any suitable V2X-enabled device such that the V2X-enabled device that receives the data can provide a received and / or transmitted registration certificate in a manner similar to that described above with respect to the certification authority 116. When provided by a V2X-enabled device, the certificate can be encrypted with the private key associated with the V2X-enabled device whose corresponding public key is known to the registration authority 118 by virtue of a previous interaction between the V2X-enabled device and the registration authority 118.

[0051]

[0064] When a received registration certificate is provided at 210, at 212, the mobile device 102 can be configured to begin receiving data from the network 108 (e.g., from any suitable remote device such as the RV110 of FIG. 1). In some embodiments, the software and / or hardware of the mobile device 102 can be configured to restrict data reception according to the received registration certificate.

[0052]

[0065] At 214, mobile device 102 may request a temporary transmission certificate by providing its transmission registration certificate to registration authority 118. In some embodiments, registration authority 118 may be configured to manage temporary transmission certificates for all of the transmitting devices on network 108. The temporary transmission certificate may be required to be included in any data message transmitted via network 108. The temporary transmission certificate may be used by the receiving device to verify that the transmitting device has permission to transmit data via network 108.

[0053]

[0066] At 216, registration authority 118 may verify the certificate received at 214 by decrypting the transmission registration certificate using the public key associated with certification authority 116. Registration authority 118 may verify that the identifier of certification authority 116 is included in the certificate. If registration authority 118 cannot verify that the certificate was provided by certification authority 116, registration authority 118 may discard the data provided at 214. In some embodiments, registration authority 118 may transmit, at 218, data to mobile device 102 indicating that registration authority 118 will not provide a temporary registration certificate to mobile device 102. In the absence of a temporary registration certificate, mobile device 102 may be restricted from transmitting data, or all receiving devices may be configured to discard the message if they determine that the data message is missing a temporary registration certificate even if the data was transmitted. Alternatively, if registration authority 118 can verify that the certificate was generated by the certification authority, registration authority 118 may generate a temporary transmission certificate according to a predetermined protocol.

[0054]

[0067] The temporary transmission certificate generated for mobile device 102 may include the public key associated with mobile device 102. In some embodiments, at 214, the registration authority 118 may generate a public / private key pair for mobile device 102, and mobile device 102 may generate its own public / private key pair and provide its public key to registration authority 118 along with its transmission registration certificate. The registration authority 118 may maintain an association between mobile device 102 and its public key or between mobile device 102. To generate the temporary transmission certificate, the registration authority 118 may encrypt the public key of the mobile device and any suitable data associated with mobile device 102 using the private key of the registration authority. The temporary transmission certificate may be utilized over a temporary time period (e.g., one week, one day, one month, twelve hours, etc.) enforced by the registration authority 118. When the temporary transmission certificate is generated, at 218, mobile device 102 may receive the certificate and public key of the registration authority 118 and store the received data in local memory. If a public / private key pair for mobile device 102 is generated by the registration authority 118, at 218, the private key may also be provided.

[0055]

[0068] At 220, mobile device 102 may begin to transmit data via network 108 in accordance with the permission given by the transmission registration certificate received at 210. For example, mobile device 102 may transmit a BSM data message via network 108. In some embodiments, the software and / or hardware of mobile device 102 may be configured to limit data transmission according to the transmission level provided within its transmission registration certificate. Mobile device 102 may encrypt any suitable portion of the data message using its private key. In some embodiments, the mobile device may generate a digital signature and include it in the message. Mobile device 102 may insert its temporary transmission certificate into the data message prior to transmission. RV110 (e.g., the receiver of a data message from mobile device 102) or any suitable receiver of the data message may be configured to use the public key of the registration authority 118 to decrypt the certificate in order to retrieve the public key of mobile device 102. The public key of mobile device 102 may then be used by the receiving device to decrypt any suitable portion of the data message and verify the digital signature to ensure the authenticity of the sender and / or the integrity of the data message (e.g., ensure that the message has not been altered).

[0056]

[0069] At 222, the registration authority 118 may determine, in accordance with a predetermined protocol, that an expiration date has been reached. In response to this determination, the registration authority 118 may generate a new public / private key pair for itself.

[0057]

[0070] At 224, the registration authority 118 may send its new public key to all previously registered V2X devices (e.g., all transmitting devices that have previously obtained a temporary transmission certificate). Each device that receives this public key may be configured to discard the previously used public key of the registration authority 118 and store this new public key in memory. In some embodiments, each device having a previously provided temporary transmission certificate may be configured to obtain a new temporary transmission certificate in response to receiving the new public key of the registration authority 118. As an example, the mobile device 102 may perform the operations described above at 214 again. The operations at 214 - 224 may be repeated any suitable number of times.

[0058]

[0071] Since the temporary transmission certificate is obtained by the mobile device 102 based at least in part on vehicle functions associated with the vehicle 104, it should be understood that when the mobile device 102 pairs with another vehicle, the mobile device 102 may be configured to request a registration certificate and / or a temporary transmission certificate via method 200 so as to be applicable to the newly paired vehicle.

[0059]

[0072] In some embodiments, the mobile device 102 may be enabled to transmit on the network 108 even if it cannot meet latency, accuracy, and / or throughput requirements. In these scenarios, the mobile device 102 may be required to add metadata indicating its limitations / defects within its transmission message.

[0060]

[0073] Figure 3 is a flowchart showing a method 300 for obtaining one or more transmission authentication information in place of one or more third - party sensors according to an embodiment. In some embodiments, a V2X user device 301 (e.g., a mobile device 102 functioning as a proxy for vehicle 104 in FIG. 1, or vehicle 104 if vehicle 104 is a V2X - compliant device) may be utilized to request a temporary transmission certificate for transmitting sensor data collected by one or more third - party sensors 105 in FIG. 1.

[0061]

[0074] Method 300 may begin at 302 where the V2X user device 301 may exchange any suitable data with the third - party sensor 105 to obtain an identifier associated with the third - party sensor 105. In some embodiments, the data exchanged at 302 may include a public key of a public / private key pair generated by the third - party sensor 105 or the V2X user device 301 in place of each of the third - party sensors 105.

[0062]

[0075] At 304, the V2X user device 301 may transmit the sensor identifier to the certificate authority 116. In some embodiments (e.g., when the V2X user device 301 is transmitting sensor data collected by the third - party sensor 105), the V2X user device 301 may transmit any suitable vehicle function associated with the V2X user device 301 (e.g., a vehicle function corresponding to vehicle 104) along with the sensor identifier. In other embodiments (e.g., when one or more of the third - party sensors 105 are transmitting their own sensor data), a sensor identifier for sensors that may potentially transmit their own sensor data may be provided.

[0063]

[0076] At 306, the certification authority 116 may be configured to identify (e.g., via a predefined rule set) whether the data collected by the third - party sensor 105 meets the accuracy requirements as indicated by the data received at 304, and / or whether the transmitting device (e.g., the V2X user device 301 and / or the third - party sensor 105) is capable of meeting the latency and / or throughput transmission requirements associated with transmitting data messages over the network 108 (e.g., the V2X network). The certification authority 116 may be configured to generate one or more transmission registration certificates for each of the transmitting devices (e.g., for any suitable combination of the V2X user device 301 and / or the third - party sensor 105) determined to meet the accuracy and / or latency transmission requirements. As described above, the transmission registration certificate may indicate the transmission level corresponding to a particular type of data that the certificate holder is enabled to transmit. In some embodiments, the transmitting device may be provided with an extended active registration certificate to enable the transmitting device to transmit sensor data obtained from the third - party sensor 105 (and / or to enable the third - party sensor 105 to transmit its own sensor data over the network 108).

[0064]

[0077] At 310, the certification authority 116 may transmit any generated registration certificate to the V2X user device 301.

[0065]

[0078] At 312, the V2X user device 301 may request a temporary transmission certificate for the third - party sensor 105 by providing each of the transmission registration certificates received at 310 to the registration authority 118. When the V2X user device 301 is the intended transmission device, at 312, the transmission registration certificate provided at 310 and the public key of the public / private key pair generated by and associated with the V2X user device 301 may be provided. When one or more of the third - party sensors 105 are the intended transmission devices, at 312, the registration certificate corresponding to each third - party sensor and the corresponding public key generated at 302 may be provided. As described above, the registration authority 118 may be configured to manage temporary transmission certificates for all of the transmission devices of the network 108.

[0066]

[0079] At 314, the registration authority 118 may verify the certificate received at 312 by decrypting the transmission registration certificate using the public key associated with the certification authority 116. The registration authority 118 may verify that the identifier of the certification authority 116 is included in each certificate. If the registration authority 118 cannot verify that the certificate was provided by the certification authority 116, the registration authority 118 may discard the data provided at 312.

[0067]

[0080] At 316, the registration authority 118 may send data to the V2X user device 301 indicating either that the registration authority 118 will not provide the requested temporary registration certificate (e.g., because the registration authority 118 cannot verify one or more certificates provided at 312), or that the registration authority 118 may provide the temporary transmission certificate generated at 316. If the third-party sensor 105 is the intended transmitting device, the V2X user device 301 may forward the temporary transmission certificate to the third-party sensor 105, and the third-party sensor may then use the temporary transmission certificate at 320 to transmit their respective sensor data over the network 108. The third-party sensor 105 may utilize their temporary transmission certificate to encrypt and / or digitally sign a message (or one or more portions of a message), and the temporary transmission certificate may be included in the transmitted message. At 220, the RV 110 may decrypt and verify the data message using the techniques described above with respect to FIG. 2.

[0068]

[0081] If the V2X user device 301 is the intended transmitter, the operations at 318 and 320 may be skipped, and the method may proceed to 322, where sensor data collected by the third - party sensor 105 may be provided to the V2X user device 301. At 324, the V2X user device 301 may be configured to encrypt and / or digitally sign any suitable portion of the sensor data and transmit the encrypted / digitally signed data, along with a temporary transmission certificate, via the network 108. The temporary transmission certificate transmitted at 320 and / or 324 may include the public key of the transmitting device, signed by the private key of the registration authority 118. Thus, the temporary transmission certificate transmitted at 320 and / or 324 may be used by the receiving device (e.g., RV110) to obtain the public key of the transmitting device for verifying the digital signature and / or decrypting a portion of the received message.

[0069]

[0082] At 326, the registration authority 118 may determine, according to a predetermined protocol, that the expiration date has been reached. In response to this determination, the registration authority 118 may generate a new public / private key pair for itself.

[0070]

[0083] At 328, the registration authority 118 may transmit its new public key to all previously registered V2X devices (e.g., all transmitting devices that previously obtained a temporary transmission certificate for themselves or on behalf of another device). Each device (e.g., V2X user device 301) that receives this public key may be configured to discard the previously used public key of the registration authority 118 and store this new public key in memory. In some embodiments, each device having one or more previously provided temporary transmission certificates may be configured to obtain a new temporary transmission certificate in response to receiving the new public key of the registration authority 118. By way of example, the method may return to 312. The operations from 312 to 328 may be repeated any suitable number of times.

[0071]

[0084] FIG. 4 is a flowchart showing a method 400 for utilizing a plurality of mobile devices to determine V2X transmission data according to one embodiment. FIGS. 1-3 showed a single mobile device functioning as a proxy for a single vehicle, but any suitable number of mobile devices can function as a proxy for a single vehicle. By way of example, mobile device 102 may be the driver's (or passenger's) smartphone of vehicle 104, and mobile device 402 may be a passenger's smartphone of vehicle 104. In some embodiments, the mobile devices may conform to a master / slave model in which one device (the master) processes data provided by other devices (the slaves) and serves as the communication hub of the group.

[0072]

[0085] Method 400 may begin at 404, where mobile device 102 and mobile device 402 may execute any suitable selection algorithm to determine which of the two devices is assigned as the "master" and which becomes the "slave". By way of illustration, mobile device 102 may be selected as the master.

[0073]

[0086] At 406, mobile device 102 may obtain vehicle data from vehicle 104 and obtain configuration data from mobile device 402 that identifies various sensors, processing devices, memory resources, etc. utilized by each device.

[0074]

[0087] At 408, the mobile device 102 may perform operations similar to those of method 200 to obtain a received registration certificate and / or a transmitted registration certificate from a certification authority (e.g., the certification authority 116 of FIG. 2, the RSU of network 108, a remote vehicle (e.g., RV110), etc.). In some embodiments, the mobile device 102 may transmit to the certification authority a superset of data including vehicle functions related to vehicle 104, configuration data related to mobile device 402, and its own configuration data that identifies various sensors, processing devices, memory resources, etc. utilized by mobile device 102.

[0075]

[0088] Assuming that a received registration certificate is received in response to the operations performed at 408, the mobile device 102 may begin, at 410, to receive data from network 108 (e.g., from RV110).

[0076]

[0089] At 412, the mobile device 102 may perform any suitable operations related to receiving and / or processing data messages. By way of example, the mobile device 102 may determine whether a data message is related to vehicle 104 by determining that one or more data elements of the data message match specific thresholds of vehicle attributes verified from registration data (e.g., registration data 114 of FIG. 1). As another example, if the message is considered related and the message includes data elements that provide additional vehicle functions to vehicle 104, the mobile device may store the additional vehicle functions in local memory along with the registration data 114, thereby expanding the data known about the attributes of vehicle 104. In some embodiments, the mobile device 102 may be configured to generate driver assistance information. By way of example, the mobile device 102 may generate any suitable alarms, alerts, and / or real-time traffic models as described below with respect to FIG. 6.

[0077]

[0090] At 414, the driver assistance information generated at 412 can be transmitted to vehicle 104 at 414 for display. In some embodiments, the driver assistance information may be graphically displayed on a display of vehicle 104 and / or the driver assistance information may be audibly displayed. According to some embodiments, the data message received at 410 may include a message type. Exemplary message types may include "vehicle-to-vehicle", "vehicle-from-proxy vehicle", "vehicle-from-human driver", "human driver-to-vehicle", "human driver-to-human driver", or "general broadcast". Any suitable data provided from the data message may be color-coded such that a driver or passenger viewing the information on the display of vehicle 104 can distinguish the data from each of the message types and / or may be visually distinguishable in some cases. By way of example, some data provided from a vehicle to a human driver may be displayed in blue text, while data provided by another human driver may be provided in red.

[0078]

[0091] Assuming that a transmission registration certificate is received in response to the operation of 408, the method may proceed to 416, where the mobile device 102 may transmit the transmission registration certificate to a registration authority (e.g., registration authority 118 of FIG. 1) to request one or more temporary transmission certificates. In some embodiments, at 410, the mobile device 102 may generate a public / private key pair and transmit the public key along with the transmission registration certificate.

[0079]

[0092] At 418, the mobile device 102 may obtain sensor data from vehicle 104 and / or mobile device 402. It should be understood that the data may be obtained from these devices simultaneously, at different times, according to a schedule, according to a period, or at any suitable time. In some embodiments, sensors of mobile device 402 and / or vehicle 104 may collect sensor data at any suitable time and communicate the data to mobile device 102 for transmission.

[0080]

[0093] At 420, mobile device 102 may be configured to format sensor data collected from vehicle 104 and / or mobile device 402 and / or sensor data collected by one or more of its own on-board sensors, and transmit one or more data messages via network 108. By way of example, mobile device 102 may transmit a BSM that may be received by RV110 (a participant in network 108). In some embodiments, the data messages transmitted at 420 may be broadcast or may be directed to specific recipients, as may be described in further detail with respect to FIG. 7.

[0081]

[0094] FIGS. 5A-5C illustrate a technique for assigning trust values to one or more entities in a V2X environment, according to one embodiment. A trust value may quantify the accuracy with which data provided by a device can be trusted. Any suitable numbering protocol may be utilized. The specific values used in the following examples are for illustration only and are not intended to limit the scope of the present disclosure. Legacy vehicles (LV), remote vehicles (RV), and proxy devices (PD) that operate as proxies for legacy vehicles are used in the following examples, but any suitable combination of V2X-enabled devices (PD, RV, RSU, etc.) may be utilized as well.

[0082]

[0095] Figure 5A shows several V2X-enabled devices that transmit data with corresponding trust values. As an example, RV504 and PD506 may acquire sensor data indicating the speed measurement of LV502 during their respective operations. For example, the sensor of RV504 may identify the speed of LV502 as 20 miles per hour (mph), while PD506 may acquire sensor data (from its own sensor or sensors of the vehicle and / or other mobile devices within the vehicle) that identifies the speed of LV502 as 22 mph. RV504 may transmit a trust value (e.g., 50) along with its measurement, indicating that the sensor from which the data was acquired is configured to be accurate within plus or minus 0.5 mph. Similarly, PD506 may transmit a measurement of 22 mph along with a trust value (e.g., 30) indicating that the sensor from which the data was acquired is configured to be accurate within 3 mph.

[0083]

[0096] In some embodiments, since the data of RV504 is likely to be more accurate than the sensor data acquired by PD506, PD506 may be configured to prioritize (e.g., utilize) the measurements provided by RV504, at least partially based on the trust values associated with and / or provided with those measurements.

[0084]

[0097] In some embodiments, since the measurements of PD506 are within the known error range of the sensor and PD506 has provided an indication of the measurement accuracy, the trust value associated with PD506 (at least for the speed measurement) may remain unchanged.

[0085]

[0098] Figure 5B shows an example where the confidence value can be corrected. Continuing with the example provided in Figure 5A. Instead, if the confidence value of PD506 indicates an accuracy of 1 mph, RV504 and / or PD506 may identify that the confidence value of PD506 does not indicate the actual accuracy of the measured value. In some embodiments, RV504 may send a data message to PD506 to correct the confidence value associated with its sensor, or PD506 may identify the discrepancy itself and accordingly adjust its confidence value (e.g., to 20) to indicate a new accuracy (e.g., within 2 mph accuracy). Moving forward, PD506 may use this confidence value when reporting the measured value from its sensor.

[0086]

[0099] Thus, in some embodiments, each part of the data may be provided with a confidence value indicating the accuracy of the sensor from which the data was obtained. In some embodiments, a V2X-enabled device may manage multiple confidence values corresponding to each sensor it accesses. In some embodiments, a V2X-enabled device may calculate an integrated confidence value (e.g., the average confidence value of all its sensors). In any scenario, the confidence value can be adjusted up or down over time as other data sources use it to identify the accuracy of the data provided by the V2X-enabled device. It should be understood that only a V2X-enabled device with a sensor having a high confidence value can adjust the confidence value of another device's sensor upward. This is because at least only a device with higher accuracy can confirm higher accuracy in other devices.

[0087]

[0100] Figure 5C shows another view of an ongoing example where a new RV arrives. RV508 may operate with a default confidence value associated with the sensor whose measured value is provided in some embodiments. In some embodiments, RV504, PD506, or any suitable V2X-enabled device may be configured to assign a confidence value to the measured value provided by RV508.

[0088]

[0101] As an example, PD506 can confirm that a speed measurement value of 21 mph falls within its own error range (e.g., 22 mph + or - 2 mph) based at least in part on the 22 mph measurement value it provided. Thus, PD506 can identify that the reliability value of RV508 is at least as accurate as itself, and send data to PD506 indicating that the measurement value provided by RV508 should be associated with a reliability value of at least 20. Similarly, RV504 can be configured to determine that the measurement value provided by RV508 is within 1 mph of the actual speed of LV502 (determined at least by RV504). RV504 can confirm that a speed measurement value of 21 mph provided by RV508 is within 1 mph of the speed of LV502 (determined at least by RV504) based at least in part on its own speed measurement value of 20 mph. Thus, RV504 can identify a reliability value of RV508 (e.g., 40) that is lower than its own reliability value (e.g., 50), indicating that it has a higher accuracy than the measurement value provided by PD506 but a lower accuracy for the measurement value provided by RV504. When each V2X-enabled device operates, the reliability value it maintains can vary over time. In some embodiments, when the reliability value of a particular sensor falls below a threshold, driver assistance information can be generated by that device to warn the user of the possibility of a hardware and / or software failure in that sensor.

[0089]

[0102] FIG. 6 is a diagram showing an exemplary technique for providing a real-time traffic model 600 according to at least one embodiment. The real-time traffic model 600 is intended to be an example of the driver assistance information 122 of FIG. 1. In some embodiments, the real-time traffic model 600 can be generated by a proxy device (e.g., the mobile device of FIG. 1) or any suitable V2X device capable of receiving data via the network 108 of FIG. 1 (e.g., a V2X network). The data elements of the real-time traffic model 600 can be derived and generated based at least in part on data elements received via any suitable combination of V2X messages received from any suitable number of sources. In some embodiments, the real-time traffic model 600 can include a map 601 representing an area (e.g., a threshold distance from the device that generated the model) and the number of vehicles (e.g., vehicles 602-632) within that area. Vehicles 634 and 636 are shown in FIG. 6 to indicate that two additional vehicles are physically present within the area, but these vehicles are not shown within the real-time traffic model 600 for reasons that will be further explained below.

[0090]

[0103] As shown in FIG. 6, the real-time traffic model 600 shows the "own vehicle" (e.g., own vehicle 602), which is the vehicle in which the real-time traffic model 600 is generated and displayed. The real-time traffic model 600 may be generated by a component of the own vehicle (e.g., the processor 1110 of FIG. 1), or at least some aspects of the real-time traffic model 600 may be generated by a proxy device related to the own vehicle (e.g., by the processor 1310 of FIG. 13). In some embodiments, the own vehicle 602 may be shown in a color and / or style different from other graphical elements representing other vehicles so that the color and / or style visually distinguishes the own vehicle 602 from other vehicles in the real-time traffic model 600. In some embodiments, the own vehicle 602 (or its proxy device that may generate the real-time traffic model 600) may be configured to access sensors that may collect data indicating the presence and various attributes of the vehicle. 608-618 are shown in FIG. 6.

[0091]

[0104] In some embodiments, vehicle 604 is a smart vehicle (e.g., a V2X-capable vehicle), and vehicle 606 is a legacy vehicle having a proxy device for transmission. The proxy devices of vehicle 604 and vehicle 606 can be configured to access respective sensors that can collect data indicating the presence and various attributes of other vehicles in the area. For example, vehicle 604 can obtain sensor data indicating the presence and various attributes of vehicles 608, 610, and 620 - 626. Similarly, the proxy device of vehicle 606 can obtain sensor data indicating the presence and various attributes of vehicles 614, 616, and 628 - 632. Vehicles 634 and 636 may not be displayed in the real-time traffic model 600 because there is no transmitting vehicle (or proxy device for transmission) collecting the sensor data of these vehicles. Each of vehicles 634 and 636 is blocked by other vehicles so that it is not detected by the host vehicle 602 or by either of the smart vehicles 604 or 606. When vehicle 626 is configured with suitable sensors (e.g., proximity sensors, cameras, LIDAR, SONAR, RADAR, etc.), it can potentially obtain sensor data regarding vehicles 634 and 636. Accordingly, the real-time traffic model generated in vehicle 626 can display vehicles 634 and 636 based on data collected from its own sensors. However, since vehicle 626 is a legacy vehicle that includes only a proxy device receiving from the V2X network, none of the other vehicles 602, 603, or 606 can display the presence and / or data related to vehicles 634 and 636 on their respective real-time traffic models.

[0092]

[0105] Each of vehicles 602, 604, and 606 can be a V2X-enabled device (e.g., a vehicle including a V2X-enabled vehicle or a proxy device) configured to transmit its respective vehicle attributes and / or vehicle attributes of other vehicles sensed by its respective device. Vehicles 608 - 624 and 628 - 636 are intended to represent legacy vehicles (e.g., vehicles that are not V2X-enabled). In some embodiments, if vehicle 626 includes a proxy device that transmits data indicating that it is listening on the network, the real-time traffic model (including real-time traffic model 600) generated by vehicles 602 - 606 may display some prominent feature indicating that vehicle 626 includes a receiving proxy device. Otherwise, vehicle 626 may be displayed in the same manner as each of the other legacy vehicles (e.g., vehicles 608 - 624).

[0093]

[0106] Each of the graphical elements of real-time traffic model 600 representing vehicles 602 - 632 can correspond to a stored object maintained by the host vehicle (or a proxy device operating as a proxy in place of host vehicle 602). In some embodiments, this object can store the correlation of data from multiple data sources. By way of example, the object corresponding to vehicle 608 can include data provided by vehicles 602 and 604. The object for vehicle 610 can store data provided by vehicles 602 and 604. The object can store any suitable vehicle attributes such as color, make, model, an image of the vehicle, license plate number, speed, acceleration, heading direction, identifying features (e.g., a broken left tail light, a dent in the right rear fender, a broken front windshield, etc.), vehicle status (e.g., on fire, smoking, traveling well below the current speed limit, right blinker on, left blinker on, etc.), passenger metadata, and the like. Similarly, vehicles 614 and 616 can correspond to respective objects that hold data provided by vehicles 602 and 606.

[0094]

[0107] Data corresponding to vehicles 608, 610, 614, and 616 (collectively referred to as anchor vehicles) can be used as reference points. As an example, since host vehicle 602 has sensor data regarding each vehicle, graphical elements regarding vehicles 608 - 618 can be displayed, while vehicles 620 - 632 can be stored as objects and graphically displayed by receiving data indicating the position and / or attributes of each vehicle relative to the anchor vehicles from either vehicle 604 or vehicle 606. Thus, host vehicle 602 does not itself collect sensor data regarding vehicles 620 - 632, yet still recognizes the presence of the vehicles and, in some cases, various attributes of each vehicle based on receiving such data from other V2X transmitting vehicles within the nearby area. Accordingly, real-time traffic model 600 can include graphical elements representing vehicles 608 - 632 even if those vehicles are not transmitting (or are not transmitting at all) V2X messages regarding themselves.

[0095]

[0108] Each type of vehicle (e.g., host vehicle, smart, legacy with transmitting PD, legacy with receiving PD, legacy (PD unknown), etc.) can be visually distinguishable, at least in part, based on any suitable attributes (e.g., color, shape, text, etc.). It should be understood that the description of the real-time traffic model is intended to be illustrative and non-limiting.

[0096]

[0109] In some embodiments, each of vehicles 602 - 606 may be configured to collectively determine their own and the unique identifiers of vehicles 608 - 632 using any suitable protocol. In some embodiments, vehicles 602 - 606 may utilize an attribute (e.g., license plate number) if the unique vehicle attribute is known from various sensor data (or in their own case, vehicle functions) to identify the vehicle. Otherwise, vehicles 602 - 606 may generate a unique identifier for each vehicle. In some embodiments, vehicles 602 - 606 may then direct V2X messages to any suitable vehicle among vehicles 602 - 632. For example, vehicle 602 may transmit a data message (e.g., a human - to - human message type) containing information indicating a warning from the driver of vehicle 602 to the driver / passenger of vehicle 604 that vehicle 618 is rapidly approaching from behind and to the left of vehicle 608 and appears to be driving aggressively. This may be useful for the operation of vehicle 604 as the driver and / or passenger of vehicle 604 may not yet be aware of vehicle 618. In some embodiments, it may not be necessary to determine a unique identifier; rather, the V2X data message may include the attributes of the vehicle to which the message pertains and / or is directed. Thus, in some embodiments, instead of using a specific identifier determined by a set of V2X devices (e.g., V2X1234), vehicle attributes (e.g., white, sedan, 4 - door sedan) may be used to identify the intended recipient of the message.

[0097]

[0110] Means for providing a real - time traffic model may include one or more software components and / or hardware components of a proxy device, such as bus 1305, processor 1310, memory 1360, wireless transceiver 1330, proxy processing module 1365, and output device 1315, as shown in FIG. 13, which is described in more detail below.

[0098]

[0111] In some embodiments, the means for providing a real-time traffic model may include one or more software components and / or hardware components of a V2X-enabled vehicle (e.g., vehicle 1100 of FIG. 1), such as bus 1101, processor 1110, memory 1160, wireless transceiver 1130, vehicle processing module 1165, and input / output device 1168, as shown in FIG. 11, which will be described in more detail below.

[0099]

[0112] FIG. 7 is a diagram showing an exemplary technique for utilizing messages directed in a V2X environment 700 (e.g., an example of environment 100 of FIG. 1) according to at least one embodiment. Vehicles A - D, vehicle N, and vehicle M can be V2X-enabled devices (e.g., vehicles having V2X-enabled vehicles and / or V2X-enabled proxy devices). Vehicle A may already be in motion and may have recognized various vehicle attributes associated with any suitable combination of vehicles A - G. These attributes may have been transmitted by any suitable combination of vehicles B - D, similar to those described in FIG. 6. Thereafter, vehicle A may stop at intersection 702 in accordance with the red signal and traffic regulations. Vehicles N and M may also stop at intersection 702.

[0100]

[0113] At a subsequent point in time, any suitable combination of vehicles A, N, and / or M may collect sensor data indicating that vehicle J is traveling through a red light, presenting a potential for a collision. In some embodiments, any suitable combination of vehicles A, N, and / or M may broadcast a V2X message indicating an action of vehicle J to warn other vehicles of a potential hazard. In some embodiments, vehicle A may be configured to determine that vehicles B and C are stopped behind vehicle A (from sensor data of vehicle A itself, as well as sensor data provided by vehicles B and / or C). In some embodiments, vehicle A may use any suitable combination of unique V2X identifiers pre-assigned to the vehicle, as described in FIG. 6, and / or any suitable attributes previously received with respect to vehicles D, E, F, and G, to direct a data message, particularly to vehicles D, E, F, and G. In some embodiments, if vehicle A is aware of the approximate positions of vehicles D - G, vehicle A may be configured to transmit a message directed only to vehicles D and E, as vehicle A may be able to decelerate vehicles D and E so that vehicles D and E similarly decelerate vehicles F and G.

[0101]

[0114] FIG. 8 is a flowchart showing a method 800 for transmitting data by a mobile device (e.g., mobile device 102 of FIGS. 1-4) instead of a vehicle (e.g., vehicle 104 of FIGS. 1-4). In some embodiments, the mobile device may comprise a memory (e.g., a non-transitory computer-readable medium) storing executable instructions for transmitting data instead of a vehicle, and one or more processors communicatively coupled to the memory, the one or more processors being configured to execute method 800 based on executing the instructions stored in the memory. The means for executing method 800 may include software components and / or hardware components of proxy device 1300, such as bus 1305, processor 1310, memory 1360, wireless transceiver 1330, proxy processing module 1365, and output device 1315, as shown in FIG. 13 described in more detail below.

[0102]

[0115] Method 800 may begin at 810 where a vehicle function related to the vehicle is obtained. In some embodiments, the vehicle function represents one or more sensors of the vehicle.

[0103]

[0116] At 820, the mobile device may determine a mobile device function representing one or more sensors of the mobile device, processing resources, or both.

[0104]

[0117] At 830, the mobile device may obtain one or more transmission authentication information from an authentication authority (e.g., certification authority 116 and / or registration authority 118 of FIGS. 1-4) (e.g., for vehicle-to-vehicle / road-to-vehicle transmission within the V2X network) based at least in part on the vehicle function and the mobile device function.

[0105]

[0118] At 840, in response to obtaining one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, the mobile device may transmit one or more data messages on behalf of the vehicle using the one or more transmission authentication information via one or more transceivers (e.g., the wireless transceiver 1330 of FIG. 13).

[0106]

[0119] FIGS. 9-13 are diagrams of systems, structural devices, vehicle components, and other devices, components, and systems that may be used to implement the techniques provided herein for detecting the degree of motion sickness that a person may experience while traveling in an autonomously driven vehicle.

[0107]

[0120] FIG. 9 is a diagram of a system 900 in a V2X - capable device (e.g., a vehicle, a proxy device, an RSU, a server, etc.) that can communicate via various networks according to one embodiment. In one embodiment, vehicle A980, for example, in one embodiment, performs negotiations for relative positioning between vehicles, lane changes, or passing through intersections, and exchanges V2X data elements such as global navigation satellite system (GNSS) measurements, vehicle status, vehicle position and vehicle capabilities, measurement data, and / or calculated status, vehicle functions, passenger metadata, and exchanges other V2X vehicle status steps that may not be covered in the V2X functional data elements. Vehicle A980 may communicate with vehicle B990, which may be V2X - or optionally communication - transceiver - capable, using a V2X or other wireless communication transceiver via link 923. In one embodiment, vehicle A980 may communicate with vehicle B990 through a network, for example, via wireless signal 922 with base station 920 and / or via wireless signal 932 with access point 930, or via one or more communication - capable RSUs 925, any of which may relay communication, information, and / or convert protocols for use by other vehicles such as vehicle B990, particularly in embodiments where vehicle B990 cannot directly communicate with vehicle A980 using a common protocol. In one embodiment, an RSU may comprise various types of roadside beacons, traffic monitors and / or vehicle monitors, traffic control devices, and location beacons.

[0108]

[0121] In some embodiments, vehicle A980 may lack V2X communication components (or such communication components may be malfunctioning and / or disabled) such that it cannot transmit and / or receive V2X data elements with other entities of system 900 (e.g., vehicle B990, RSU925, servers 940, 945, 950, 955, 960, 965, 968, etc.). A vehicle that cannot participate in V2X communication is referred to herein as a “legacy vehicle”. Thus, in some embodiments, vehicle A980 is a legacy vehicle. In some embodiments, mobile device 902 (an example of proxy device 1300 in FIG. 13) may be configured to function as a proxy on behalf of vehicle A980. Mobile device 902 may be configured to transmit and / or receive V2X messages with any suitable combination of entities of system 900 (e.g., vehicle B990, RSU925, servers 940, 945, 950, 955, 960, 965, 968, etc.). Mobile device 902 may be configured to transmit and / or receive wireless messages with vehicle A980 (or any suitable component of vehicle A980) using protocols of various wide area networks (WANs), wireless local area networks (WLANs), and / or personal area networks (PANs) in order to communicate via a wireless communication network. In one embodiment, mobile device 902 may comprise various combinations of WAN, WLAN, and / or PAN transceivers. In one embodiment, these transceivers may include Bluetooth transceivers, ZigBee® transceivers, and / or other PAN transceivers.The local transceiver, WAN wireless transceiver, and / or mobile wireless transceiver may comprise a WAN transceiver, access point (AP), femtocell, home base station, small cell base station, home node B (HNB), home eNode B (HeNB) or next-generation node B (gNodeB), and may provide access to a wireless local area network (WLAN, e.g., IEEE 802.11 network), wireless personal area network (PAN, e.g., Bluetooth network) or cellular network (e.g., LTE network or other wireless wide area network such as those described in the next paragraph). These are merely examples of networks that may communicate with mobile device 902 via a wireless link, and it should be understood that the claimed subject matter is not limited in this regard.

[0109]

[0122] In some embodiments, mobile device 902 may communicate with vehicle A980 via a PAN such as a Bluetooth network. In some embodiments, mobile device 902 may communicate with vehicle A980 via link 936, or through a network, e.g., via wireless signal 937 with base station 920 and / or via wireless signal 934 with access point 930, or via one or more communication-enabled RSUs 925, any of which may relay communication, information, and / or convert protocols for use by other vehicles such as vehicle B990, particularly in embodiments where vehicle B990 cannot directly communicate with vehicle A980 using a common protocol.

[0110]

[0123] Mobile device 902 may be configured to receive any suitable vehicle data from any suitable combination of components of vehicle A980 (e.g., vehicle sensor 1145, vehicle motion sensor 1140, camera 1135, RADAR 1153, LIDAR 1150, power / drive system and related systems 1175, input / output device 1168, and / or system 1155) via one or more communication networks. In some embodiments, mobile device 902 may be configured to receive vehicle functions and / or passenger metadata from vehicle A980 or from one or more interfaces of mobile device 902 in any suitable combination, based on one or more images captured by mobile device 902. Mobile device 902 may be configured with one or more sensors and may exchange locally acquired sensor data with the vehicle. In some embodiments, mobile device 902 may be configured to interface (send and / or receive data) with input / output device 1168 of FIG. 11. For example, mobile device 902 may present data via input / output device 1168 and / or mobile device 902 may receive data (e.g., user input) collected and provided by input / output device 1168 of vehicle A980.

[0111]

[0124] It should be understood that any suitable sensor of sensors / components 1135, 1140, 1145, 1150, 1153 may be attached aftermarket. Thus, any of sensors / components 1135, 1140, 1145, 1150, 1153 may be an example of a third-party sensor (e.g., of third-party sensors 105 of FIG. 1).

[0112]

[0125] The mobile device 902 may be configured to generate driver assistance information (e.g., the driver assistance information 122 of FIG. 1) based at least in part on the received V2X message data. As an example, when executed, the mobile device 902 may be configured with code (e.g., the proxy processing module 1365 of FIG. 13) that generates visual data and / or audible data (e.g., driver assistance information) indicative of at least a portion of the data received via one or more V2X messages. As a simplified example, the mobile device 902 may receive a V2X message indicating that a vehicle located in front of vehicle A980 has suddenly applied the brakes. The mobile device 902 may determine that the V2X message is relevant to vehicle A980 and generate visual data and / or audible data that may be displayed on the display and / or speaker of the mobile device 902 and / or on the display and / or speaker of vehicle A980 (e.g., via the input / output device 1168). The visual data and / or audible data may indicate that the brakes are being applied ahead and may warn the driver of a potential collision.

[0113]

[0126] Mobile device 902 may be configured to store vehicle functions and / or passenger metadata provided by a user or received as V2X message data. By way of example, mobile device 902 may be configured with code (e.g., proxy processing module 1365 of FIG. 13) to perform any suitable operations described herein with respect to managing, obtaining, storing, classifying, or in some cases interacting with vehicle functions and / or passenger metadata. In some embodiments, mobile device 902 may determine that a V2X message relates to vehicle A980 based at least in part on comparing vehicle functions and / or passenger metadata received from the V2X message with vehicle functions and / or passenger metadata stored in the mobile device. In some embodiments, proxy processing module 1365 may be configured with code to obtain passenger metadata from one or more nearby user devices (e.g., multiple mobile devices) when executed.

[0114]

[0127] Mobile device 902 may be configured to receive any suitable V2X data message from any suitable V2X-enabled device of system 900. In some embodiments, mobile device 902 may correlate the received data with any suitable data (e.g., vehicle functions, passenger metadata, sensor data, etc.) stored locally in mobile device 902 and may store data received from different sources corresponding to an entity in a single data container and / or related data containers.

[0115]

[0128] In some embodiments, the mobile device 902 may be configured to send any suitable data (e.g., vehicle functions, passenger metadata, sensor data, trust values, weather data, road conditions, object detection, etc.) via any suitable V2X data message. In some embodiments, these data messages may be broadcast, or the data messages may be directed (e.g., using a unique identifier and / or one or more attributes of the intended recipient). In some embodiments, the mobile device 902 may be configured to obtain any suitable registration certificate and / or temporary transmission certificate for itself and / or on behalf of any suitable number of devices (e.g., the third-party sensor 105 of FIG. 1) according to the methods 200 and 300 described above.

[0116]

[0129] In some embodiments, the mobile device 902 may operate in cooperation with one or more other mobile devices for data collection and / or transmission purposes. By way of example, the mobile device 902 may perform the functions described above with respect to any of the mobile devices of FIG. 4.

[0117]

[0130] Generally, any of the functions described in FIGS. 1-8 as being performed by a mobile device may be performed by the mobile device 902 (e.g., by executing the code of the proxy processing module 1365 of FIG. 13).

[0118]

[0131] In one embodiment, the mobile device 902 may communicate with a vehicle B990 using a V2X or other wireless communication transceiver via link 935 to perform, for example, relative positioning between vehicles, negotiation for lane changes or passing through intersections, and exchange V2X data elements such as global navigation satellite system (GNSS) measurements, vehicle status, vehicle position and vehicle capabilities, measurement data, vehicle functions, passenger metadata, and / or calculated situations, and to exchange other V2X vehicle situation steps that may not be covered by the V2X functional data elements. In one embodiment, the mobile device 902 may also communicate with the vehicle B990 through a network, for example, via a wireless signal 937 with a base station 920 and / or via a wireless signal 934 with an access point 930, or via one or more communication-enabled RSUs 925, any of which may relay communication, information, and / or convert protocols for use by other vehicles such as the vehicle B990, particularly in embodiments where the vehicle B990 cannot directly communicate with the vehicle A980 using a common protocol.

[0119]

[0132] In one embodiment, the RSU 925 may have a processor 925A configured to operate a wireless transceiver 925E to transmit and receive wireless messages, such as BSM or Cooperative Awareness Message (CAM) or other V2X messages, from the base station 920 and / or access point 930 to the vehicle A 980 and / or vehicle B 990 and / or mobile device 902, or vice versa. For example, the wireless transceiver 925E may use various protocols for V2X communication with vehicles, and / or various wide area network (WAN), wireless local area network (WLAN), and / or personal area network (PAN) protocols to transmit and / or receive wireless messages via a wireless communication network. In one embodiment, the RSU 925 may include one or more processors 925A communicatively coupled to the wireless transceiver 925E and a memory, and may include instructions and / or hardware for executing as a traffic control unit 925C, and / or for providing and / or processing environmental and roadside sensor information 925D, or for functioning as a position reference regarding the GNSS relative position between the RSU 925 and the vehicle. In one embodiment, the RSU 925 may include a network interface 925B (and / or wireless transceiver 925E) that may communicate with external servers such as a traffic optimization server 965, a vehicle information server 955, and / or an environmental data server 940 in one embodiment. In one embodiment, the wireless transceiver 925E may communicate via a wireless communication network by transmitting or receiving wireless signals from a wireless base transceiver subsystem (BTS), Node B or evolved Node B (eNodeB) or next generation Node B (gNodeB) via a wireless communication link. In one embodiment, the wireless transceiver 925E may comprise various combinations of WAN, WLAN, and / or PAN transceivers.In one embodiment, the local transceiver can also be a Bluetooth transceiver, a ZigBee transceiver, or other PAN transceiver. The local transceiver, WAN wireless transceiver, and / or mobile wireless transceiver may comprise a WAN transceiver, access point (AP), femtocell, home base station, small cell base station, home node B (HNB), home eNode B (HeNB) or next generation node B (gNodeB), and provide access to a wireless local area network (WLAN, e.g., IEEE 802.11 network), wireless personal area network (PAN, e.g., Bluetooth network) or cellular network (e.g., LTE network or other wireless wide area network such as those described in the next paragraph). These are merely examples of networks that can communicate with the RSU 925 via a wireless link, and it should be understood that the claimed subject matter is not limited in this regard.

[0120]

[0133] The RSU 925 can receive position, situation, GNSS and other sensor measurements, and functional information from vehicle A980 and / or vehicle B990 and / or mobile device 902, such as GNSS measurement values, sensor measurement values, speed, heading direction, position, stopping distance, priority status or emergency status, as well as other vehicle-related information such as vehicle functions and passenger metadata. In some embodiments, the mobile device 902 can obtain such data from vehicle A980. In one embodiment, environmental information such as road surface information / situation, weather situation, and camera information can be collected and shared with the vehicle via either point-to-point or broadcast messaging. The RSU 925 can utilize the information received from vehicle A980 and / or vehicle B990 and / or mobile device 902 via wireless transceiver 925E, environmental and roadside sensors 925D, and network information and control messages from, for example, traffic control and optimization server 965, to adjust and direct traffic flow and provide environmental messages, vehicle messages, safety messages, and notification messages to vehicle A980 and vehicle B990. In one embodiment, the RSU 925 can be configured to request and / or receive a received registration certificate, a transmission registration certificate, and / or one or more temporary transmission certificates, or any suitable combination of the above, from certificate and registration server 958. In some embodiments, the certificate and registration server 958 can perform any suitable functions described above with respect to the certificate authority 116 and / or registration authority 118 of FIGS. 1-4 and 8.

[0121]

[0134] In one embodiment, the processor 925A may be configured to operate a network interface 925B that may be connected to the network 970 via a backhaul and may be used to communicate and cooperate with various centralized servers such as a centralized traffic control and optimization server 965 that monitors and optimizes traffic flow within an area such as within a city or a city section or region. The network interface 925B may also be utilized for cloud sourcing of vehicle data, maintenance of the RSU 925, and / or cooperation with other RSU 925s, or remote access to the RSU 925 for other uses. The RSU 925 may have a processor 925A configured to operate a traffic control unit 925C, and the traffic control unit 925C may be configured to process data received from vehicles such as vehicle A 980 and vehicle B 990, such as position data, stopping distance data, road condition data, identification data, and other information related to the situation and position of nearby vehicles and the environment. The RSU 925 may have a processor 925A configured to obtain data from environmental and roadside sensors 925D, and these sensors may include temperature sensors, weather sensors, camera sensors, pressure sensors, road sensors (e.g., for vehicle detection), accident detection sensors, movement detection sensors, speed detection sensors, and other vehicle and environmental monitoring sensors.

[0122]

[0135] In one embodiment, vehicle A980 can also communicate with mobile device 902 using short - range communication networks and personal networks such as Bluetooth, Wi - Fi or Zigbee (registered trademark), or via V2X or other vehicle - related communication protocols, for example, to access a WAN and / or Wi - Fi (registered trademark) network in one embodiment, and / or to obtain sensor measurement values and / or position measurement values from mobile device 902. In one embodiment, vehicle A980 can communicate with mobile device 902 via a WAN base station 920, through a WAN network using WAN - related protocols, or directly peer - to - peer or using Wi - Fi via a Wi - Fi access point. Vehicle A980 and / or vehicle B990 can communicate using various communication protocols. In one embodiment, vehicle A980 and / or vehicle B990 can support wireless communication in various multiple modes, such as using V2X, Global System for Mobile Communications (GSM (registered trademark)), Wideband Code Division Multiple Access (WCDMA (registered trademark)), Code Division Multiple Access (CDMA), High - Rate Packet Data (HRPD), Wi - Fi, Bluetooth, WiMAX (registered trademark), LTE, 5G New Radio Access Technology (NR) communication protocols, etc.

[0123]

[0136] In one embodiment, vehicle A980 can communicate on a WAN network using a WAN protocol via a base station 920, or communicate with a wireless LAN access point 930 using a wireless LAN protocol such as Wi - Fi. The vehicle can also support wireless communication, for example, using WLAN, PAN (such as Bluetooth or ZigBee), Digital Subscriber Line (DSL), or packet cable.

[0124]

[0137] Vehicle A980 and / or vehicle B990 and / or mobile device 902 may include, in one embodiment, one or more GNSS receivers (e.g., GNSS receiver 1170 for vehicle A and / or B, GNSS receiver 1180 for mobile device 902) for receiving GNSS signals 912 from GNSS satellites 910 for positioning, time acquisition, and time integrity. Various GNSS systems may be supported, alone or in combination, using GNSS receivers xxx or other receivers to receive signals from various regional navigation systems such as Beidou, Galileo, GLONASS, and / or Global Positioning System (GPS), as well as quasi-zenith satellite system (QZSS) and NavIC or Indian Regional Navigation Satellite System (IRNSS). In one example, other wireless systems such as one or more RSUs 925, one or more wireless LAN access points 930, or one or more base stations 920, such as those that rely on beacons, may be utilized. Various GNSS signals 912 may be utilized with car sensors to determine position, velocity, proximity to other vehicles such as between vehicle A980 and vehicle B990.

[0125]

[0138] In one embodiment, vehicle A and / or vehicle B may access GNSS measurements and / or positions determined using GNSS, at least in part, provided by mobile device 902, which may also have GNSS, WAN, Wi-Fi, and other communication receivers and / or transceivers in one embodiment. In one embodiment, vehicle A980 and / or vehicle B990 may access GNSS measurements (such as pseudorange measurements, Doppler measurements, and satellite IDs) and / or positions determined using GNSS, at least in part, provided by mobile device 902 as a fallback in the event that GNSS receiver 770 fails or provides position accuracy below a threshold level.

[0126]

[0139] Vehicle A980 and / or vehicle B990 and / or mobile device 902 (as a proxy for vehicle A980) can access various servers on the network, such as vehicle information server 955, route server 945, location server 960, map server 950, environmental data server 940, and certificate and registration server 968. In some embodiments, vehicle A980 and / or vehicle B990 can be configured to request and / or receive from certificate and registration server 958 a received registration certificate, a transmitted registration certificate, and / or one or more temporary transmission certificates, or any suitable combination of the foregoing.

[0127]

[0140] Vehicle information server 955 can provide information describing various vehicles, such as antenna position, vehicle size, and vehicle functions, that can be used when making decisions regarding the operation of nearby vehicles, such as whether a vehicle can stop or accelerate in time, whether a vehicle is autonomously driven, whether it is capable of autonomous driving, whether it is communicable, etc. In one embodiment, vehicle information server 955 can also provide information regarding the size, shape, function, identification information, ownership, number of passengers, and / or determined location point (e.g., the position of a GNSS receiver, etc.) of the vehicle, as well as the position of the vehicle's boundary with respect to the determined location point.

[0128]

[0141] Route server 945 can receive current location and destination information and provide routing information, map data, alternative route data, and / or traffic data and road condition data for the vehicle.

[0129]

[0142] In one embodiment, the location server 960 provides a positioning function, transceiver almanacs including transmitter signal acquisition assistance (such as GNSS satellite orbit prediction information, time information, approximate location information, and / or approximate time information), and identification information and locations for Wi-Fi access points and base stations, and in some embodiments, additional route-related information such as speed limits, traffic, and road conditions / building conditions. The map server 950 can provide map data such as road locations, points of interest along the road, address locations along the road, road sizes, road speed limits, traffic conditions, and / or road conditions (wet, slippery, snow / frozen, etc.), road situations (open, under construction, accidents, etc.). The environmental data server 940 can provide, in one embodiment, weather and / or road-related information, traffic information, terrain information, and / or road quality and speed information, and / or other related environmental data.

[0130]

[0143] In one embodiment, vehicles 980 and 990 and mobile device 902 of FIG. 9 can communicate over network 970 via various network access points such as wireless LAN access point 930 or wireless WAN base station 920 on network 970. Any suitable combination of vehicles 980, 990, and mobile device 902 can also, in some embodiments, use various short-range communication mechanisms for direct communication between devices, between vehicles, from device to vehicle, and from vehicle to device, via Bluetooth, Zigbee, and 5G new radio standards, etc., without going through network 870.

[0131]

[0144] FIG. 10 shows a functional block diagram of a vehicle 1000 according to one embodiment. Vehicle 1000 corresponds to vehicle 104 and / or RV110 of FIG. 1 as described in the above embodiments. Further, hardware components and / or software components for executing the blocks shown in FIG. 10 are shown in FIG. 11 and will be described in more detail below.

[0132]

[0145] As shown in FIG. 10, vehicle 1000 can receive vehicle information and environmental information from vehicle external sensor 1002, vehicle internal sensor 1004, vehicle function 1006, external wireless information 1008 such as the position of the RV and GNSS measurement information (from the environment, other vehicles, RSU, system server), and / or vehicle movement situation 1010 (describing the current and / or future movement situation). The messages received by vehicle 104 and / or RV 110 of FIG. 1 described in the above embodiments can carry data provided, for example, in blocks 1008 and / or 1010. The received vehicle information, sensor information, and environmental information, in one embodiment, are connected and configured to provide external object perception and classification, prediction and planning, and execution of maneuvers, and to determine and update V2X or other wireless data element values including GNSS data element values, and to transmit messaging including the determined data elements via one or more wireless transceivers 1130, and can be processed in one or more processors 1110, DSP 1120, and memory 1160 (further described in FIG. 1). Messaging and data elements can be transmitted and received via various means, protocols, and standards such as SAE or European Telecommunications Standards Institute (ETSI) CV2X messages and data elements, or other wireless protocols and wireless V2X protocols supported by wireless transceiver 1130. In some embodiments, vehicle 1100 can be a legacy vehicle that lacks the ability to exchange messages and / or data elements via CV2X messages and / or via a wireless V2X protocol. Thus, in some embodiments, vehicle 1100 may receive V2X data elements from CV2X messages received by mobile device 902 of FIG. 9 (e.g., an example of proxy device 1300 described below with respect to FIG. 13).In an embodiment where the mobile device 902 functions as a proxy for the vehicle 1000, any suitable data received by the vehicle 1000 can be received from the mobile device 902, additionally and / or alternatively, (after the mobile device 902 receives data from data sources such as the servers 940, 945, 950, 955, 960, 965, and / or 968, the RSU 925, the vehicle B 990 in FIG. 9).

[0133]

[0146] The inter-vehicle relative positioning block 1028 can be used to determine the relative positions of vehicles within the area of interest. In one embodiment, GNSS data is exchanged with other vehicles (e.g., RVs) or other devices such as RSU to determine, and / or verify, and / or enhance the accuracy of the relative positions associated with other vehicles or devices. In one embodiment, determining the vehicles (or other devices) within the area of interest can utilize broadcast position information such as broadcast latitude and longitude received in messages (e.g., BSM) from other vehicles and other devices, and the position information of the vehicle 1000, to determine the approximate relative positions and / or approximate ranges between vehicles.

[0134]

[0147] In one embodiment, other vehicle-related input sources such as servers 955, 945, 960, 950, and 940 in FIG. 9 provide information such as vehicle information, routing, position assistance, map data, and environmental data, and are used together with vehicle-to-vehicle maneuver coordination 1024 to determine maneuver execution 1026. Other inputs, such as road position data, map data, driving state data, and other vehicle-related data inputs, can be input and / or complemented and / or used with them. In one embodiment, the map data may include the position of the roadside unit relative to the road position, where the vehicle can utilize the relative positioning with the RSU in combination with the map data to determine its position relative to the road surface, particularly in situations where other systems may fail, such as in poor visibility weather conditions (snow, rain, sandstorm, etc.). In one embodiment, the map data from map server 950 can be utilized together with relative and / or absolute data from adjacent vehicles and / or RSU 925 to determine the high-confidence absolute position and relative position with respect to the road / map for multiple vehicles. For example, if vehicle A980 in FIG. 9 has a higher accuracy / higher confidence position than other vehicles it is communicating with, such as vehicle B990 in FIG. 9, vehicle A980 can use the high-precision relative position transmitted to vehicle B990 and GNSS information about the high-precision position from vehicle A980 to determine the high-precision position of vehicle B990, even when the system of vehicle B990 may not be able to calculate a high-precision position in certain situations or environments. In this situation, the presence of vehicle A with a high-precision positioning system benefits all surrounding vehicles by sharing one or more high-precision positions along with the ongoing relative position information. Further, assuming the map data from map server 950 is accurate, the ability of vehicle A980 to propagate high-precision position data to surrounding vehicles such as vehicle B990 also enables the surrounding vehicles to accurately determine their relative positions with respect to the map data, even in a problematic signal / position environment in some cases.The vehicle information server 955 can provide vehicle information such as size, shape, and antenna position that can be utilized by, for example, vehicle A or other vehicles to determine not only the relative position between the GNSS receiver on vehicle A980 and, for example, vehicle B990, but also the distance between the closest points of vehicle A980 and vehicle B990. In one embodiment, traffic information from the traffic control and optimization server 965 can be utilized to determine overall route selection and rerouting, which (in one embodiment) is used together with the route server 945. In one embodiment, the environmental data server 940 can provide inputs regarding road conditions, black ice patches, snow, water on the road, and other environmental conditions that can also affect the decisions and decision criteria in the inter-vehicle maneuver coordination block 1024 and the maneuver execution block 1026. For example, in an icy or rainy condition, vehicle 1000 may execute and / or request an increase in the inter-vehicle distance from adjacent vehicles, or may select route options that avoid road hazard conditions such as black ice patches and standing water.

[0135]

[0148] Block 1028 may be implemented using various dedicated or generalized hardware and software, such as processor 1010 (an example of processor 1110 or DSP 1120 in FIG. 11) and memory 1160 (also shown in FIG. 11), or, in one embodiment, in dedicated hardware blocks such as a dedicated sensor processing core and / or a vehicle messaging core. According to some embodiments, the position of nearby vehicles can be determined through various means based on signal-based timing measurements such as round-trip time (RTT) and time of arrival (TOA), the signal strength of broadcast signals for vehicles, and the distance determined based on the broadcast latitude and longitude from neighboring vehicles and the current position of the vehicle. Additionally or alternatively, the position of nearby vehicles can be determined from sensor measurements such as 5G new radio (NR), ultra-wideband (UWB), light detection and ranging (LIDAR), radio detection and ranging (RADAR), SONAR, camera measurements, or any combination thereof. In one embodiment, some or all of blocks 1002, 1004, 1006, 1008 and / or 1010 may have dedicated processing cores, for example, to improve performance and reduce measurement latency. In one embodiment, some or all of blocks 1002, 1004, 1006, 1008 and / or 1010 may share processing with block 1028.

[0136]

[0149] In some embodiments, the vehicle external sensor 602 includes a camera, LIDAR, RADAR, proximity sensor, other sensors (e.g., devices for detecting weather, rain, snow, pressure changes, vertical direction, ground position, proximity detection, etc.), a GNSS receiver 770, and received data used with sensors such as map data, environmental data, position, route, etc., and / or other vehicle information that can be received from servers such as a map server 950, a route server 945, a vehicle information server 955, an environmental data server 940, a location server 960, etc., and / or from related devices such as a mobile device 902 that may be present in or near a vehicle such as vehicle A980. For example, in one embodiment, the mobile device 902 may provide an additional source of GNSS measurements, may provide an additional source of motion sensor measurements, or may serve as a communication portal to a WAN, Wi-Fi or other network and as a gateway to various information servers such as servers 940, 945, 950, 955, 960, 965, and / or 968.

[0137]

[0150] It should be understood that vehicle 1000 may include one or more cameras. In one embodiment, the camera may be forward-facing, side-facing, rear-facing, or have an adjustable perspective (such as a rotatable camera). As shown in FIG. 12, for example, there may be a plurality of cameras facing the same plane. For example, camera 1206 may be one of two forward-facing cameras, one focusing on lower objects and / or a lower perspective (such as an attached bumper) for parking, while the other focuses on a higher perspective for tracking traffic, other vehicles, pedestrians, and more distant objects. In one embodiment, it may be switched to various perspectives to optimize the tracking of other vehicles and external entities and objects, and / or to calibrate the sensor systems with each other, and / or various perspectives may be correlated with other inputs such as V2X inputs from other vehicles. LIDAR 1204 may be mounted on the roof and rotate, or may be focused on a specific perspective (forward-facing, rear-facing, side-facing, etc.). LIDAR 1204 may be solid-state or mechanical. The proximity sensor may be ultrasonic, RADAR-based, light-based (based on infrared ranging, etc.), and / or capacitive (surface contact-oriented or capacitive detection of a metallic object). Other sensors may include various sensing functions and technologies such as a barometric pressure sensor, weather, pressure change, vertical direction, a device for detecting ground position, proximity detector, moisture detector, rain and / or snow sensor, and / or light sensor, and / or may utilize other existing sensor systems. The GNSS receiver may be mounted on the roof, such as within a fin antenna assembly at the rear of the vehicle's roof, may be mounted on the hood or dashboard, or may in some cases be disposed outside or inside the vehicle.

[0138]

[0151] In one embodiment, the vehicle interior sensor 1004 includes wheel sensors 812 such as a tire pressure sensor, a brake pad sensor, a brake condition sensor, a speedometer, and other speed sensors, a heading direction sensor and / or an azimuth sensor such as a magnetometer and a geomagnetic compass, a distance sensor such as an odometer and a wheel tick sensor, an inertial sensor such as an accelerometer and a gyroscope, and an inertial positioning result using the above-described sensors, and sensors for yaw, pitch, and / or roll that can be individually determined or determined using other sensor systems such as an accelerometer, a gyroscope, and / or an inclination sensor.

[0139]

[0152] Both the vehicle interior sensor 1004 and the vehicle exterior sensor 1002 may have shared or dedicated processing functions. For example, a sensor system or subsystem may have one or more sensor processing cores that determine vehicle state values such as yaw, pitch, roll, heading direction, speed, acceleration ability, and / or distance, and / or stopping distance based on measurements and other inputs from accelerometers, gyroscopes, magnetometers, and / or other sensing systems. Different sensing systems may communicate with each other to determine measurements or may send values to block 1028 to determine the vehicle position. Vehicle state values derived from measurements from the internal and external sensors may be further combined with vehicle state values and / or measurements from other sensor systems using a general-purpose processor or an application processor. For example, block 1028 and / or 1024 may be implemented on a dedicated processor or a centralized processor to determine data element values for V2X messaging that may be transmitted using the wireless transceiver 1130 or via other communication transceivers. In one embodiment, the sensors may be separated into associated systems, such as LIDAR, RADAR, movement systems, wheel systems, etc., that are operated by dedicated core processing to obtain raw results for outputting vehicle state values from each core, and the vehicle state values may be combined and interpreted to derive combined vehicle state values that include functional data elements and situational data elements for use in controlling vehicle operation or, in some cases, affecting vehicle operation and / or as messaging steps shared with other vehicles and / or systems via V2X or other messaging functions. These messaging functions may be based on various wireless-related standards, optical-related standards, or other communication standards, such as those supported by the wireless transceiver 1130 and antenna 1132 in one embodiment.

[0140]

[0153] In one embodiment, the vehicle function 1006 may include performance estimated values regarding stopping, braking, accelerating, and turning radius, as well as autonomous and / or non-autonomous situations, and / or one or more functions. The function estimated values may be based on stored estimated values that may be loaded into the memory in one embodiment. These estimated values may be based on empirical performance numerical values for a particular vehicle or for an average across one or more vehicles, and / or one or more models for a given performance numerical value. When performance estimated values for multiple models are averaged or in some cases combined, they may be selected based on similar or common characteristics. For example, vehicles having similar or the same weight and the same or similar drive trains may share performance estimated values for drive performance-related estimated values such as braking / stopping distance, turning radius, and acceleration performance. Vehicle performance estimated values may also be obtained using the external V2X input 1008 via a wireless network, for example, from a vehicle data server on the network. This is particularly useful for obtaining information about vehicles that are not wireless-enabled and cannot directly provide vehicle information. In one embodiment, the vehicle function 1006 may also be affected by automotive component situations such as tire wear, tire brand function, brake pad wear, brake brand and function, and engine situation. In one embodiment, the vehicle function 1006 may also be affected by the overall vehicle situation such as speed, heading direction, etc., and external factors such as road surface, road condition (wet, dry, slippery / traction), weather (windy, raining, snowing, black ice burn, smooth road, etc.). Often, wear or other system degradation, and external factors such as weather, road surface, road condition, etc. may be utilized to reduce, verify, or improve the performance estimated values. In some embodiments, actual measured vehicle performance such as measuring the vehicle stopping distance and / or the acceleration time per distance may be measured and / or estimated based on the performance related to actual vehicle operation. In one embodiment, if the measurements are not consistent, the more recently measured performance may be weighted more heavily or may be prioritized over older measurements.Similarly, in one embodiment, measurements taken between similar states in the same type of weather or the same type of road surface, etc., as currently detected by the vehicle via, for example, the vehicle external sensor 1002 and / or the vehicle internal sensor 1004, may be weighted more heavily and / or given a higher priority when determining the function.

[0141]

[0154] V2X vehicle perception, prediction, and planning execution 1012 handles the reception and processing of information from blocks 1002, 1004, 1006, 1008, and 1010 via the external object perception and classification block 1014, and partially utilizes the sensor fusion and object classification block 1016 to correlate, validate, and / or combine the data from the input blocks 1002, 1004, 1006, 1008, and 1010. The external object perception and classification of block 1014 determines the existing objects, the type of the object (such as car, truck, bicycle, motorcycle, pedestrian, animal, etc.), and / or the object situation with respect to the vehicle, such as the movement situation, proximity, heading direction, and / or position with respect to the vehicle, size, threat level, and vulnerability priority (for example, pedestrians have a higher vulnerability priority than road debris). In one embodiment, block 1014 may utilize GNSS measurement messages from other vehicles to determine the relative position with respect to other vehicles. This output from block 1014 may be provided to the prediction and planning block 1018, which determines the detected objects and vehicles and their associated trajectories via block 1020, and determines vehicle maneuvers and route planning in block 1022, and its output is utilized in the vehicle maneuver execution of block 1026 directly or via the V2X vehicle-to-vehicle negotiation block 1024 that integrates and considers the maneuver plans, positions, and situations received from other vehicles. V2X vehicle-to-vehicle negotiation takes into account the situations of adjacent vehicles, vehicle priorities, vehicle functions (such as functions to stop, decelerate, or accelerate to avoid collisions), and in some embodiments, various conditions such as weather conditions (rain, fog, snow, wind), road conditions (dry, wet, frozen, slippery), etc., to enable negotiation and cooperation between adjacent vehicles or in some cases, affected vehicles.These include, for example, negotiation about the timing and order of passing through an intersection among vehicles approaching the intersection, negotiation about lane changes among adjacent vehicles, negotiation about parking spaces, and negotiation about access for turning or passing another vehicle on a single-lane road. Vehicle-to-vehicle negotiation may also include time-based and / or distance-based factors such as reservation time, destination distance, and estimated route time to reach the destination, and in some embodiments, type of reservation and importance of the reservation.

[0142]

[0155] FIG. 11 comprises a functional block diagram of a vehicle 1100 according to one embodiment. The vehicle 1100 may comprise, for example, an automobile, a bus, a truck, a motorcycle, and / or other motorized vehicles that can be at least partially autonomously driven. The vehicle 1100 may be an example of a legacy vehicle and / or a V2X-capable vehicle. As a legacy vehicle, the vehicle 1100 may lack the function of communicating via a V2X network and / or may lack a suitable combination of vehicle sensors 1145, vehicle motion sensors 1140, LIDAR 1150, RADAR 1153, GNSS receivers 1170, cameras 1135, or ADAS functions, which may be considered as the minimum requirements for participation in a V2X network.

[0143]

[0156] As shown in FIG. 11, vehicle 1100 may include various software and hardware components connected via bus 1101. For example, vehicle 1100 may include one or more processors 1110 and memory 1160. Memory 1160 may include executable instructions executable by processor 1110 to perform autonomous driving activities, including but not limited to external object detection and classification, prediction and planning, driving execution, receiving and / or transmitting V2X messages (in some cases including some combination of vehicle functions and / or passenger metadata). In some embodiments, memory 1160 may include vehicle processing module 1165. When executed by processor 1110, vehicle processing module 1165 may cause processor 1110 to generate and / or display any suitable driver assistance information (e.g., via input / output device 1168 or output device 1315 of FIG. 13) based at least in part on data elements received in one or more V2X data messages. When executed by processor 1110, vehicle processing module 1165 may include code that causes processor 1110 to perform any suitable operations for obtaining, requesting, storing, receiving, transmitting, comparing, or in some cases interacting with any suitable vehicle functions and / or passenger metadata. Vehicle processing module 1165 may provide any suitable graphical and / or audible interface through which any suitable combination of vehicle functions and / or passenger metadata may be obtained. Generally, any function described as being provided by a V2X-enabled vehicle may be performed by executing the code of vehicle processing module 1165.

[0144]

[0157] Vehicle 1100 may include one or more wireless transceivers, such as wireless transceiver 1130, for transmitting and receiving data via various means, protocols, and standards, such as SAE or European Telecommunications Standards Institute (ETSI) CV2X messages and data elements or other wireless and wireless protocols. In some embodiments, wireless transceiver 1130 is configured to transmit and receive data messages and elements via a short-range wireless communication protocol (e.g., Bluetooth, Bluetooth Low Energy®, etc.), and / or via a local and / or wide area network, and / or via a cellular network, and / or via any suitable wireless network. Of course, these are merely examples of networks that may be utilized by vehicle 1100 via a wireless link, and it should be understood that the claimed subject matter is not limited in this regard. In one embodiment, wireless transceiver 1130 may comprise various combinations of WAN, WLAN, and / or PAN transceivers. In one embodiment, wireless transceiver 1130 may also comprise a Bluetooth transceiver, a ZigBee transceiver, or other PAN transceiver.

[0145]

[0158] In some embodiments, vehicle 1100 may include a Global Navigation Satellite System (GNSS) receiver 1170. The GNSS receiver 1170 may be configured to receive and digitally process signals from navigation satellites (and / or other vehicles) to provide the position, velocity, and time of the receiver. The GNSS receiver 1170 may include hardware components and / or software components. In one embodiment, the GNSS signals from GNSS satellites received by the GNSS receiver 1170 are utilized by the vehicle 1100 for positioning and / or for the determination of GNSS signal parameters and demodulation data. In one embodiment, the signals received by the wireless transceiver 1130 are used alone or in combination with the GNSS signals received by the GNSS receiver 1170 for positioning.

[0146]

[0159] Examples of network technologies that may support the wireless transceiver 1130 are GSM, CDMA, WCDMA, LTE, 5G or New Radio Access Technology (NR), HRPD, and V2X vehicle-to-vehicle communication. As described, the V2X communication protocol may be defined in various standards such as SAE and ETS-ITS standards. GSM, WCDMA, and LTE are technologies defined by 3GPP. CDMA and HRPD are technologies defined by the Third Generation Partnership Project II (3GPP2). WCDMA is also part of the Universal Mobile Telecommunications System (UMTS) and may be supported by HNB.

[0147]

[0160] The wireless transceiver 1130 may communicate with a communication network via a WAN wireless base station that may include the deployment of equipment that provides subscriber access to a wireless telecommunications network (e.g., under a service contract). Here, the WAN wireless base station may perform the functions of a WAN or cell base station when serving subscriber devices within a cell determined at least in part based on the area in which the WAN wireless base station can provide access services. Examples of WAN base stations include GSM, WCDMA, LTE, CDMA, HRPD, Wi-Fi, Bluetooth, WiMAX, 5GNR base stations. In one embodiment, further, the wireless base station may include a WLAN and / or PAN transceiver.

[0148]

[0161] In one embodiment, vehicle 1100 may include one or more cameras 1135. In one embodiment, camera 1135 may comprise a camera sensor and a mounting assembly. Different mounting assemblies may be used for different cameras on vehicle 1100. For example, a forward-facing camera may be mounted within the front bumper, within the stem of the rearview mirror assembly, or in other forward-facing areas of vehicle 1100. A rear-facing camera may be mounted within the rear bumper / fender, on the rear glass, on the trunk, or in other rear-facing areas of the vehicle. Side mirrors may be mounted on the sides of the vehicle, such as being integrated into the mirror assembly or door assembly. The camera may provide object detection and distance estimation, particularly for objects of known size and / or shape (e.g., both stop signs and license plates have standardized sizes and shapes), and may also provide information regarding rotational movement with respect to the axis of the vehicle, such as while the vehicle is turning. When used in cooperation with other sensors, both cameras may be calibrated by the use of other systems, such as LIDAR, wheel tick / distance sensors, and / or GNSS, to verify the distance traveled and the angular direction. The camera may similarly be used to verify other systems and calibrate them so as to verify that the distance measurements are correct by calibrating against known distances between known objects (e.g., landmarks, roadside markers, road mile markers, etc.), and to verify that the object detection has been accurately performed so that the objects are appropriately mapped to the correct positions relative to the vehicle by LIDAR and other systems.Similarly, for example, when combined with an accelerometer, the collision time with a road hazard (e.g., the elapsed time before hitting a pothole) may be estimated, which may be verified against the actual collision time, and / or a stopping model (e.g., compared with an estimated stopping distance if attempting to stop before hitting an object) and / or a steering model (verifying whether the current estimated value of the turning radius at the current speed and / or the measured value of the steerability at the current speed is accurate and is appropriately corrected to update the parameters estimated based on the camera and other sensor measurements) may be verified.

[0149]

[0162] In some embodiments, at least some of the cameras 1135 may be inward-facing. The cameras 1135 may be utilized to capture one or more images from which vehicle data may be derived (e.g., an image of a speedometer from which speed may be derived, an image of a head direction indicator from which the head direction may be derived, etc.). In some embodiments, the cameras 1135 may be utilized to capture one or more images of at least a portion of one or more of the vehicle occupants.

[0150]

[0163] The vehicle motion sensor 1140 may include any suitable number of accelerometers, gyroscopes, and / or magnetometers. In some embodiments, the vehicle motion sensor 1140 may be part of an inertial measurement unit of the vehicle 1100. The vehicle motion sensor 1140 may be utilized to provide and / or verify motion and direction information, to monitor wheel and drive train performance, and / or to measure the amplitude and frequency of vibrations of the vehicle 1100 and / or components of the vehicle 1100. By way of example, an accelerometer (e.g., a three-axis accelerometer) can measure vibrations of the vehicle 1100 such as motion around the equilibrium position of components of the vehicle 1100 or mechanical vibrations. The accelerometer may also, in one embodiment, be utilized to verify the actual collision time with road hazards such as potholes for a predicted time based on existing stop and acceleration models as well as steering models. The gyroscope and magnetometer of the vehicle sensor 1145 may, in one embodiment, measure the rotational situation of the vehicle and the orientation relative to magnetic north, respectively, and in particular, when used in cooperation with measurements from other external and internal sensors such as other sensors like speed sensors, wheel tick sensors, and / or odometer measurements, may be utilized to measure and calibrate estimates and / or models for the turning radius at the current speed and / or measurements of maneuverability at the current speed. In some embodiments, the vehicle sensor 745 may be configured to measure vibrations and / or vibration frequencies corresponding to the motion executed by the vehicle 1100.

[0151]

[0164] The vehicle 1100 may include LIDAR 1150. The LIDAR 1150 may use pulsed laser light to measure the distance to an object. While the camera 1135 can provide object detection, the LIDAR 1150 may provide a means for more reliably detecting the distance (and orientation) of an object, particularly with respect to objects of unknown size and shape. The LIDAR 1150 measurements may also be used to estimate the travel speed, vector direction, relative position, and stopping distance by providing accurate distance measurements and delta distance measurements.

[0152]

[0165] In one embodiment, the power / drive system and associated systems 1175 (generator, battery, transmission, engine) and system 1155 (brake, actuator, throttle control device, steering, and electric) can be controlled by processor 1110 and / or by hardware or software, or by the vehicle operator, or by some combination thereof. System 1155 and the power / drive system and associated systems 1175 can be used with performance and operating parameters to enable the vehicle 1100 to be safely and accurately driven and operated, such as safely, effectively and efficiently merging into traffic, stopping, accelerating, and in some cases operating the vehicle 1100, autonomously (and manually for alerts and emergency override / brake / stop). In one embodiment, inputs from various sensor systems such as camera 1135, vehicle motion sensors 1140 (including accelerometers, gyros, manometers, etc.), LIDAR 1150, GNSS receiver 1170, RADAR 1153, inputs from wireless transceiver 1130, messages and / or measurements, or various combinations thereof can be utilized by processor 1110 and / or DSP 1120 or other processing systems to control the power / drive system and associated systems 1175 and system 1155.

[0153]

[0166] The GNSS receiver 1170 may be used to determine its position (absolute position) relative to the Earth and, when used with measurements from other objects and / or other information such as mapping data, may be used to determine its position relative to other objects such as other vehicles and / or the road surface. To determine its position, the GNSS receiver 1170 may receive RF signals from one or more GNSS satellites using one or more antennas 1172. The GNSS receiver 1170 may support one or more GNSS constellations as well as other satellite-based navigation systems. For example, in one embodiment, the GNSS receiver 1170 may support a global navigation satellite system such as GPS, GLONASS, Galileo, and / or BeiDou, or any combination thereof. In one embodiment, the GNSS receiver 1170 may support a regional navigation satellite system such as NavIC or QZSS or a combination thereof, as well as various augmentation systems such as Doppler Orbitography and Radio-positioning Integrated by Satellite (DORIS), Wide Area Augmentation System (WAAS), European Geostationary Navigation Overlay Service (EGNOS), Multi-functional Satellite Augmentation System (MSAS), or Local Area Augmentation System (LAAS) (e.g., satellite-based augmentation system (SBAS) or ground-based augmentation system (GBAS)). In one embodiment, the GNSS receiver 1170 and antenna 1172 may support multiple bands and sub-bands such as the GPS L1, L2, and L5 bands, the Galileo E1, E5, and E6 bands, the Compass (BeiDou) B1, B3, and B2 bands, the GLONASS G1, G2, and G3 bands, and the QZSS L1C, L2C, and L5-Q bands.

[0154]

[0167] The GNSS receiver 1170 can be used to determine the position, the position and relative position that can be utilized for navigation, and to determine the distance between two points in clear weather conditions, and can be used as appropriate to calibrate other sensors such as an odometer and / or LIDAR using the distance data. In one embodiment, for example, GNSS-based relative positions based on shared Doppler measurements and / or pseudo-range measurements between vehicles may be used to determine the high-precision distance between two vehicles, and when vehicle information such as shape and model information is combined with the GNSS antenna position, it can be used to calibrate, verify, and / or affect the reliability levels associated with information from LIDAR, cameras, RADAR, SONAR, and other distance estimation techniques. GNSS Doppler measurements may also be utilized to determine the linear and rotational motion of a vehicle, or of a vehicle relative to another vehicle, and GNSS Doppler measurements may be utilized with gyroscopes and / or magnetometers and other sensor systems to maintain the calibration of those systems based on the measured position data. Relative GNSS position data may also be combined with high-reliability absolute positions from roadside units (RSUs) to determine the high-reliability absolute position of a vehicle. Further, relative GNSS position data may be used during inclement weather to obscure LIDAR and / or camera-based data sources for avoiding other vehicles and staying within a lane or other assigned road area. For example, a roadside unit (RSU) equipped with a GNSS receiver and V2X functionality may be used to provide GNSS measurement data to a vehicle, and the GNSS measurement data can be used to navigate the vehicle relative to a map when the absolute position of the RSU is provided, and can keep the vehicle within a lane and / or on a road despite a lack of visibility.

[0155]

[0168] RADAR1153 uses the transmitted radio waves reflected from an object. The reflected radio waves are analyzed based on the time it takes for the reflected wave to arrive and other signal characteristics of the reflected wave to determine the position of nearby objects. RADAR1153 may be utilized to detect the positions of nearby vehicles, roadside objects (such as signs, other vehicles, pedestrians, etc.), and generally enables the detection of objects even in the presence of obscuring weather conditions such as snow, rail, or hail. Thus, RADAR1153 may be used to complement LIDAR1150 and camera 1135 when providing ranging information to other objects by providing ranging and distance measurement as well as information when vision-based systems typically fail. Additionally, RADAR1153 may be utilized to calibrate and / or sanity-check other systems such as LIDAR1150 and camera 1135. The ranging measurements from RADAR1153 can be used to determine / measure the stopping distance at the current speed, acceleration, maneuverability at the current speed, and / or the turning radius at the current speed and / or the maneuverability measurement at the current speed. In some systems, ground-penetrating RADAR may also be used to track the road surface, for example, via terrain features such as RADAR reflection markers or grooves on the road surface.

[0156]

[0169] The input / output device 1168 may include any suitable one or more audio devices (such as one or more speakers) and / or one or more displays (such as a dashboard display, a media display, a projection display, etc.). The input / output device 1168 may provide an interface through which a mobile device (such as the mobile device 902 in FIG. 9) can provide data for display in the vehicle 1100 (for example, in a scenario where the mobile device 902 functions as a proxy for the vehicle 1100).

[0157]

[0170] FIG. 12 is a perspective view of an exemplary vehicle 1200 (e.g., an example of the vehicle 1100 of FIG. 11, an example of the vehicle 104 of FIGS. 1-4) according to one embodiment. Here, some of the components described with respect to FIG. 12 and previous embodiments are shown. As illustrated and previously described, the vehicle 1200 can have one or more cameras (e.g., each an example of the camera 1135 of FIG. 11), such as a rearview mirror-mounted camera 1206, a passenger-facing camera (not shown), a front fender-mounted camera (not shown), a side mirror-mounted camera (not shown), and a rear camera (not shown, but typically on the trunk, hatch, or rear bumper). The vehicle 1200 may also have a LIDAR 1204 (an example of the LIDAR 1150 of FIG. 11) for detecting objects and measuring the distance to those objects, and the LIDAR 1104 is often mounted on the roof, but if there are multiple LIDAR units, they may be directed around the front, rear, and sides of the vehicle. The vehicle 1200 can have other various position-related systems such as a GNSS wireless receiver (typically located within a shark fin unit on the rear of the roof as shown) and / or receivers 1202 such as various wireless transceivers (WAN, WLAN, V2X, etc., typically but not necessarily located within the shark fin), a RADAR 1208 (typically located within the front bumper), and a SONAR 1210 (if present, typically located on both sides of the vehicle). A wheel sensor 1212 (an example of the vehicle motion sensor 1140 of FIG. 11) may be present and can include wheel sensors and / or drive train sensors such as tire pressure sensors, accelerometers, gyros, and wheel rotation detection and / or counters.

[0158]

[0171] In one embodiment, the distance measurements and relative positions determined via various sensors such as LIDAR, RADAR, cameras, GNSS, and SONAR may be combined with vehicle size and shape information and information regarding the positions of the sensors to determine the distances and relative positions between the surfaces of different vehicles such that the distances or vectors from the sensors to another vehicle or between two different sensors (such as two GNSS receivers) gradually increase to account for the positions of the sensors on each vehicle. Thus, the accurate GNSS distances and vectors between two GNSS receivers need to be corrected based on the relative positions of the various vehicle surfaces with respect to the GNSS receivers. For example, when determining the distance between the front bumper of a following vehicle and the rear bumper of a leading vehicle, this distance needs to be adjusted based on the distance between the GNSS receiver and the front bumper of the following vehicle and the distance between the GNSS receiver of the leading vehicle and the rear bumper of the leading vehicle. As an example, the distance between the rear bumper of the leading vehicle and the front bumper of the following vehicle is the relative distance between the two GNSS receivers minus the distance from the GNSS receiver to the front bumper of the following vehicle minus the distance from the GNSS receiver to the rear bumper of the leading vehicle. This list is not intended to be limiting, and it should be understood that FIG. 12 is intended to provide exemplary positions of various sensors in one embodiment of vehicle 1200.

[0159]

[0172] It should be understood that any suitable sensors and / or any suitable devices / components shown in FIG. 12 may be attached aftermarket. Thus, any of the sensors / devices / components shown in FIG. 12 may be an example of a third-party sensor (such as third-party sensor 105 of FIG. 1).

[0160]

[0173] FIG. 13 is a block diagram of one embodiment of a proxy device 1300 according to at least one embodiment. According to some embodiments, the proxy device 1300 may comprise a stand-alone device mobile device (e.g., smartphone, laptop, tablet PC, etc.) that may be communicatively coupled to other components / devices of a vehicle or RSU. It should also be noted that the proxy device 1300 may be utilized in a similar manner by V2X entities other than vehicles or RSUs. Additionally, embodiments may not necessarily be limited to V2X communication. Thus, alternative embodiments may have components similar to those shown in FIG. 13 and be capable of performing the functions of the vehicles and / or RSUs described in the foregoing embodiments, but may include devices similar to the proxy device 1300 that do not have V2X functionality.

[0161]

[0174] Note that FIG. 13 is only intended to provide a generalized illustration of various components, and any or all of those components may be utilized as appropriate. In some cases, the components shown by FIG. 13 may be localized to a single physical device and / or distributed among various networked devices that may be located at different physical locations, e.g., on a vehicle, RSU, or other V2X entity.

[0162]

[0175] The proxy device 1300 is shown as comprising hardware elements that may be electrically coupled (or in some cases, may communicate as appropriate) via a bus 1305. The hardware elements may include a processor 1310 that can include, but is not limited to, one or more general-purpose processors, one or more dedicated processors (such as a digital signal processing (DSP) chip (e.g., DSP 1320), a graphics acceleration processor, an application specific integrated circuit (ASIC), etc.), and / or other processing structures or means.

[0163]

[0176] The proxy device 1300 can also include one or more input devices 1370 that can include devices related to a user interface (e.g., touch screen, touch pad, microphone, button, dial, switch, etc.). Similarly, one or more output devices 1315 can be related to interacting with the user (e.g., via a display, light emitting diode (LED), speaker, etc.). For example, one or more output devices 1315 may be utilized by the proxy device 1300 to display the driver assistance information 122 of FIG. 1 (e.g., display, sound, etc.).

[0164]

[0177] The proxy device 1300 can also include a wireless transceiver 1330 that can be equipped with, but not limited to, a modem, network card, infrared communication device, wireless communication device, and / or chipset (such as Bluetooth device, IEEE802.11 device, IEEE802.15.4 device, Wi-Fi device, WiMAX device, WAN device and / or various cellular devices, etc.). The wireless transceiver 1330 can enable the proxy device 1300 to communicate with other V2X devices (e.g., vehicle B990, RSU925, servers 940, 945, 950, 955, 960, 965, and 968 of FIG. 9) and devices lacking V2X communication capabilities (e.g., vehicle A980). This can include various forms of communication of the foregoing embodiments. Thus, it can be possible to transmit direct communication, broadcast wireless signals, receive direct and / or broadcast wireless signals, etc. Thus, the wireless transceiver 1330 may be capable of transmitting and / or receiving RF signals from various RF channels / frequency bands. Communication using the wireless transceiver 1330 can be performed via one or more wireless communication antennas 1332 that transmit and / or receive wireless signals 1334.

[0165]

[0178] The proxy device 1300 may further include a sensor 1340. The sensor 1340 may include, without limitation, one or more inertial sensors and / or other sensors (e.g., accelerometers, gyroscopes, cameras, magnetometers, altimeters, microphones, proximity sensors, light sensors, barometers, etc.). The sensor 1340 may be used, for example, to determine some real-time characteristics of the vehicle such as position, speed, acceleration, etc. As shown previously, the sensor 1340 may be used to assist the vehicle in determining its position.

[0166]

[0179] Embodiments of the proxy device 1300 may also include a GNSS receiver 1380 that is capable of receiving a signal 1384 from one or more GNSS satellites using an antenna 1382 (which may be the same as the wireless communication antenna 1332 in some embodiments). Positioning based on GNSS signal measurements can be used to determine the current position of the proxy device 1300 and may further be used as a basis for determining the position of the detected object. The GNSS receiver 1380 can extract the position of the proxy device 1300 from GNSS satellites of a GNSS system such as the Global Positioning System (GPS) and / or similar satellite systems using conventional techniques.

[0167]

[0180] The proxy device 1300 may further comprise and / or communicate with a memory 1360. The memory 1360 may include, without limitation, solid-state storage devices such as local and / or network-accessible storage, disk drives, drive arrays, optical storage devices, random access memory (RAM) and / or read-only memory (ROM), which may be programmable, flash updatable, etc. Such storage devices may be configured to implement any suitable data store, including, without limitation, various file systems, database structures, etc.

[0168]

[0181] The memory 1360 of the proxy device 1300 may include software elements (some of which are not shown in FIG. 13), such as an operating system, device drivers, executable libraries, and / or other code, such as one or more application programs. This memory 1360 may comprise computer programs provided by various embodiments and / or may be designed to implement the methods described herein and / or configure the system. A software application (e.g., proxy processing module 1365) stored in the memory 1360 and executed by the processor 1310 may be used to implement the functions that provide the functionality of the proxy device described herein. Further, one or more procedures described with respect to the methods described herein may be implemented as part of the proxy processing module 1365 and may be stored in the memory 1360. The code / instructions of the proxy processing module 1365 are executable by the proxy device 1300 (and / or the processor 1310 or DSP 1320 within the proxy device 1300) and may include the functions described above with respect to the functionality of the proxy device of FIGS. 1-8. In one aspect, such code and / or instructions may then be used to configure and / or adapt a general-purpose computer (or other device) to perform one or more operations in accordance with the described methods.

[0169]

[0182] When executed by the processor 1310, the proxy processing module 1365 may include code to cause the processor 1310 to obtain, request, store, receive, transmit, compare, or otherwise perform any suitable operations for interacting with any suitable vehicle functions and / or passenger metadata. The proxy processing module 1365 may provide any suitable graphical and / or audible interface through which any suitable combination of vehicle functions and / or passenger metadata may be obtained (e.g., from a user of the proxy device 1300). The proxy processing module 1365 may include one or more application programming interfaces through which passenger metadata may be obtained and / or provided by one or more user devices associated with one or more passengers of the vehicle.

[0170]

[0183] The processor 1310 may receive and / or transmit vehicle A980's position, vehicle functions and / or passenger metadata, situation, GNSS and other sensor measurements, one or more confidence values corresponding to the sensor measurements, GNSS measurements, sensor measurements, speed, heading direction, position, stopping distance, priority or emergency situation, etc., functional information from vehicle A980 and / or vehicle B990, as well as other vehicle-related information. In one embodiment, environmental information such as road surface information / situation, weather situation, and camera information may be collected (e.g., from any suitable combination of RSU 925, vehicle A980, vehicle B990, or the server of FIG. 9) via either point-to-point or broadcast messaging and shared with the vehicle. The processor 1310 may utilize the received information to adjust and direct traffic flow and provide environmental messages, vehicle messages, safety messages, and notification messages to vehicle A980; otherwise, vehicle A980 may not be able to view such information. By utilizing the proxy device 1300, legacy vehicles can participate in the V2X environment so that information provided by other V2X entities can be displayed to the driver of the legacy vehicle.

[0171]

[0184] In one embodiment, the processor 925A may be connected to the network 970 via a backhaul and may be configured to operate a network interface 925B for communicating and coordinating with various centralized servers such as a centralized traffic control and optimization server 965 that monitors and optimizes traffic flow within an area such as a city or within a city block or region. The network interface 925B may also be utilized for cloud sourcing of vehicle data, maintenance of the RSU 925, and / or coordination with other RSU 925s, or remote access to the RSU 925 for other uses. The RSU 925 may have a processor 925A configured to operate a traffic control unit 925C, and the traffic control unit 925C may be configured to process data received from vehicles such as vehicle A 980 and vehicle B 990, such as position data, stopping distance data, road condition data, identification data, and other information related to the status and position of nearby vehicles and the environment. The RSU 925 may have a processor 925A configured to obtain data from environmental and roadside sensors 925D, and these sensors may include temperature sensors, weather sensors, camera sensors, pressure sensors, road sensors (e.g., for vehicle detection), accident detection sensors, movement detection sensors, speed detection sensors, and other vehicle and environmental monitoring sensors.

[0172]

[0185] It will be apparent to those skilled in the art that substantial modifications may be made in accordance with specific requirements. For example, customized hardware may be used and / or certain elements may be implemented in hardware, software (including portable software such as applets), or both. Additionally, connections to other computing devices such as network input / output devices may be used.

[0173]

[0186] Referring to the accompanying drawings, a component that can include a memory (e.g., memory 1360 in FIG. 13) can include a non-transitory machine-readable medium. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any storage medium involved in providing data that causes a machine to operate in a particular manner. In the embodiments provided above, various machine-readable media can be involved in providing instructions / code to a processor and / or other devices for execution. Additionally or alternatively, a machine-readable medium may be used to store and / or carry such instructions / code. In many implementations, a computer-readable medium is a physical and / or tangible storage medium. Such a medium can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Common forms of computer-readable media include, for example, magnetic and / or optical media, any other physical media having a pattern of holes, RAM, PROM, EPROM, FLASH®-EPROM, any other memory chip or cartridge, the carrier wave described below, or any other medium that a computer can read instructions and / or code from.

[0174]

[0187] The methods, systems, and devices described herein are examples. Various embodiments can omit, substitute, or add various procedures or components as appropriate. For example, features described with respect to some embodiments can be combined in various other embodiments. Different aspects and elements of embodiments can be combined in a similar manner. The various components in the figures provided herein can be implemented in hardware and / or software. Also, technology evolves, and thus many of the elements are examples and their examples do not limit the scope of the disclosure to those specific examples.

[0175]

[0188] For reasons mainly related to general usage, it has been found useful at times to refer to such signals as bits, information, values, elements, symbols, characters, variables, terms, numbers, digits, etc. However, it should be understood that all of these or similar terms should be associated with appropriate physical quantities and are merely convenient labels. Unless otherwise specified, as is apparent from the above description, throughout this specification, descriptions using terms such as "processing", "calculating", "computing", "determining", "confirming", "identifying", "associating", "measuring", "performing", etc. are to be understood as referring to actions or processes of a particular apparatus, such as a dedicated computer or a similar dedicated electronic computing device. Thus, in the context of this specification, a dedicated computer or a similar dedicated electronic computing device is capable of operating on or transforming signals that are generally represented as electronic, electrical, or magnetic physical quantities within the memory, registers, or other information storage devices, transmission devices, or display devices of the dedicated computer or similar dedicated electronic computing device.

[0176]

[0189] The terms "and" and "or" as used herein can include a variety of meanings that are also expected to depend at least in part on the context in which such terms are used. Generally, when "or" is used to associate a list such as A, B, or C, it is meant to mean A, B, and C as used herein in an inclusive sense, as well as A, B, or C as used herein in an exclusive sense. Further, the term "one or more" as used herein can be used to describe any singular feature, structure, or property, or can be used to describe some combination of features, structures, or properties. However, it should be noted that this is merely an exemplary example and the claimed subject matter is not limited to this example. Further, the term "at least one of" when used to associate a list such as A, B, or C can be interpreted to mean any combination of A, B, and / or C, such as A, AB, AA, AAB, AABBCCC, etc.

[0177]

[0190] Although some embodiments have been described, various modifications, alternative configurations, and equivalents can be used without departing from the spirit of the disclosure. For example, the above elements may merely be components of a larger system, and other rules may take precedence over or otherwise modify the application examples of the various embodiments. Also, several steps may be taken before, during, or after the above elements are considered. Accordingly, the above description does not limit the scope of the disclosure.

[0178]

[0191] In view of this description, embodiments can include different combinations of features. Implementation examples are described in the following numbered clauses.

[0179] Clause 1: A method for transmitting data by a mobile device instead of a vehicle, the method comprising: obtaining, by the mobile device, vehicle functions related to the vehicle, the vehicle functions indicating one or more sensors of the vehicle; determining, by the mobile device, mobile device functions indicating one or more sensors of the mobile device, processing resources, or both; obtaining, by the mobile device, from a certification authority, one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission based at least in part on the vehicle functions and the mobile device functions; and in response to obtaining the one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, transmitting, by the mobile device, one or more data messages via one or more transceivers using the one or more transmission authentication information instead of the vehicle.

[0180] Clause 2: Obtaining the one or more transmission authentication information comprises transmitting to the certification authority the vehicle functions, the mobile device functions, and a public key generated by the mobile device, wherein the transmission authentication information comprises the public key generated by the mobile device encrypted with a secret key associated with the certification authority, the method according to clause 1.

[0181] Clause 3: Transmitting the one or more data messages comprises obtaining data from at least one of sensors of the mobile device, the vehicle, or sensors of the vehicle; encrypting the data to generate encrypted data, wherein encrypting the data utilizes a secret key associated with a public key generated by the mobile device; generating, by the mobile device, a digital signature for the one or more data messages using the secret key associated with the public key generated by the mobile device, wherein the one or more data messages, when transmitted, comprise the encrypted data, the digital signature, and the transmission authentication information, the method according to clause 2.

[0182] Clause 4: The transmission authentication information is generated by an authentication authority based at least in part on a determination that the vehicle function and the mobile device function satisfy a set of transmission threshold requirements, by the method described in any one of Clauses 1 to 3.

[0183] Clause 5: The transmission authentication information is associated with one or more specific types of data for which transmission authority is granted to the mobile device, and the mobile device is configured to restrict the data to be transmitted to one or more specific types of data, by the method described in any one of Clauses 1 to 4.

[0184] Clause 6: Further comprising providing at least one transmission authentication information to a sensor device, wherein providing at least one transmission authentication information to the sensor device configures the sensor device to transmit data via a network, by the method described in any one of Clauses 1 to 5.

[0185] Clause 7: One or more data messages are formatted according to a vehicle-to-everything communications protocol, by the method described in any one of Clauses 1 to 6.

[0186] Clause 8: Further comprising obtaining received authentication information from an authentication authority by the mobile device, receiving a data message by the mobile device based at least in part on having obtained the received authentication information, and performing one or more operations by the mobile device based at least in part on the received data message, by the method described in any one of Clauses 1 to 7.

[0187] Clause 9: Performing one or more operations comprises generating driving assistance information at least partially based on a received data message, providing the driving assistance information to an output device associated with the mobile device or the vehicle, determining that a data element of the data message corresponds to an additional vehicle function of the vehicle, storing, in the mobile device, the additional vehicle function received from the data message, transmitting at least a portion of the additional vehicle function in one or more data messages, determining whether a trust value associated with a sensor should be adjusted at least partially based on the received data message, or any combination thereof, the method according to Clause 8.

[0188] Clause 10: A mobile device comprising a memory and one or more processors communicatively coupled to the memory, the one or more processors being configured to obtain a vehicle function associated with a vehicle, determine a mobile device function indicating one or more sensors of the mobile device, processing resources, or both, where the vehicle function indicates one or more sensors of the vehicle, obtain, from a certification authority, one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission at least partially based on the vehicle function and the mobile device function, and in response to obtaining the one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, transmit, via one or more transceivers, one or more data messages on behalf of the vehicle using the one or more transmission authentication information.

[0189] Clause 11: Obtaining one or more transmission authentication information comprises transmitting to the certification authority the vehicle function, the mobile device function, and a public key generated by the mobile device, where the transmission authentication information comprises the public key generated by the mobile device encrypted with a private key associated with the certification authority, the mobile device according to Clause 10.

[0190] Clause 12: Sending one or more data messages causes one or more processors to obtain data from at least one of the sensors of the mobile device, the vehicle, or the sensors of the vehicle, encrypt the data to generate encrypted data, where encrypting the data uses a private key associated with the public key generated by the mobile device, generate a digital signature for one or more data messages using the private key associated with the public key generated by the mobile device, and where the one or more data messages, when sent, comprise the encrypted data, the digital signature, and transmission authentication information, for the mobile device described in Clause 11.

[0191] Clause 13: The transmission authentication information is generated by an authentication authority based at least in part on a determination that the vehicle functions and the mobile device functions meet a set of transmission threshold requirements, for the mobile device described in any one of Clauses 10 to 12.

[0192] Clause 14: The transmission authentication information is associated with one or more specific types of data for which transmission authority is granted to the mobile device, and the mobile device is configured to restrict the data to be sent to one or more specific types of data, for the mobile device described in any one of Clauses 10 to 13.

[0193] Clause 15: One or more processors are further configured to provide at least one transmission authentication information to a sensor device, where providing at least one transmission authentication information to a sensor device configures the sensor device to send data over a network, for the mobile device described in any one of Clauses 10 to 14.

[0194] Clause 16: One or more data messages are formatted according to a vehicle-to-vehicle / road-to-vehicle communication protocol, for the mobile device described in any one of Clauses 10 to 15.

[0195] Clause 17: The mobile device according to any one of Clauses 10 to 16 is further configured such that one or more processors obtain received authentication information from a certification authority, receive a data message at least partially based on having obtained the received authentication information, and execute one or more operations at least partially based on the received data message.

[0196] Clause 18: Executing one or more operations causes the one or more processors to generate driving assistance information at least partially based on the received data message, provide the driving assistance information to an output device associated with the mobile device or the vehicle, determine that the data elements of the data message correspond to additional vehicle functions of the vehicle, store in the mobile device the additional vehicle functions received from the data message, transmit at least a portion of the additional vehicle functions in one or more data messages, determine whether a trust value associated with a sensor should be adjusted at least partially based on the received data message, or any combination thereof, for the mobile device according to Clause 17.

[0197] Clause 19: A non - transitory computer - readable medium having instructions stored thereon for transmitting data by a mobile device instead of a vehicle, the instructions, when executed by one or more processors of the mobile device, cause the one or more processors to: obtain vehicle functions related to the vehicle, where the vehicle functions indicate one or more sensors of the vehicle; determine mobile device functions indicating one or more sensors of the mobile device, processing resources, or both, based at least in part on the vehicle functions and the mobile device functions; obtain from a certification authority one or more transmission authentication information for vehicle - to - vehicle / road - to - vehicle transmission; and in response to obtaining the one or more transmission authentication information for vehicle - to - vehicle / road - to - vehicle transmission, transmit one or more data messages using the one or more transmission authentication information via one or more transceivers of the mobile device instead of the vehicle.

[0198] Clause 20: Transmitting one or more data messages causes the one or more processors to: obtain data from at least one of the sensors of the mobile device, the vehicle, or the sensors of the vehicle; encrypt the data to generate encrypted data, where encrypting the data uses a private key associated with a public key generated by the mobile device; generate a digital signature for the one or more data messages using the private key associated with the public key generated by the mobile device; and where the one or more data messages, when transmitted, comprise the encrypted data, the digital signature, and the transmission authentication information. The non - transitory computer - readable medium according to Clause 19.

[0199] Clause 21: The transmission authentication information is associated with one or more specific types of data for which the transmission authority is granted to the mobile device, and the mobile device is configured to limit the data to be transmitted to the one or more specific types of data. The non - transitory computer - readable medium according to Clause 19 or 20.

[0200] Clause 22: The one or more processors are further configured to provide at least one transmission authentication information to the sensor device, wherein providing the at least one transmission authentication information to the sensor device configures the sensor device to transmit data over the network, a non-transitory computer-readable medium according to any one of Clauses 19 to 21.

[0201] Clause 23: The one or more processors are further configured to obtain received authentication information from a certification authority, receive a data message at least in part based on having obtained the received authentication information, and execute one or more operations at least in part based on the received data message, a non-transitory computer-readable medium according to any one of Clauses 19 to 22.

[0202] Clause 24: Executing the one or more operations further causes the one or more processors to generate driving assistance information at least in part based on the received data message, provide the driving assistance information to an output device associated with the mobile device or vehicle, determine that the data elements of the data message correspond to additional vehicle functions of the vehicle, store in the mobile device the additional vehicle functions received from the data message, transmit at least a portion of the additional vehicle functions in one or more data messages, determine whether a trust value associated with the sensor should be adjusted at least in part based on the received data message, or any combination thereof, a non-transitory computer-readable medium according to Clauses 19 to 23.

[0203] Clause 25: Means for obtaining vehicle functions related to a vehicle, where the vehicle functions indicate one or more sensors of the vehicle, one or more sensors of a mobile device, processing resources, or both, means for determining mobile device functions indicating one or more sensors of the vehicle, processing resources, or both, means for obtaining from a certification authority one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission based at least in part on the vehicle functions and the mobile device functions, and in response to obtaining the one or more transmission authentication information, means for transmitting one or more data messages to at least one other vehicle on behalf of the vehicle using the one or more transmission authentication information via a network. A mobile device comprising these means.

[0204] Clause 26: The means for transmitting one or more data messages further comprises means for obtaining data from at least one of the sensors of the mobile device, the vehicle, or the sensors of the vehicle, means for encrypting the data to generate encrypted data, where encrypting the data uses a private key associated with a public key generated by the mobile device, and means for generating a digital signature for the one or more data messages using the private key associated with the public key generated by the mobile device, where the one or more data messages, when transmitted, comprise the encrypted data, the digital signature, and the transmission authentication information. The mobile device described in Clause 25 further comprising these means.

[0205] Clause 27: The transmission authentication information is associated with one or more specific types of data for which the mobile device is granted transmission authority, and the mobile device is configured to limit the data to be transmitted to the one or more specific types of data. The mobile device described in Clause 25 or 26.

[0206] Clause 28: The mobile device according to any one of Clauses 25 to 27 further comprises means for providing at least one transmission authentication information to the sensor device, wherein providing at least one transmission authentication information to the sensor device configures the sensor device to transmit data via the network.

[0207] Clause 29: The mobile device according to any one of Clauses 25 to 28 further comprises means for obtaining received authentication information from a certification authority, means for receiving a data message at least partially based on having obtained the received authentication information, and means for performing one or more operations at least partially based on the received data message.

[0208] Clause 30: The means for performing one or more operations further comprises means for generating driving assistance information at least partially based on the received data message, means for providing the driving assistance information to an output device associated with the mobile device or the vehicle, means for determining that a data element of the data message corresponds to an additional vehicle function of the vehicle, means for storing in the mobile device the additional vehicle function received from the data message, means for transmitting at least a portion of the additional vehicle function in one or more data messages, means for determining whether a trust value associated with the sensor should be adjusted at least partially based on the received data message, or any combination thereof. The mobile device according to any one of Clauses 25 to 29. The invention described in the claims of the present application at the time of filing is appended below. [C1] A method for transmitting data by a mobile device instead of a vehicle, comprising: acquiring, by the mobile device, vehicle functions related to the vehicle, wherein the vehicle functions indicate one or more sensors of the vehicle; determining, by the mobile device, mobile device functions indicating one or more sensors, processing resources, or both of the mobile device; acquiring, by the mobile device, from an authentication authority, one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission based at least in part on the vehicle functions and the mobile device functions; in response to acquiring the one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, transmitting, by the mobile device, one or more data messages via one or more transceivers using the one or more transmission authentication information instead of the vehicle; A method comprising. [C2] The acquiring of the one or more transmission authentication information comprises transmitting the vehicle functions, the mobile device functions, and a public key generated by the mobile device to the authentication authority, wherein the transmission authentication information comprises the public key generated by the mobile device encrypted with a secret key associated with the authentication authority. The method according to C1. [C3] The transmitting of the one or more data messages comprises: acquiring data from at least one of the sensors of the mobile device, the vehicle, or the sensors of the vehicle; encrypting the data to generate encrypted data, wherein encrypting the data utilizes a secret key associated with the public key generated by the mobile device. The mobile device generates a digital signature for the one or more data messages using the private key associated with the public key generated by the mobile device, where the one or more data messages, when transmitted, comprise the encrypted data, the digital signature, and the transmission authentication information. The method according to C2, comprising: [C4] The method according to C1, wherein the transmission authentication information is generated by the certification authority at least partially based on determining that the vehicle function and the mobile device function satisfy a set of transmission threshold requirements. [C5] The method according to C1, wherein the transmission authentication information is associated with one or more specific types of data for which transmission authority is granted to the mobile device, and the mobile device is configured to limit the data to be transmitted to the one or more specific types of data. [C6] The method according to C1, further comprising providing at least one transmission authentication information to a sensor device, wherein providing the at least one transmission authentication information to the sensor device configures the sensor device to transmit data via a network. [C7] The method according to C1, wherein the one or more data messages are formatted according to a vehicle-to-vehicle / road-to-vehicle communication protocol. [C8] The mobile device obtains reception authentication information from the certification authority. The mobile device receives a data message at least partially based on obtaining the reception authentication information. The mobile device performs one or more operations at least partially based on the received data message. The method according to C1, further comprising: [C9] Performing the one or more operations includes: Generating driving assistance information at least partially based on the received data message; Providing the driving assistance information to an output device associated with the mobile device or the vehicle; Determining that the data elements of the data message comprise additional vehicle functions corresponding to the vehicle; Storing, in the mobile device, the additional vehicle functions received from the data message; Transmitting at least a portion of the additional vehicle functions in one or more data messages. Determining whether to adjust a trust value associated with a sensor based at least in part on the received data message, or any combination thereof The method according to C8, comprising: [C10] A memory, and One or more processors communicatively coupled to the memory, wherein The one or more processors are configured to: Obtain vehicle functions related to a vehicle, the vehicle functions indicating one or more sensors of the vehicle; Determine mobile device functions indicating one or more sensors, processing resources, or both of the mobile device; Obtain, from an authentication authority, one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission based at least in part on the vehicle functions and the mobile device functions; and in response to obtaining the one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, transmit, via one or more transceivers, one or more data messages on behalf of the vehicle using the one or more transmission authentication information A mobile device configured to perform the above. [C11] The mobile device according to C10, wherein obtaining the one or more transmission authentication information comprises transmitting the vehicle functions, the mobile device functions, and a public key generated by the mobile device to the authentication authority, wherein the transmission authentication information comprises the public key generated by the mobile device encrypted with a secret key associated with the authentication authority. [C12] Transmitting the one or more data messages comprises causing the one or more processors to: Obtain data from at least one of the sensors of the mobile device, the vehicle, or the sensors of the vehicle; Encrypt the data to generate encrypted data, wherein encrypting the data utilizes a secret key associated with the public key generated by the mobile device; Generate a digital signature for the one or more data messages using the secret key associated with the public key generated by the mobile device, wherein the one or more data messages, when transmitted, comprise the encrypted data, the digital signature, and the transmission authentication information. The mobile device according to C11, which causes the operation to be performed. [C13] The mobile device according to C10, wherein the transmission authentication information is generated by the certification authority at least partially based on determining that the vehicle function and the mobile device function satisfy a set of transmission threshold requirements. [C14] The mobile device according to C10, wherein the transmission authentication information is associated with one or more specific types of data for which transmission authority is granted to the mobile device, and the mobile device is configured to restrict the data to be transmitted to the one or more specific types of data. [C15] The mobile device according to C10, wherein the one or more processors are further configured to provide at least one transmission authentication information to a sensor device, and providing the at least one transmission authentication information to the sensor device configures the sensor device to transmit data via a network. [C16] The mobile device according to C10, wherein the one or more data messages are formatted according to a vehicle-to-vehicle / road-to-vehicle communication protocol. [C17] The one or more processors are configured to obtain received authentication information from the certification authority, receive a data message at least partially based on having obtained the received authentication information, and perform one or more operations at least partially based on the received data message The mobile device according to C10, which is further configured to perform. [C18] Performing the one or more operations causes the one or more processors to generate driving assistance information at least partially based on the received data message, provide the driving assistance information to an output device associated with the mobile device or the vehicle, determine that a data element of the data message comprises an additional vehicle function corresponding to the vehicle, store, in the mobile device, the additional vehicle function received from the data message, transmit at least a portion of the additional vehicle function in one or more data messages, determine whether a trust value associated with a sensor should be adjusted at least partially based on the received data message, or any combination thereof The mobile device according to C17, which further causes to be performed. [C19] A non-transitory computer-readable medium storing instructions for transmitting data by a mobile device instead of a vehicle, wherein the instructions, when executed by one or more processors of the mobile device, cause the one or more processors to obtain vehicle functions related to the vehicle, wherein the vehicle functions indicate one or more sensors of the vehicle, determine mobile device functions indicating one or more sensors of the mobile device, processing resources, or both, obtain, from a certification authority, one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission based at least in part on the vehicle functions and the mobile device functions; and in response to obtaining the one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, transmit one or more data messages via one or more transceivers of the mobile device using the one or more transmission authentication information instead of the vehicle A non-transitory computer-readable medium that causes the above. [C20] Transmitting the one or more data messages causes the one or more processors to obtain data from at least one of sensors of the mobile device, the vehicle, or sensors of the vehicle, encrypt the data to generate encrypted data, wherein encrypting the data utilizes a private key associated with a public key generated by the mobile device, generate a digital signature for the one or more data messages using the private key associated with the public key generated by the mobile device, wherein the one or more data messages, when transmitted, comprise the encrypted data, the digital signature, and the transmission authentication information The non-transitory computer-readable medium according to C19 that causes the above. [C21] The transmission authentication information is associated with one or more specific types of data for which transmission authority is granted to the mobile device, and the mobile device is configured to restrict the data to be transmitted to the one or more specific types of data. The non-transitory computer-readable medium according to C19. [C22] One or more processors are further configured to provide at least one transmission authentication information to a sensor device, wherein providing the at least one transmission authentication information to the sensor device configures the sensor device to transmit data via a network, a non-transitory computer-readable medium as described in C19. [C23] The one or more processors are to obtain received authentication information from the certification authority, to receive a data message at least partially based on obtaining the received authentication information, and to perform one or more operations at least partially based on the received data message and are further configured to do so, a non-transitory computer-readable medium as described in C19. [C24] Performing the one or more operations causes the one or more processors to generate driving assistance information at least partially based on the received data message, to provide the driving assistance information to an output device associated with the mobile device or the vehicle, to determine that a data element of the data message comprises an additional vehicle function corresponding to the vehicle, to store, in the mobile device, the additional vehicle function received from the data message, to transmit at least a portion of the additional vehicle function in one or more data messages, to determine whether a trust value associated with the sensor should be adjusted at least partially based on the received data message, or any combination thereof and further causes to do so, a non-transitory computer-readable medium as described in C23. [C25] means for obtaining vehicle functions associated with a vehicle, the vehicle functions indicating one or more sensors of the vehicle, means for determining mobile device functions indicating one or more sensors, processing resources, or both of a mobile device, means for obtaining, from a certification authority, one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission at least partially based on the vehicle functions and the mobile device functions, means for transmitting, in response to obtaining the one or more transmission authentication information, one or more data messages to at least one other vehicle on behalf of the vehicle using the one or more transmission authentication information via a network A mobile device comprising [C26] The means for transmitting the one or more data messages Means for obtaining data from at least one of the sensors of the mobile device, the vehicle, or the sensors of the vehicle Means for encrypting the data to generate encrypted data, wherein encrypting the data utilizes a private key associated with a public key generated by the mobile device Means for generating a digital signature for the one or more data messages using the private key associated with the public key generated by the mobile device, wherein the one or more data messages, when transmitted, comprise the encrypted data, the digital signature, and the transmission authentication information The mobile device according to C25, further comprising [C27] The transmission authentication information is associated with one or more specific types of data for which transmission authority is granted to the mobile device, and the mobile device is configured to restrict the data to be transmitted to the one or more specific types of data. The mobile device according to C25 [C28] The mobile device according to C25, further comprising means for providing at least one transmission authentication information to a sensor device, wherein providing the at least one transmission authentication information to the sensor device configures the sensor device to transmit data via a network [C29] Means for obtaining received authentication information from the certification authority Means for receiving a data message at least partially based on having obtained the received authentication information Means for performing one or more operations at least partially based on the received data message The mobile device according to C25, further comprising [C30] The means for performing one or more operations Means for generating driving assistance information at least partially based on the received data message Means for providing the driving assistance information to an output device associated with the mobile device or the vehicle Means for determining that the data elements of the data message comprise additional vehicle functions corresponding to the vehicle In the mobile device, means for storing the additional vehicle functions received from the data message means for transmitting at least a part of the additional vehicle functions in one or more data messages means for determining whether a trust value associated with a sensor should be adjusted based at least in part on the received data message, or any combination thereof The mobile device according to C25, further comprising

Claims

**Claim 1** A method for transmitting data by a mobile device instead of a vehicle, comprising: obtaining, by the mobile device, vehicle functions associated with the vehicle, wherein the vehicle functions indicate one or more sensors of the vehicle; determining, by the mobile device, mobile device functions indicating one or more sensors of the mobile device, processing resources, or both; obtaining, by the mobile device, from an authentication authority, one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, at least partially based on the vehicle functions and the mobile device functions, wherein obtaining the one or more transmission authentication information comprises transmitting the vehicle functions, the mobile device functions, and a public key generated by the mobile device to the authentication authority, and the obtained one or more transmission authentication information comprises the public key generated by the mobile device encrypted with a secret key associated with the authentication authority; in response to obtaining the one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, transmitting, by the mobile device, one or more data messages via one or more transceivers, using the one or more transmission authentication information, instead of the vehicle; A method comprising the above steps. **Claim 2** The step of transmitting the one or more data messages comprises: obtaining data from at least one of the sensors of the mobile device, the vehicle, or the sensors of the vehicle; encrypting the data to generate encrypted data, wherein encrypting the data uses a secret key associated with the public key generated by the mobile device; generating, by the mobile device, a digital signature for the one or more data messages using the secret key associated with the public key generated by the mobile device, wherein when the one or more data messages are transmitted, they comprise the encrypted data, the digital signature, and the one or more transmission authentication information; The method according to claim 1, comprising the above steps. **Claim 3** The method according to claim 1, wherein the one or more transmission authentication information is generated by the certification authority based at least in part on a determination that the vehicle function and the mobile device function satisfy a set of transmission threshold requirements.

4. The method according to claim 1, wherein the one or more transmission authentication information is associated with one or more specific types of data for which transmission authority is granted to the mobile device, and the mobile device is configured to restrict the data to be transmitted to the one or more specific types of data.

5. The method according to claim 1, wherein the one or more data messages are formatted according to a vehicle-to-vehicle / road-to-vehicle communication protocol.

6. obtaining received authentication information from the certification authority by the mobile device; receiving a data message by the mobile device based at least in part on having obtained the received authentication information; performing one or more operations by the mobile device based at least in part on the received data message The method according to claim 1, further comprising.

7. Performing the one or more operations includes: generating driving assistance information based at least in part on the received data message; providing the driving assistance information to an output device associated with the mobile device or the vehicle; determining that the data elements of the data message comprise additional vehicle functions corresponding to the vehicle; storing, in the mobile device, the additional vehicle functions received from the data message; transmitting at least a portion of the additional vehicle functions in one or more data messages; determining whether a trust value associated with a sensor should be adjusted based at least in part on the received data message; or any combination thereof The method according to claim 6, comprising.

8. means for obtaining vehicle functions associated with a vehicle, the vehicle functions indicating one or more sensors of the vehicle; means for determining mobile device functions indicating one or more sensors, processing resources, or both of the mobile device; Means for obtaining, from a certification authority, one or more transmission authentication information for vehicle-to-vehicle / road-to-vehicle transmission, at least partially based on the vehicle function and the mobile device function, wherein obtaining the one or more transmission authentication information comprises transmitting the vehicle function, the mobile device function, and a public key generated by the mobile device to the certification authority, and the obtained one or more transmission authentication information comprises the public key generated by the mobile device encrypted with a private key associated with the certification authority. Means for transmitting, via a network, one or more data messages to at least one other vehicle on behalf of the vehicle, using the one or more transmission authentication information, in response to obtaining the one or more transmission authentication information. A mobile device comprising the above.

9. The means for transmitting the one or more data messages Means for obtaining data from at least one of the sensors of the mobile device, the vehicle, or the sensors of the vehicle. Means for encrypting the data to generate encrypted data, wherein encrypting the data uses a private key associated with the public key generated by the mobile device. Means for generating a digital signature for the one or more data messages using the private key associated with the public key generated by the mobile device, wherein the one or more data messages, when transmitted, comprise the encrypted data, the digital signature, and the one or more transmission authentication information. The mobile device according to claim 8, further comprising the above.

10. The one or more transmission authentication information is associated with one or more specific types of data for which transmission authority is granted to the mobile device, and the mobile device is configured to limit the data to be transmitted to the one or more specific types of data. The mobile device according to claim 8.

11. Means for obtaining reception authentication information from the certification authority. Means for receiving a data message, at least partially based on obtaining the reception authentication information. means for performing one or more operations based at least in part on the received data message The mobile device according to claim 8, further comprising the same. **Claim 12**: A non-transitory computer-readable medium storing instructions for transmitting data by a mobile device instead of a vehicle, the instructions causing, when executed by one or more processors of the mobile device, the one or more processors to perform the method according to any one of claims 1 to 7.

Images