Method for approximating time, vehicle and computer readable medium

Abstract

Example operations include one or more of determining, by the transportation vehicle, that a problem will occur soon, determining, by the transportation vehicle, a time at which a problem will occur, and displaying, by the transportation vehicle, the time at which the problem will occur. The problem is based on sensor data that approaches a threshold within a time period that is faster than an average time period.

Description

Technical Field

[0001] This application relates to methods, means of transport, and computer-readable media for approximating the time of a problem. Background Technology

[0002] Vehicles or means of transport, such as cars, motorcycles, trucks, airplanes, and trains, typically provide transportation services to passengers and / or goods in various ways. Functions associated with these means of transport can be identified and utilized by various computing devices, such as smartphones or computers located on or outside the vehicle. Summary of the Invention

[0003] One example embodiment provides a method comprising one or more of the following: determining, by means of a vehicle, that a problem will occur soon; determining, by means of the vehicle, the time when the problem will occur; and displaying, by means of the vehicle, the time when the problem will occur. The problem is based on sensor data approaching a threshold within a time period faster than the average time period.

[0004] Another example embodiment provides a system including a memory communicatively coupled to a processor, wherein the processor is configured to determine, via a vehicle, that a problem will occur soon, via a vehicle, the time when a problem will occur, and via a vehicle, display the time when a problem will occur. The problem is based on sensor data approaching a threshold within a time period faster than the average time period.

[0005] Another example embodiment provides a non-transient computer-readable medium including instructions that, when read by a processor, cause the processor to execute one or more of the following: a determination by the transportation vehicle that a problem will occur soon, a determination by the transportation vehicle of the time when a problem will occur, and a display by the transportation vehicle of the time when a problem will occur. The problem is based on sensor data approaching a threshold within a time period faster than the average time period. Attached Figure Description

[0006] Figure 1A An example flowchart illustrating the display of transportation vehicle data according to an example embodiment is shown.

[0007] Figure 1B Another example transportation vehicle diagram is illustrated, showing transportation vehicle data according to an example embodiment.

[0008] Figure 2A The diagram illustrates a transportation network according to an example embodiment.

[0009] Figure 2B The illustration shows another transportation network diagram according to an example embodiment.

[0010] Figure 2CThe illustration shows another transportation network diagram according to an example embodiment.

[0011] Figure 2D The illustration shows another transportation network diagram according to an example embodiment.

[0012] Figure 2E The illustration shows another transportation network diagram according to an example embodiment.

[0013] Figure 2F The diagram illustrates the electrification of one or more components according to an example embodiment.

[0014] Figure 2G The diagram illustrates the interconnections between different elements according to an example embodiment.

[0015] Figure 2H Other diagrams illustrating interconnections between different elements according to an example embodiment are shown.

[0016] Figure 2I Additional diagrams illustrating the interconnections between depicting elements according to an example embodiment are shown.

[0017] Figure 2J Other diagrams depicting a keyless entry system according to an example embodiment are illustrated.

[0018] Figure 2K Further diagrams depicting a CAN within a vehicle, according to an example embodiment, are illustrated.

[0019] Figure 2L Other diagrams depicting an end-to-end communication channel according to an example embodiment are illustrated.

[0020] Figure 2M Additional figures illustrating an example of a transportation vehicle using a security certificate to perform secure V2V communication, according to an example embodiment.

[0021] Figure 3A The illustration shows a flowchart of transportation vehicle data display according to an example embodiment.

[0022] Figure 3B Another flowchart illustrating the identification of vehicle data display according to an example embodiment is shown.

[0023] Figure 3C Another flowchart illustrating the identification of vehicle data display according to an example embodiment is shown.

[0024] Figure 4 The diagram illustrates a machine learning transportation network according to an example embodiment.

[0025] Figure 5AThe illustration shows an example vehicle configuration for managing database transactions associated with a vehicle, according to an example embodiment.

[0026] Figure 5B The illustration shows another example vehicle configuration for managing database transactions between various vehicles, according to an example embodiment.

[0027] Figure 6A The diagram illustrates a blockchain architecture configuration according to an example embodiment.

[0028] Figure 6B Another blockchain configuration according to an example embodiment is illustrated.

[0029] Figure 6C The illustration shows a blockchain configuration for storing blockchain transaction data according to an example embodiment.

[0030] Figure 6D An example data block according to an example embodiment is illustrated.

[0031] Figure 7 An example system supporting one or more of the example embodiments is illustrated. Detailed Implementation

[0032] As will be readily understood, as generally described and illustrated in the accompanying drawings, this component can be arranged and designed in a wide variety of different configurations. Therefore, the following detailed description of at least one embodiment of the methods, apparatus, non-transient computer-readable media, and systems presented in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments.

[0033] Communication between a vehicle and entities such as remote servers, other vehicles, and local computing devices (e.g., smartphones, personal computers, vehicle-embedded computers, etc.) can be sent and / or received and processed by one or more “components,” which may be hardware, firmware, software, or a combination thereof. Components may be part of any of these entities or computing devices or certain other computing devices. In one example, consensus decisions related to blockchain transactions may be performed by one or more computing devices or components (which may be any elements described and / or depicted herein) associated with one or more vehicles, as well as by one or more components located outside or remotely from the vehicle.

[0034] The features, structures, or characteristics described throughout this specification can be combined in one or more embodiments in any suitable manner. For example, the use of phrases such as “example embodiment,” “some embodiments,” or other similar language in this specification refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment can be included in at least one embodiment. Therefore, the appearance of phrases such as “example embodiment,” “some embodiments,” “other embodiments,” or other similar language throughout this specification does not necessarily refer to the same set of embodiments, and the described features, structures, or characteristics can be combined in one or more embodiments in any suitable manner. In the figures, even if the depicted connections are unidirectional or bidirectional arrows, any connection between elements may permit unidirectional and / or bidirectional communication. In the present solution, the means of transportation may include one or more of automobiles, trucks, pedestrian zone battery electric vehicles (BEVs), e-Palettes, fuel cell buses, motorcycles, scooters, bicycles, ships, recreational vehicles, aircraft, and any object that can be used to transport people and / or goods from one location to another.

[0035] Additionally, although the term "message" may be used in the description of the embodiments, other types of network data such as packets, frames, datagrams, etc., may also be used. Furthermore, although certain types of messages and signaling may be depicted in the exemplary embodiments, they are not limited to specific types of messages and signaling.

[0036] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide at least one of the following: a means of transport (also referred to herein as a vehicle or automobile), a data collection system, a data monitoring system, an authentication system, an authorization system, and a vehicle data distribution system. Vehicle status data received in the form of communication messages, such as wireless data network communications and / or wired communication messages, can be processed to identify vehicle / transportation status and provide feedback on the status and / or changes of the means of transport. In one example, a user profile can be applied to a specific means of transport / vehicle to authorize current vehicle events, service stops at service stations, authorization of subsequent vehicle rental services, and enable the vehicle to conduct vehicle communications.

[0037] Within a communication infrastructure, a decentralized database is a distributed storage system comprising multiple nodes that communicate with each other. A blockchain is an example of a decentralized database, comprising an append-only immutable data structure (i.e., a distributed ledger) capable of maintaining records between untrusted parties. Untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify a database record until consensus is reached among the distributed peers. For example, peers can execute consensus protocols to verify blockchain storage entries, group storage entries into blocks, and construct a hash chain via blocks. For consistency, this process forms the ledger by ordering storage entries as necessary. In public or permissionless blockchains, anyone can participate without specific identification. Public blockchains can involve cryptocurrencies and use consensus based on various protocols such as Proof-of-Work (PoW). Conversely, permissioned blockchain databases can ensure interactions between a group of entities sharing a common goal but not trusting or fully trusting each other, such as business parties exchanging funds, goods, or information. This solution can work in both permissioned and / or permissionless blockchain settings.

[0038] Smart contracts are trusted, distributed applications that leverage the tamper-proof nature of shared or distributed ledgers (which can take the form of blockchains) and underlying protocols between member nodes, known as endorsements or endorsement policies. Typically, blockchain entries are "endorsed" before being submitted to the blockchain, while unendorsed entries are ignored. A typical endorsement policy allows the smart contract executable code to specify the endorsers of an entry in the form of a set of peer nodes necessary for endorsement. When a client sends an entry to the peers specified in the endorsement policy, the entry is executed to verify it. After verification, the entry enters a sorting phase, where a consensus protocol is used to generate a sorted sequence of endorsed entries grouped into blocks.

[0039] A node is a communication entity in a blockchain system. In the sense that multiple nodes of different types can run on the same physical server, a "node" can perform logical functions. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. Nodes can include different types, such as client or submitting client nodes, that submit entry requests to endorsers (e.g., peers) and broadcast entry suggestions to ordering services (e.g., ordering nodes). Another type of node is a peer node, which can receive entries submitted by clients, submit the entries, and maintain the state and copy of the ledger of blockchain entries. Peers can also act as endorsers. Ordering service nodes or orderers are nodes that run communication services for all nodes and implement delivery guarantees such as broadcasting to every peer in the system when an entry is submitted and the world state of the blockchain is modified. The world state can constitute the initial blockchain entry, which typically includes control and setup information.

[0040] A ledger is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions can be triggered by smart contract executable code calls (i.e., entries) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). An entry is a set of asset key-value pairs submitted to the ledger as one or more operands such as create, update, delete, etc. The ledger includes a blockchain (also known as a chain) used to store immutable, sequential records in blocks. The ledger also includes a state database that keeps track of the current state of the blockchain. Each channel typically has one ledger. Each peer node maintains a copy of the ledger for its respective channel.

[0041] A chain is a log of entries constructed as hashed linked blocks, with each block containing a sequence of N entries, where N is equal to or greater than 1. The block header includes the hash of the block's entries as well as the hash of the headers of previous blocks. In this way, all entries on the ledger can be ordered and cryptographically linked together. Therefore, the ledger data cannot be tampered with without breaking the hash chain. The hash of the most recently added blockchain block represents every entry on the chain that arrived before it, thus ensuring that all peer nodes are in a consistent and trusted state. This chain can be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), effectively supporting the append-only nature of blockchain workloads.

[0042] The current state of the immutable ledger represents the latest values ​​of all keys included in the chain entry log. Because the current state represents the latest key values ​​known to the channel, it is sometimes referred to as the world state. Smart contract executables invoke entries that refer to the current state data of the ledger. To enable effective interaction between these smart contract executables, the latest values ​​of the keys can be stored in a state database. The state database can simply be an indexed view of the chain entry log and can therefore be regenerated from the chain at any time. The state database can be automatically restored after peer startup but before entries are accepted (or generated when needed).

[0043] The difference between blockchain and traditional databases is that blockchain is not a central storage, but a decentralized, immutable, and secure storage where nodes must share changes to the records in the storage. Some inherent properties of blockchain that contribute to its realization include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility.

[0044] Example embodiments provide services to specific vehicles and / or user profiles applied to vehicles. For example, a user could be a vehicle owner or an operator of a vehicle owned by another party. Vehicles may require service at certain intervals, and service requests may require authorization before being authorized to receive service. Additionally, service centers can provide services to vehicles in a nearby area based on the vehicle's current route plan and relative service level requirements (e.g., immediate, severe, intermediate, minor, etc.). Vehicle demand can be monitored via one or more vehicle and / or road sensors or cameras, which report the sensed data to a central controller computer device located inside and / or separate from the vehicle. This data is forwarded to a management server for viewing and action. Sensors can be located on one or more of the following: inside the vehicle, outside the vehicle, on a fixed object separate from the vehicle, or on another vehicle nearby. Sensors can also be associated with the vehicle's speed, braking, acceleration, fuel level, service demand, gear changes, steering, etc. As described herein, sensors can also be devices such as wireless devices located in and / or near the vehicle. Additionally, sensor information can be used to identify whether a vehicle is operating safely and whether occupants have been involved in any unforeseen vehicle situations (such as during vehicle entry, exit, and / or usage periods). Vehicle information collected before, during, and / or after vehicle operation can be identified and stored in transactions on a shared / distributed ledger, which can be generated and submitted, for example, via a blockchain membership group to an immutable ledger determined by a permissioned consortium and thus in a “decentralized” manner.

[0045] Each stakeholder (i.e., owners, users, companies, agents, etc.) may wish to restrict the disclosure of private information; therefore, blockchain and its immutability can be used to manage permissions for each specific user's vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / checks, apply vehicle event permissions, determine when service is needed, identify collision and / or degradation events, identify safety issue events, identify event participants, and distribute such vehicle event data to registered entities seeking access. Furthermore, outcomes can be identified, and necessary information can be shared among registered companies and / or individuals based on consensus methods associated with the blockchain. This approach cannot be implemented on traditional centralized databases.

[0046] The various driving systems in this solution can utilize software, sensor arrays, machine learning capabilities, light detection and ranging (LIDAR) projectors, radar, ultrasonic sensors, etc., to create maps of terrain and roads that the vehicle can use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, etc., can also replace LIDAR in autonomous vehicles.

[0047] In some embodiments, this solution includes authorizing the service to the vehicle via an automated and rapid authentication scheme. For example, the vehicle operator or autonomous vehicle may drive to a charging station or fuel pump, and if the service and / or charging station receives authorization, authorization to receive electricity or fuel can be executed without any delay. The vehicle may provide a communication signal identifying it with a current activity profile linked to the authorized account receiving the service, which can later be corrected through compensation. Additional measures may be used to provide further authentication, such as wirelessly sending another identifier from the user's device to the service center to replace or supplement the initial authorization work between the vehicle and the service center with additional authorization work.

[0048] Shared and received data can be stored in a database that keeps the data in a single location (e.g., a database server). This location is often a central computer, such as a desktop central processing unit (CPU), server CPU, or mainframe computer. Information stored in a centralized database is typically accessible from multiple different points. Centralized databases are easy to manage, maintain, and control, especially for security purposes, due to their single location. Within a centralized database, data redundancy is minimized because the single storage location of all data also means that a given set of data has only one master record. Blockchain can be used to store data and transactions related to transportation.

[0049] Any of the actions described herein can be performed by one or more processors (such as microprocessors, sensors, ECUs, host computers, etc.) that may be located on or outside the vehicle. One or more processors may communicate with other processors on or outside the vehicle to utilize data being transmitted by the vehicle. One or more processors and other processors may send data, receive data, and utilize that data to perform one or more of the actions described or depicted herein.

[0050] Transportation vehicles typically display numerous parameters related to the vehicle and its operating conditions. During normal operation, no warning lights or other forms of alerts are displayed, and vehicle occupants may wish to simply verify the vehicle's status or view its current operational condition. During abnormal operation, one or more warning lights or warning notices may be displayed when a problem has occurred. This alerts the driver or vehicle occupants that the problem needs to be addressed immediately (as it has already occurred). This application addresses the problem of predicting between these two scenarios.

[0051] Figure 1A The diagram illustrates an example flowchart for displaying 100 on transportation vehicle data. Figure 1A The diagram illustrates a flowchart of the message flow between three entities: sensor 110, vehicle 120, and vehicle display 130. Sensor 110 can be a sensor of vehicle 120 or a sensor external to vehicle 120. For example, sensor 110 can be a sensor of a different vehicle, a sensor 110 located near vehicle 120, or a sensor 110 within the detection range of vehicle 120. Examples of sensor 110 may include, but are not limited to, cameras (still frame and video cameras), microphones, optical sensors, magnetic sensors, temperature or pressure sensors, shock or vibration sensors, or any other type of sensor known in the art. Vehicle 120 can be any kind of vehicle capable of transporting or conveying any combination of occupants or cargo. Vehicle 120 may include any processor associated with vehicle 120, including but not limited to vehicle computers and infotainment systems, navigation computers, ECUs, or any other components in the vehicle including processors and memory. Vehicle display 130 is a device that presents a visual image to the driver or occupants of vehicle 120, and references... Figure 1B To describe in more detail.

[0052] Sensor 110 can acquire sensor data 112 via any wired or wireless device. The acquired sensor data 112 can originate from equipment within / on the transport vehicle 120 itself, from another nearby transport vehicle, or from sources external to the transport vehicle 120 such as weather satellites, buildings, TV or radio stations, the Internet, networks, or the cloud. Sensor 110 can represent one sensor 110 or multiple sensors 110, and the number of sensors 110 from which sensor data 112 is acquired can vary over time. After acquiring sensor data 112, sensor 110 transmits sensor data 114 to the transport vehicle 120. Sensor data 114 can be transmitted via a wired or wireless interface.

[0053] After receiving sensor data 114 from sensor 110, vehicle 120 determines a problem 122 based on the received sensor data 114. In one embodiment, vehicle 120 determines that a problem will occur soon based on the received sensor data 114. This problem is based on sensor data 114 approaching a threshold within a period earlier than the average time period. The threshold may represent the level of sensor data 114 corresponding to the time when a change to vehicle 120, a change in the operation of vehicle 120, or a safety-related concern should or must be addressed. The period earlier than the average time period occurs before the average time period. In one embodiment, vehicle 120 may review the received sensor data 114 over time and establish a rate of change for the sensor data 114. This allows vehicle 120 to predict future values ​​of sensor data 114. In one embodiment, the problem may include maintenance recommendations that may be based on a maintenance schedule corresponding to vehicle 120. In another embodiment, the problem may include a safety warning.

[0054] In one embodiment, the average time period may be based on the history of the problem experienced by vehicle 120, other vehicles, and / or similar types of vehicles. In another embodiment, the average time period may be based on one or more predetermined (factory) expected nominal maintenance intervals for vehicle 120, other vehicles, and / or similar types of vehicles. In yet another embodiment, the average time period may take into account season, geographical conditions, weather (temperature, humidity, wind, snowfall, precipitation), driver identity, and / or historical acceleration, braking, shifting, and / or steering data corresponding to the current driver of vehicle 120. Additionally, vehicle 120 determines the time 124 when the problem will occur and provides the time 126 when the problem will occur to vehicle display 130. Relative to Figure 1B A more detailed description of the vehicle display 130.

[0055] Vehicle 120 can determine when a problem will occur in several different ways. In one embodiment, a processor in the electronic control unit (ECU) can continuously monitor oil pressure within the engine. Over time, the ECU processor can detect a steady rise in oil pressure. High oil pressure can occur when oil requires external force to be pumped through the engine. The amount of pressure required to push the oil through the engine is set as a default parameter. In many common vehicles, if the reading is slightly close to 80 pounds per square inch (psi) or greater, it indicates that the vehicle should be considered for immediate repair. In another embodiment, a processor in the navigation system can detect that vehicle 120 does not have a map corresponding to its current location. After a series of such readings, vehicle 120 can conclude that it should obtain the required map or notify the vehicle occupants and / or the vehicle owner to obtain the required map.

[0056] The vehicle display 130 can receive the time 126 when a problem will occur via any wired or wireless device. After receiving the time 126 when a problem will occur, the vehicle display 130 displays the time 132 when a problem will occur on one or more vehicle displays 130. In one embodiment, displaying sensor data 114 may include verbally notifying the occupants of one or more vehicles 120, or using sound or other visual indicators. In one embodiment, the displayed information may be directly related to one or more sensors 110 affected based on the current drive of the vehicle 120. Information may be provided as sensor data 114 when a problem is eventually to occur.

[0057] In one embodiment, the time when a problem will occur 126 may be based on a single type of sensor data 114. In another embodiment, the time when a problem will occur 126 may be based on multiple types of sensor data 114. In yet another embodiment, the time when a problem will occur 126 may be based on a single instance of sensor data 114. In one embodiment, the time when a problem will occur 126 may be based on multiple instances of sensor data 114.

[0058] Sensor data 114 may include any combination of text, audio, still images, video, telemetry, GPS coordinates, brainwaves, numerical values, or odors. Sensor data 114 may originate from one or more sensors 110 on the vehicle 120, from another vehicle (such as a camera viewing the area of ​​interest of the vehicle 120, such as from a spark below the vehicle 120, smoke from the vehicle 120, etc.), an aircraft or drone, or from buildings or structures near the road on which the vehicle 120 is traveling.

[0059] In one embodiment, the vehicle display 130 always displays the most recently received sensor data 114 based on the current condition and environment of the vehicle 120. In another embodiment, the vehicle display 130 always displays all received sensor data 114 within a predetermined period based on the current condition and environment of the vehicle 120. The predetermined period can be measured in seconds, minutes, hours, days, weeks, or years. These conditions, environments, and predetermined periods can change unpredictably, resulting in changes to the display of sensor data 114. Sensor data 114 can include various data entries with different levels of importance. More important sensor data 114 can include data that has a more important sequence than other data for the vehicle 120, the vehicle owner, or the vehicle occupants, or data that has a stronger current time impact than other data. For example, sensor data 114 indicating a potential immediate collision of the vehicle 120 may be considered more important than sensor data 114 indicating the current fuel level. Sensor data 114 indicating road conditions over the next 300 feet may be considered more important than road conditions one mile ahead. One or more processors associated with the vehicle 120 can make this determination. These one or more processors receive sensor data 114 from sensor 110, other vehicles, satellites, and any combination of internal or external devices, identify and classify the type and quantity of the received data 114, and determine its importance based on the type and classification of the sensor data 114.

[0060] In one embodiment, the displayed sensor data 114 may vary based on the eye position of the vehicle driver or another vehicle occupant. The vehicle 120 may include eye position sensors capable of detecting when a driver or occupant is looking at the vehicle display 130 or other locations. For example, the vehicle 120 may determine that the driver is looking at the vehicle display 130 and display sensor data 114 associated with driving or navigation conditions. When the eye position sensors determine that the driver is not looking at the vehicle display 130, the vehicle display 130 may alternatively blank the display to eliminate potential distractions. This advantageously minimizes the possibility of driver distraction while providing the driver with safe and useful driving information when desired.

[0061] In one embodiment, when important data needs to be presented on the vehicle display 130, the data can be displayed in an incremental manner. In one embodiment, this incremental manner continues until the eye sensor confirms that the driver is looking at the vehicle display 130. Based on the importance of the sensor data 114, the incremental manner can mean increasing the font size, changing the text color, flashing the text, producing an audible sound, vibrating the steering wheel and / or seat, etc. The importance of sensor data 114 can be determined in various ways. For example, sensor data 114 that can be used to mitigate injury to vehicle occupants or damage to the vehicle 120 (such as sensor data 114 reporting that the vehicle 120 is traveling on a road opposite a one-way sign) can be considered important sensor data 114, while sensor data 114 that can indicate that radio programming does not reflect the current preferences of the vehicle driver can be considered unimportant. It should be understood that only important sensor data 114 can be shown so as not to distract the driver. Initially, sensor data 114 may simply be displayed, but when one or more sensors do not indicate that the driver's eyes are looking at the vehicle display 130, one or more processors in the vehicle 120 may increase attempts to notify the driver and / or one or more occupants. Visual and / or auditory alarms may be increased in proportion to the importance of sensor data 114.

[0062] In one embodiment, the vehicle 120 may be stationary rather than moving. The vehicle 120 may be stationary due to being parked, in a garage, unoccupied, or for any other reason. In some embodiments, the vehicle 120 may be stationary and inactive. When stationary, the vehicle 120 may determine a problem as previously described. For example, the vehicle 120 may detect a tire pressure leak approaching a tire pressure threshold. In response, the vehicle 120 may notify one or more devices associated with the vehicle 120 or the owner of the vehicle 120 of the problem. This device may include, but is not limited to, a vehicle computer, a vehicle display 130, and / or occupant equipment 156.

[0063] In one embodiment, vehicle 120 may determine that the time 126 when a problem will occur is earlier than the expected time of arrival at the destination. In one embodiment, the driver or vehicle occupant may have entered or selected the destination into the navigation system of vehicle 120. In another embodiment, the driver or vehicle occupant may have given a voice command to vehicle 120 to specify the destination. In yet another embodiment, vehicle 120 may receive the destination from a source outside vehicle 120. After receiving the destination, vehicle 120 may calculate the expected time to reach the destination from its current location. Vehicle 120 may compare the expected time of arrival at the destination with the expected time 126 when a problem will occur. If the expected time of arrival at the destination is before the time 126 when a problem will occur, vehicle 120 may display both facts on one or more vehicle displays 130 or occupant devices 156, or send a notification to the maintenance facility or equipment corresponding to the owner of vehicle 120. If the expected time of arrival at the destination is after the time 126 when a problem will occur, vehicle 120 may notify the owner of one or more associated devices or vehicles of the problem. In one embodiment, vehicle 120 may suggest rerouting vehicle 120 to an entity that can resolve the problem (such as an open repair shop) instead of its destination. This suggestion may be displayed on vehicle display 130, sent as an email or text message to one or more vehicle occupants or the vehicle owner, invoked through communication devices, and / or presented to vehicle occupants as an audio notification. In one embodiment, vehicle 120 may provide suggestions for mitigating the problem within a period prior to the time 126 when the problem will occur. This suggestion may be made by any known means, including those previously described regarding suggestions.

[0064] In one embodiment, vehicle 120 may broadcast instructions in response to vehicle 120 being manipulated in a manner contrary to sensor data 114. For example, sensor data 114 may indicate that vehicle 120 is in good working order, weather and road conditions are good, and traffic in the area is smooth and unobstructed. If vehicle 120 is manipulated with frequent and / or significant speed and / or steering changes (i.e., steering or frequent lane changes), this may be a symptom of a problem such as a serious medical condition on the part of the driver. In this case, it may be advantageous for vehicle 120 to broadcast instructions of possible or probable medical conditions on vehicle 120 to emergency responders so that appropriate assistance can be directed toward vehicle 120. In one embodiment, vehicle computer within vehicle 120 may receive sensor data 114 indicating steering, acceleration, and braking changes that are significantly different from what the driver of vehicle 120 typically makes. In another embodiment, the voice control computer of vehicle 120 may detect coughs and other sounds from the driver that are determined to be abnormal and identify possible adverse medical conditions on the part of the driver. The vehicle's computer or voice control computer can create a notification to a communication processor within the vehicle or a communication device associated with the vehicle's occupants, which then broadcasts the instruction to emergency responders. As another example, sensor data 114 can indicate traffic stopped ahead of the vehicle 120. If the vehicle 120 does not initiate deceleration, it may be advantageous for the vehicle 120 to provide instructions to emergency responders to immediately mobilize police, fire, EMS, or tow trucks. In one scenario, the driver of the vehicle 120 may be asleep and unaware of the stopped traffic ahead.

[0065] In another embodiment, sensor data 114 may include a timestamp 112 indicating when the data was acquired. The timestamp may reflect the time when sensor 110 generated sensor data 114. The timestamp can provide useful information that can identify current data, older data, or help in data sorting. In response to sensor data 114 representing the same parameter or data type, data with a later timestamp can be displayed. In one embodiment, only sensor data 114 with a later timestamp may be displayed. In some cases, sensor data 114 with older timestamps may be “aged” and eventually replaced by newer data. For example, where displaying a series of data points for a given parameter (e.g., external temperature) might be helpful, vehicle 120 may display the five most recent temperature readings. When a new temperature reading is received from sensor data 114, the oldest of the displayed temperature readings (e.g., five) will be replaced by the newer temperature reading. This feature has the advantage of prioritizing later or newer sensor data 114 over older sensor data 114 and can result in more accurate data being presented on one or more vehicle displays 130.

[0066] In another embodiment, the vehicle 120 may display all received sensor data 114. While this is acceptable for many applications, in applications displaying a large number of entries of sensor data 114, this can lead to cluttered displays and data that is more difficult to identify and understand. In particular, the driver of the vehicle 120 may only be able to glance at the vehicle display 130 while driving to avoid taking their eyes off the road or other vehicles / objects near the vehicle 120. If there are many cluttered data objects on the vehicle display 130, this can make it difficult to identify important data entries. Therefore, if the combination of various sensor data 114 exceeds a threshold amount of data (where the threshold reflects the amount of data that can be identified or understood on the display 130), it may be advantageous to limit the displayed sensor data 114 to less than the threshold amount. One or more processors associated with the vehicle 120 may determine the threshold. In one embodiment, the threshold is a predetermined value that reflects previous human factor studies and analyses. In another embodiment, the threshold may reflect a previous value corresponding to the total amount of data displayed. In yet another embodiment, the threshold may be a value input into the vehicle 120 by the occupants of the vehicle 120. In another embodiment, a stationary vehicle 120 may present an increasing amount of sensor data 114 to the vehicle occupants until the occupants indicate that they have not perceived the most recently displayed sensor data 114. In this case, a threshold may correspond to the amount of sensor data 114 displayed when or before the vehicle 120 receives the indication.

[0067] In one embodiment, sensor data 114 can cause the vehicle 120 to change its operating parameters. These operating parameters (e.g., cruise control settings, headlight control, vehicle audio volume, etc.) can be changed autonomously without directly affecting safety. Alternatively, if safety is directly affected, the vehicle operating parameters can be suggested and required to be approved by the occupants of the vehicle 120 (i.e., without autonomous changes). In one embodiment, a computer associated with the vehicle 120 (referred to as the vehicle computer) analyzes one or more data points, and the vehicle computer initializes the change in the vehicle operating parameters.

[0068] In one embodiment, vehicle 120 may be included within a blockchain network, and vehicle 120 may receive verification of one or more of the following: a problem, sensor data 114, a threshold, and / or the time 126 when a problem will occur. Verification may include blockchain consensus between a peer group consisting of vehicle 120 and one or more other vehicles. In one embodiment, vehicle 120 may execute a smart contract based on blockchain consensus to record the verification and the time 126 when a problem will occur on the blockchain.

[0069] In one possible use case of this application, vehicle 120 can detect that the tire pressure in the tire is approaching a threshold that will trigger a notification. It flashes / displays actual video of vehicle 120 moving with the tire in focus. In another use case, increments can be examined before / after the presentation of video / image sensor data 114. The notification can be associated with vehicle 120 / tire, indicating that the tire pressure has just dropped, such as from 34 psi to 25 psi. The notification can also include history. If the tire pressure threshold is 30 psi and the current pressure drops from 35 psi to 33 psi, the notification can indicate that a problem will occur with the tire in a short time. In this case, the notification can simply provide a heads-up.

[0070] In another possible use case of this application, tire pressure history (such as that received by tire sensor 110) can indicate the severity of a problem. For example, the tire pressure was 36 psi a week ago, 32 psi four days ago, and so on. Based on history and timing, vehicle 120 estimates that the tire pressure threshold will be reached tomorrow. Vehicle 120 and vehicle display 130 can inform the driver that it is approaching or rapidly approaching the threshold. Similar situations may occur with oil pressure, transmission temperature, fluid levels, etc. This will generate actual data when it occurs and generate one or more alarms when it is estimated that a problem will occur soon.

[0071] In yet another possible use case of this application, the vehicle 120 may identify, based on received sensor data 114, faster-than-expected wear on a particular tire as a new problem. The vehicle 120 can then determine wear on other tires and recommend corrective actions. Recommended corrective actions may include replacing the worn tire with a new one, rotating / not rotating the specific tire, adjusting tire pressure, or performing alignment. The recommended actions may be displayed on the vehicle display 130 or otherwise communicated to the driver or occupants of the vehicle 120.

[0072] Figure 1B Other example transportation diagrams are shown in the transportation data display 150. Figure 1B The illustration shows exemplary details of a representative vehicle interior 152, including a front view through the windshield, dashboard, and steering wheel. Vehicle 120 may include multiple data displays 130 to provide visual data to the driver and occupants of vehicle 120. The vehicle dashboard may include a vehicle display 158 typically located in the center. Vehicle display 158 may be a monitor that displays only images and data. In other embodiments, vehicle display 158 may include a touchscreen or other functions that enable data input and manipulation in addition to data display. Data manipulation allows data to be moved, resized, rearranged, added, or deleted by the occupants of vehicle 120. In some embodiments, vehicle display 130 may be a permanently mounted internal display associated with vehicle 120. In other embodiments, vehicle display 130 may be an occupant device 156 that can be removed from vehicle 120. A computer attached to vehicle 120 (not shown) may execute code to process input data and present additional data to be displayed on vehicle display 130. In one embodiment, the vehicle 120 may receive sensor data 114 from one or more sensors 110 associated with the vehicle 120. In another embodiment, the vehicle 120 may receive sensor data 114 from another vehicle 162. In yet another embodiment, the vehicle 120 may receive sensor data 114 from one or more sensors 110 associated with the vehicle 120 as well as from other vehicles 162.

[0073] The vehicle 120 may also include one or more vehicle head-up displays 160. The vehicle 120 may display sensor data 114, a problem or the time 126 of an impending problem, on a windshield or other transparent surface, to overlay the sensor data 114 or the time 126 of an impending problem with images (including roads, traffic, etc.) viewed from outside the vehicle 120. The idea behind the head-up display 160 is to provide helpful data to the driver without requiring them to take their eyes off the road or have their vision obscured. The vehicle 160 may display the sensor data 114 or the time 126 of an impending problem independently or simultaneously on either or both of the vehicle display 158 and / or the head-up display 160. Therefore, sensor data 114 may be displayed simultaneously on the occupant device 156, the vehicle display 158, and the head-up display 160. The time 126 of an impending problem may also be displayed simultaneously on the occupant device 156, the vehicle display 158, and the head-up display 160. The computer of the vehicle 120 can receive sensor data 114 and / or the time 126 when a problem will occur, and send other data to the head-up display 160.

[0074] Figure 2A A transportation network diagram 200 according to an example embodiment is illustrated. The network includes elements including a transport node 202 containing a processor 204 and a transport node 202' including a processor 204'. Transport nodes 202, 202' communicate with each other and with other elements (not shown) including transceivers, transmitters, receivers, memory, sensors, and other elements capable of providing communication, via processors 204, 204'. Communication between transport nodes 202, 202' can occur directly, via private and / or public networks (not shown), or via other transport nodes and elements including one or more of processors, memory, and software. Although depicted as a single transport node and processor, multiple transport nodes and processors may exist. One or more of the applications, features, steps, solutions, etc., described and / or depicted herein may be utilized and / or provided by this element.

[0075] Figure 2BA further transportation network diagram 210 according to an example embodiment is illustrated. The network includes elements including a transportation node 202 containing a processor 204 and a transportation node 202' including a processor 204'. Transportation nodes 202, 202' communicate with each other and with other elements (not shown) including transceivers, transmitters, receivers, memory, sensors, and other elements capable of providing communication, via processors 204, 204'. Communication between transportation nodes 202, 202' can occur directly, via private and / or public networks (not shown), or via other transportation nodes and elements including one or more of processors, memory, and software. Processors 204, 204' can also communicate with one or more elements 230, including sensors 212, wired devices 214, wireless devices 216, databases 218, mobile phones 220, transportation nodes 222, computers 224, I / O devices 226, and voice applications 228. Processors 204, 204' can also communicate with one or more of the following components: processor, memory, and software.

[0076] Although depicted as a single transport node, processor, and element, multiple transport nodes, processors, and elements may exist. Information or communication may enter and / or exit any of processors 204, 204', and element 230. For example, mobile phone 220 may provide processor 204 with information that can initiate transport node 202 to take action, and may also provide processor 204' with information or additional information that can initiate transport node 202' to take action, and may also provide information or additional information to mobile phone 220, transport node 222, and / or computer 224. One or more of the applications, features, steps, solutions, etc., described and / or depicted herein may be utilized and / or provided by this element.

[0077] Figure 2C The illustration shows another transportation network diagram 240 according to an example embodiment. This network includes elements, including nodes 205 containing a processor 204 and a non-transient computer-readable medium 242C. The processor 204 is communicatively coupled to the computer-readable medium 242C and element 230 (in... Figure 2B (As depicted in the text). Node 205 can be a vehicle, server, or any device that includes a processor and memory.

[0078] Processor 204 executes one or more of the following: determining in block 244C that a sensor data-based problem will soon occur on the vehicle; determining in block 246C the time when the problem will occur; and displaying in block 248C the time when the problem will occur. In one embodiment, sensor data 114 may be received from one or more sensors 110 associated with the vehicle 120. In another embodiment, sensor data 114 may be received as sensor data from one or more other vehicles 162.

[0079] Figure 2D The illustration shows another transportation network diagram 250 according to an example embodiment. This network includes elements, including nodes 205 containing a processor 204 and a non-transient computer-readable medium 242D. The processor 204 is communicatively coupled to the computer-readable medium 242D and element 230 (in...). Figure 2B (As depicted in the text). Node 205 can be a vehicle, server, or any device that includes a processor and memory.

[0080] Processor 204 executes one or more of the following actions: determining one or more actions to resolve the problem in block 244D; selecting an action from one or more actions in block 246D; displaying an action in block 248D; including a history of sensor data 114 in sensor data indicating an approaching threshold that indicates a problem will occur soon in block 250D; determining a problem in response to the vehicle 120 being stationary and inactive in block 252D; and providing a notification of the problem to the device in block 254D. In one embodiment, the notification may include a time 126 when a problem will occur. In one embodiment, the device may include equipment associated with the vehicle 120. In another embodiment, the device may include occupant equipment 156. In yet another embodiment, the device may include equipment associated with one or more other vehicles 154.

[0081] Figure 2E A further transportation network diagram 260 is illustrated according to an example embodiment. (See also...) Figure 2E Network diagram 260 includes nodes 205 connected to other transport nodes 202' and update service nodes 203 via blockchain network 206. Transport nodes 202 and 202' may represent transport vehicles. Blockchain network 206 may have a ledger 208 for storing software update verification data and a verification source for future use (e.g., for auditing).

[0082] Although this example describes only one node 205 in detail, multiple such nodes can be connected to the blockchain 206. It should be understood that node 205 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of this application. Node 205 may have a computing device or server computer, and may include a processor 204, which may be a semiconductor-based microprocessor, central processing unit (CPU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), and / or another hardware device. Although a single processor 204 is depicted, it should be understood that node 205 may include multiple processors, multiple cores, etc., without departing from the scope of this application. Node 205 may be a vehicle, server, or any device including a processor and memory.

[0083] Processor 204 executes one or more of the following: in block 244E, it verifies the consensus received from the transportation vehicle; in block 246E, it executes a smart contract by the transportation vehicle 120 to record the verification and the time 126 when the problem will occur on the blockchain. In one embodiment, only one of the verification and the time 126 when the problem will occur is stored on the blockchain. In another embodiment, both the verification and the time 126 when the problem will occur are stored on the blockchain. In yet another embodiment, neither the verification nor the time 126 when the problem will occur is stored on the blockchain. Verification may include blockchain consensus between a peer group consisting of the transportation vehicle 120 and one or more other transportation vehicles.

[0084] The processor and / or computer-readable medium 242E may reside wholly or partially inside or outside the transport node. Steps or features stored in the computer-readable medium 242E may be executed wholly or partially by any of the processors and / or elements in any order. Furthermore, one or more steps or features may be added, omitted, combined, executed at a later time, etc.

[0085] Figure 2FFigure 265 illustrates the electrification of one or more components. In one embodiment, vehicle 266 can supply power stored in its battery to one or more components, including other vehicles(s) 268, charging stations(s) 270, and power grid(s) 272. Power grid(s) 272 are coupled to one or more charging stations 270, which may be coupled to one or more vehicles 268. This configuration enables the distribution of power / capacity received from vehicle 266. Vehicle 266 can also interact with other vehicles(s) 268, for example, via vehicle-to-vehicle (V2V) technology, cellular communication, WiFi, etc. Vehicle 266 can also interact wirelessly and / or wiredly with other vehicles 268, charging stations(s) 270, and / or power grid(s) 272. In one embodiment, vehicle 266 is routed securely and efficiently to power grid(s) 272, charging stations(s) 270, or other vehicles(s) 268 (or to itself). Using one or more embodiments of this solution, the transport vehicle 266 can supply energy to one or more of the elements depicted herein in various advantageous manners as described and / or illustrated herein. Furthermore, the safety and efficiency of the transport vehicle can be improved, and the environment can be positively impacted as described and / or illustrated herein.

[0086] The term "energy" can be used to refer to any form of energy received, stored, used, shared, and / or lost by one or more vehicles. During charging / use operations, energy can be referred to in conjunction with a voltage source and / or current supply of charge provided from the entity to one or more vehicles. Energy can also be in the form of fossil fuels (e.g., for use in hybrid vehicles) or by means of alternative power sources, including but not limited to lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, fusion-based energy, and energy generated in flight during energy sharing and / or use operations to increase or decrease the energy level of one or more vehicles at a given time.

[0087] In one embodiment, charging station 270 manages the amount of energy transferred from vehicle 266 such that sufficient charge remains in vehicle 266 to reach its destination. In one embodiment, a wireless connection is used to wirelessly guide the amount of energy transferred between vehicles 268, where both vehicles may be in motion. In one embodiment, vehicle 266 (which may be autonomous) is guided to provide a certain amount of energy to charging station 270 and return to its original location (e.g., its original location or a different destination). In one embodiment, a mobile energy storage unit (not shown) is used to collect remaining energy from at least one other vehicle 268 and transfer the stored remaining energy to charging station 270. In one embodiment, various factors determine the amount of energy to be transferred to charging station 270, such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle condition (weight, etc.), concurrent occupant schedules of the vehicle(s), and anticipated occupant schedules of the waiting vehicle(s). In one embodiment, one or more vehicles 268, one or more charging stations 270, and / or one or more power grids 272 may provide energy to vehicle 266.

[0088] In one embodiment, the solution described and depicted herein can be used to determine the load effect on the vehicle and / or system, provide energy to the vehicle and / or system based on future needs and / or priorities, and provide intelligence between the device and the vehicle containing the module, enabling the device's processor to wirelessly communicate with the vehicle regarding the amount of energy stored in the vehicle's battery. In one embodiment, the solution can also be used to provide charge from the vehicle to a location based on factors such as temperature at the location, energy cost, and power level at the location. In one embodiment, the solution can also be used to manage the amount of energy remaining in the vehicle after a portion of the charge has been transferred to a charging station. In one embodiment, the solution can also be used to instruct the vehicle to provide a certain amount of energy from the battery on the vehicle, wherein the amount of energy to be transferred is based on the distance from the vehicle to the module for receiving the energy.

[0089] In one embodiment, the solution may also utilize a mobile energy storage unit that travels along a determined path to a vehicle with excess energy and stores the energy in the power grid. In one embodiment, the solution may also utilize a priority mechanism to determine the vehicle's need to supply energy to the power grid and the priority of the vehicle's current needs, such as the priority of passengers, or incoming passengers, or current cargo, or incoming cargo. In one embodiment, the solution may also utilize a determination mechanism to determine when a vehicle is idle, it decides to move to a location to release excess energy into the energy grid and then return to its previous location. In one embodiment, the solution may also utilize a determination mechanism based on one or more conditions such as weather, traffic, road conditions, vehicle conditions, and passengers and / or cargo in another vehicle to determine the amount of energy required by the vehicle to supply the required energy to another vehicle via vehicle-to-vehicle energy transfer and to instruct the vehicle to route to another vehicle and provide energy. In one embodiment, the solution may also utilize a transfer mechanism to transfer energy from a moving vehicle to another moving vehicle. In one embodiment, the solution may also utilize a recovery mechanism based on the energy consumed by the vehicle to reach the meeting point with another vehicle, the energy consumed in providing the service, and the estimated energy consumed in returning to the original location. In one embodiment, the solution can also provide the remaining distance required to reach the charging station, and the charging station determines the amount of energy to be recovered from the vehicle, wherein the remaining charge is based on the remaining distance. In one embodiment, the solution can also manage vehicles being charged simultaneously from more than one point, such as a charging station connected via a wired connection and another vehicle connected via a wireless connection. In one embodiment, the solution can also apply a priority system for allocating energy to vehicles, wherein priority is given to vehicles that will provide a portion of their stored charge to another entity such as the power grid, a residence, etc. Additionally, it can utilize, for example, relative to... Figure 2F This solution is described and depicted.

[0090] Figure 2GThis diagram illustrates the interconnections between the different components 275. This solution can be stored, in whole or in part, on and / or executed by one or more computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277' associated with various entities, all of which are communicatively coupled and communicate with network 286. Database 287 is communicatively coupled to the network and enables data storage and retrieval. In one embodiment, the database is an immutable ledger. One or more of the various entities may be vehicles 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructures 282, one or more residences 283, power grids / charging stations 284, microphones 285, and / or another vehicle 277. Other entities and / or devices, such as one or more private users using smartphones 278, laptops 280, and / or wearable devices, may also interoperate with this solution. Smartphone 278, laptop computer 280, microphone 285, and other devices may be connected to one or more of the connected computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277'. One or more public buildings 281 may include various institutions. One or more public buildings 281 may utilize computing device 281'. One or more service providers 279 may include dealerships, towing services, collision repair centers, or other repair shops. One or more service providers 279 may utilize computing device 279'. These various computer devices may be directly and / or communicatively coupled to each other, such as via wired networks, wireless networks, blockchain networks, etc. In one embodiment, microphone 285 may be used as a virtual assistant. In one embodiment, one or more traffic infrastructures 282 may include one or more traffic signals, one or more sensors including one or more cameras, vehicle speed sensors or traffic sensors, and / or other traffic infrastructure. One or more traffic infrastructures 282 may utilize computing device 282'.

[0091] In one embodiment, vehicle 277 / 276 is capable of transporting people, objects, permanently or temporarily fixed installations, etc. In one embodiment, vehicle 277 can communicate with vehicle 276 via V2V communication through a computer associated with each vehicle 276' and 277', and can be referred to as a vehicle, car, vehicle, automobile, etc. Vehicle 276 / 277 can be a self-propelled wheeled vehicle such as a car, SUV, truck, bus, van, or other electric motor or battery-powered or fuel cell-powered vehicle. For example, vehicle 276 / 277 can be an electric vehicle, hybrid vehicle, hydrogen fuel cell vehicle, plug-in hybrid vehicle, or any other type of vehicle having a fuel cell stack, motor, and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, or ships, and any other form of vehicle capable of transporting. Vehicle 276 / 277 can be semi-autonomous or autonomous. For example, vehicle 276 / 277 can self-operate and navigate without human input. Autonomous vehicles can have and use one or more sensors and / or navigation units for autonomous driving.

[0092] In one embodiment, the solution described and depicted herein can be used to determine access to a vehicle via blockchain consensus. In one embodiment, the solution can be used to perform profile verification before enabling occupants to use the vehicle. In one embodiment, the solution can be used to instruct (visually, but in another embodiment, verbally, etc.) the actions that the user needs to perform (which may be pre-recorded) on or from the vehicle and verify that these actions are correct. In one embodiment, the solution can also be used to provide the ability for the vehicle to determine how to fork data based on the risk level associated with the data and the driving environment, and to allocate a portion of the forked data (with a lower risk level during safe driving conditions) to the occupants and later allocate the remaining portion of the forked data (with a higher risk level) to the occupants after they have left the vehicle. In one embodiment, the solution can also be used to handle the transfer of vehicles across borders (such as countries / states) using blockchain and / or smart contracts, and to apply the rules of the new area to the vehicle.

[0093] In one embodiment, the solution can also be used to enable a vehicle to continue operating outside a boundary when the vehicle reaches a consensus based on its operation and the characteristics of its occupants. In one embodiment, the solution can also be used to analyze the vehicle's available data upload / download speed, file size, and the vehicle's current speed / direction to determine the distance required to complete the data upload / download and to allocate safe zone boundaries for the data upload / download to be performed. In one embodiment, the solution can also be used to perform normally dangerous maneuvers safely, such as when the system determines it is about to leave and when the vehicle does not appear ready to leave (e.g., in the wrong lane or traveling at a speed unfavorable to an imminent departure), and to instruct the main vehicle and other nearby vehicles to allow the main vehicle to leave safely. In one embodiment, the solution can also be used to verify the diagnostics of one or more vehicles while one or more vehicles and other vehicles are both in motion.

[0094] In one embodiment, the solution can also detect lane usage at a specific location and time of day to inform vehicle occupants or guide vehicles to recommend or discourage lane changes. In one embodiment, the solution can also eliminate the need for sending information via mail and for drivers / occupants to respond by using mail or making payments in person. In one embodiment, the solution can also provide services to vehicle occupants, wherein the services provided are subscription-based, and wherein licenses are obtained from other vehicles connected to the occupant's profile. In one embodiment, the solution can also record changes in the condition of the leased object. In one embodiment, the solution can also seek blockchain consensus from other vehicles near the damaged vehicle. In one embodiment, the solution can also receive media potentially related to the accident from a server, such as an insurance entity server, or from the vehicle's computer. The server accesses one or more media files to access the damage to the vehicle and stores the damage assessment on the blockchain. In one embodiment, the solution can also achieve consensus to determine the severity of an event from multiple devices at different times prior to the event related to the vehicle.

[0095] In one embodiment, the solution can also address the problem of a lack of video evidence related to accidents involving vehicles. The current solution details querying media related to the accident from other vehicles that may have been near it. In one embodiment, the solution can also utilize the vehicle and other devices (e.g., pedestrians' mobile phones, streetlight cameras, etc.) to record specific parts of the damaged vehicle.

[0096] In one embodiment, the solution can also be used to warn occupants when the vehicle is navigating toward a hazardous area and / or event, enabling the vehicle to notify occupants or a central controller of potential hazardous areas on or near the current transport route. In one embodiment, the solution can also be used to detect when the vehicle is traveling at a high speed, using at least one other vehicle to slow the vehicle down in a manner that contributes to minimal traffic disruption. In one embodiment, the solution can also be used to identify hazardous driving situations in which media is captured by vehicles involved in the hazardous driving situation. A geofence is established based on the distance of the hazardous driving situation, and additional media is captured by at least one other vehicle within the established geofence. In one embodiment, the solution can also be used to send a notification to one or more occupants of the vehicle that the vehicle is approaching a traffic control sign on the road, and then, if the vehicle crosses the sign, receive instructions of bad driving from other nearby vehicles. In one embodiment, the solution can also be used to partially inoperable the vehicle by (in some embodiments) limiting speed, limiting the ability to approach another vehicle, limiting speed to a maximum value, and allowing only a given number of miles per time period.

[0097] In one embodiment, the solution can also overcome the need to rely on software updates to correct problems with a vehicle when it is not being operated correctly. By observing other vehicles on the route, the server receives data from multiple other potential vehicles from which unsafe or incorrect operation of a vehicle is observed. Through analysis, these observations may lead to notifications to the vehicle when the data indicates unsafe or incorrect operation. In one embodiment, the solution can also provide notification between the vehicle and potential hazardous situations involving persons outside the vehicle. In one embodiment, the solution can also send data to the server via a device associated with or near an accident involving the vehicle. Based on the severity of the accident or near-accident, the server notifies the sender of the data. In one embodiment, the solution can also provide recommendations for operating the vehicle to the driver or passengers based on data analysis. In one embodiment, the solution can also establish geofencing associated with physical structures and determine liability for payment to the vehicle. In one embodiment, the solution can also coordinate the ability to drop off passengers at a location using both the current state at the location and the suggested future state of navigation destinations using other vehicles. In one embodiment, the solution can also coordinate the ability to automatically schedule passenger drop-offs at locations such as transportation rental entities.

[0098] In one embodiment, the solution can also be used to move a vehicle to another location based on a user's event. More specifically, the system tracks the user's device and, at the end of the original or modified event, modifies the vehicle to move closer to the user. In one embodiment, the solution can also be used to verify the availability of locations within an area by using existing vehicles within that area. The approximate time it takes for a location to become available is also determined based on verification from existing vehicles. In one embodiment, the solution can also be used to move the vehicle to a closer parking space when a parking space becomes available, with less time elapsed since the initial parking than the average time of the event. Furthermore, the vehicle is moved to the final parking space when the event is complete or based on the location of the device associated with at least one occupant of the vehicle. In one embodiment, the solution can also be used to plan parking ahead of an approaching crowd. The system interacts with the vehicle to offer services at a price below full fare and / or guides the vehicle to alternative parking locations based on vehicle priority, thereby optimizing parking scenarios before arrival.

[0099] In one embodiment, the solution can also be used to sell partial ownership of a transportation vehicle or to determine pricing and availability in ride-sharing applications. In one embodiment, the solution can also be used to provide accurate and timely reporting on dealer sales activities far beyond current availability. In one embodiment, the solution can also be used to enable dealers to request assets via blockchain. Consensus is reached before any asset movement using blockchain. Furthermore, the process is automated, and payments can be initiated via blockchain. In one embodiment, the solution can also be used to arrange agreements with multiple entities (such as service centers), where consensus is reached and actions (such as diagnostics) are performed. In one embodiment, the solution can also be used to associate digital keys with multiple users. The first user can be the operator of the transportation vehicle, and the second user is the responsible party for the transportation vehicle. These keys are authorized by a server, where proximity of the keys is verified against the location of the service provider. In one embodiment, the solution can also be used to determine the services required at the destination of the transportation vehicle. One or more service locations capable of providing the required services are located within an area along the route to the destination and have availability to perform the services. The navigation of the transportation vehicle is updated using the determined service locations. A smart contract containing service compensation values ​​is identified, and blockchain transactions are stored in a distributed ledger of transactions.

[0100] In one embodiment, the solution can also be used to match service provider vehicles with passenger profiles to identify services and goods that passengers in the vehicle may be interested in. These services and goods are determined by passenger history and / or preferences. The vehicle then receives a quote from the service provider vehicle, and in another embodiment, encounters the vehicle to provide the service / goods. In one embodiment, the solution can also be used to detect vehicles within a range and send service quotes (such as maintenance quotes, product quotes, etc.) to the vehicles. An agreement is reached between the system and the vehicle, and the system selects a service provider to provide the agreement. In one embodiment, the solution can also be used to assign one or more vehicles as road managers, where road managers help control traffic. Road managers can generate road indicators (such as lights, displays, sounds) to facilitate traffic flow. In one embodiment, the solution can also be used to warn vehicle drivers via devices, where the devices may be traffic lights or located near intersections. The warning is sent upon the occurrence of an event, such as when the light turns green and the vehicle at the front of the vehicle list has not yet moved.

[0101] Figure 2H This is another block diagram illustrating the interconnection between different components in an example 290. A vehicle 276 is presented, and vehicle 276 includes ECUs 295, 296 and a host unit (also referred to as an infotainment system) 297. An Electronic Control Unit (ECU) is a built-in system in automotive electronics that controls one or more electronic systems or subsystems within a vehicle. ECUs may include, but are not limited to, the management of the vehicle's engine, braking system, transmission system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECU is connected to the vehicle's Controller Area Network (CAN) bus 294. The ECU can also communicate with a vehicle computer 298 via the CAN bus 294. The vehicle's processor / sensor (such as the vehicle computer) 298 can communicate with external components such as a server 293 via a network 292 (such as the Internet). Each ECU 295, 296, and host unit 297 may contain its own security policy. The security policy defines the permissible processes that can be executed in an appropriate context. In one embodiment, the security policy may be partially or wholly set in the vehicle computer 298.

[0102] ECUs 295, 296, and host unit 297 may each include a custom safety function element 299 that defines authorized processes and the context in which these processes are permitted to operate. Context-based authorization, which determines the validity of a process when it can be executed, enables the ECU to maintain safe operation and prevents unauthorized access from components such as the vehicle's controller area network (CAN bus). When the ECU encounters an unauthorized process, it can prevent the process from running. The vehicle ECU can use various contexts to determine whether a process is operating within its permitted limits, such as proximity contexts (e.g., nearby objects, distance to approaching objects, speed, and trajectory relative to other moving objects), operational contexts (e.g., indications of whether the vehicle is moving or parked, the vehicle's current speed, and transmission status), user-related contexts (e.g., devices connected to the vehicle via wireless protocols, infotainment use, cruise control, parking assistance, and driver assistance), location-based contexts, and / or other contexts.

[0103] In one embodiment, the solution described and depicted herein can also be used to partially inoperable a vehicle by (in some embodiments) limiting speed, restricting the ability to approach another vehicle, limiting speed to a maximum value, and allowing only a given number of miles per time period. In one embodiment, the solution can also be used to facilitate the exchange of vehicle ownership using blockchain, where data is sent from a device associated with or near an accident involving the vehicle to a server. Based on the severity of the accident or near-accident, the server notifies the sender of the data. In one embodiment, the solution can also be used to help a vehicle avoid accidents, such as when it is involved in one, by querying a server of other vehicles near the accident. The server attempts to obtain data from other vehicles, enabling it to understand the nature of the accident from multiple vantage points. In one embodiment, the solution can also be used to determine that the sound emanating from the vehicle is atypical and send data related to the sound and possible source locations to a server, where the server can determine possible causes and avoid potentially hazardous situations. In one embodiment, when a vehicle is involved in an accident, the solution can also be used to establish a location boundary via the system. This boundary is based on the decibel level associated with the accident. Multimedia content of the devices within the boundary is obtained to aid in further understanding the accident scenario. In one embodiment, the solution can also associate the vehicle with the accident and then capture media obtained by a device near the accident location. The captured media is saved as a media segment. The media segment is sent to another computing device to construct a sound profile of the accident. This sound profile will help to understand more details surrounding the accident.

[0104] In one embodiment, the solution can also utilize sensors to record audio, video, motion, etc., and record the area where a potential event has occurred, such as if the vehicle has come into contact with or may come into contact with another vehicle (while moving or parked). The system captures data from the sensors that may reside on one or more fixed or moving objects on the vehicle. In one embodiment, the solution can also determine if the vehicle has been damaged by using the following steps: identifying new conditions of the vehicle during a vehicle incident using sensor data, and comparing that condition with a vehicle condition profile, thereby enabling the safe and reliable capture of critical data from the vehicle that is about to be involved in a harmful incident.

[0105] In one embodiment, the solution can also be used to warn occupants of a vehicle when one or more sensors have determined that the vehicle is approaching or traveling in an incorrect manner along a one-way road. The vehicle has sensors / cameras / maps that interact with the system of the current solution. The system learns the geographic location of the one-way road. For example, the system can use an audio message to inform occupants that a one-way road is approaching. In one embodiment, the solution can also be used to reward vehicles, enabling autonomous vehicle owners to monetize the data collected and stored by their vehicle's sensors. This incentivizes vehicle owners to share their data and provide additional data to entities that could improve future vehicle performance, provide services to vehicle owners, etc.

[0106] In one embodiment, the solution can also be used to add or remove vehicle characteristics based on the vehicle's actions over a period of time. In another embodiment, the solution can also be used to assign partial ownership to a vehicle. Sensor data associated with one or more vehicles and devices proximate to the vehicles is used to determine the condition of the vehicles. Based on this condition, partial ownership of the vehicles is determined, and new responsibilities are assigned to the vehicles. In yet another embodiment, the solution can also be used to provide data to a replacement / upgrade component, wherein the data attempts to overturn the authorized functions of the replacement / upgrade component, and in response to not overturning the authorized functions, the component is permitted to use the authorized functions of the replacement / upgrade component.

[0107] In one embodiment, the solution can also provide individuals with the ability to ensure that a passenger is in the vehicle and that the passenger is at a specific destination. Additionally, the system ensures that the driver (in the case of a non-autonomous vehicle) and / or other passengers are authorized to interact with the passenger. Pick-up, drop-off, and location information are also noted. All of the above is stored immutably on a blockchain. In one embodiment, the solution can also utilize the characteristics of the driver's actions when they are not driving in a normal manner (such as the way the driver has previously driven in specific conditions) during periods such as daytime, nighttime, rain, or snow, by analyzing driving style and other elements. Additionally, vehicle attributes are considered. These attributes consist of weather, whether headlights are on, whether navigation is being used, whether a HUD is being used, the volume of media being played, etc. In one embodiment, the solution can also utilize the ability to notify the passenger of a dangerous situation when items within the vehicle indicate that the passenger may be unaware of a hazardous situation.

[0108] In one embodiment, the solution can also utilize a calibration device mounted on a dedicated rig fixed to the vehicle, where various sensors on the vehicle can automatically self-adjust based on a comparison between what the calibration device should detect and what it actually detects. In another embodiment, the solution can use blockchain to request consensus from multiple service centers when a vehicle requiring service sends fault information enabling remote diagnostics, where consensus is needed from other service centers regarding the severity threshold of the data. Once consensus is received, the service centers can send the fault-safe level to the blockchain for storage. In yet another embodiment, the solution can also determine the discrepancy between sensor data external to the vehicle and sensor data from the vehicle itself. The vehicle requests software from the server to correct the problem. In yet another embodiment, the solution can also enable messaging between nearby or regional vehicles when an event (e.g., a collision) occurs.

[0109] Reference Figure 2I According to some embodiments, an operating environment 290A for a connected vehicle is illustrated. As depicted, the vehicle 276 includes a Controller Area Network (CAN) bus 291A connecting components 292A to 299A of the vehicle. Other components may be connected to the CAN bus and are not depicted herein. The depicted components connected to the CAN bus include a sensor group 292A, an electronic control unit 293A, an autonomous feature or advanced driver assistance system (ADAS) 294A, and a navigation system 295A. In some embodiments, the vehicle 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

[0110] Processor 296A includes an arithmetic logic unit, a microprocessor, a general-purpose controller, and / or a similar processor array to perform calculations and provide electronic display signals to display unit 299A. Processor 296A processes data signals and may include various computing architectures, including Complex Instruction Set Computer (CISC) architecture, Reduced Instruction Set Computer (RISC) architecture, or architectures implementing instruction set combinations. Vehicle 276 may include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations that are communicatively coupled to each other (not depicted) may be used with this solution.

[0111] Memory 297A is a non-transient memory that stores instructions or data that can be accessed and executed by processor 296A. Instructions and / or data may include code for performing the techniques described herein. Memory 297A may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or certain other storage devices. In some embodiments, memory 297A may also include non-volatile memory or similar persistent storage devices and media that may include hard disk drives, floppy disk drives, CD-ROM devices, DVD-ROM devices, DVD-RAM devices, DVD-RW devices, flash memory devices, or certain other high-capacity storage devices based on permanent underlying storage information. A portion of memory 297A may be reserved for use as a buffer or virtual random access memory (virtual RAM). Without departing from the present solution, vehicle 276 may include one or more memories 297A.

[0112] The memory 297A of the vehicle 276 may store one or more of the following types of data: navigation route data 295A and autonomous characteristic data 294A. In some embodiments, the memory 297A stores data necessary for the navigation application 295A to provide functionality.

[0113] Navigation system 295A can describe at least one navigation route including a start point and an end point. In some embodiments, navigation system 295A of vehicle 276 receives a request for a navigation route from a user, wherein the request includes a start point and an end point. Navigation system 295A can query navigation route data corresponding to the navigation route including the start point and end point from real-time data server 293 (via network 292), such as a server providing driving directions. Real-time data server 293 sends navigation route data to vehicle 276 via wireless network 292, and communication system 298A stores navigation data 295A in memory 297A of vehicle 276.

[0114] ECU 293A controls the operation of many systems of the vehicle 276, including ADAS system 294A. ECU 293A can, in response to instructions received from navigation system 295A, disable any unsafe and / or unselected autonomous features for the duration of a journey controlled by ADAS system 294A. In this way, navigation system 295A can control whether ADAS system 294A is activated or enabled, allowing it to be activated for a given navigation route.

[0115] Sensor group 292A may include any sensor in vehicle 276 that generates sensor data. For example, sensor group 292A may include short-range and long-range sensors. In some embodiments, sensor group 292A of vehicle 276 may include one or more of the following vehicle sensors: camera, LIDAR sensor, ultrasonic sensor, automotive engine sensor, radar sensor, laser altimeter, manifold absolute pressure sensor, infrared detector, motion detector, thermostat, sound detector, carbon monoxide sensor, carbon dioxide sensor, oxygen sensor, mass airflow sensor, engine coolant temperature sensor, throttle position sensor, crankshaft position sensor, valve timer, air-fuel ratio meter, blind spot meter, curb contact sensor, defect detector, Hall effect sensor, parking sensor, radar gun, speedometer, speed sensor, tire pressure monitoring sensor, torque sensor, transmission fluid temperature sensor, turbo speed sensor (TSS), variable reluctance sensor, vehicle speed sensor (VSS), water sensor, wheel speed sensor, GPS sensor, mapping function, and any other type of automotive sensor. Navigation system 295A may store sensor data in memory 297A.

[0116] Communication unit 298A transmits data to network 292 or another communication channel and receives data from the network or other communication channel. In some embodiments, communication unit 298A may include a DSRC transceiver, a DSRC receiver, and other hardware or software necessary to make vehicle 276 a DSRC-equipped device.

[0117] Vehicle 276 can interact with other vehicles 277 via V2V technology. In one embodiment, V2V communication includes sensing radar information corresponding to the relative distance to an external object, receiving GPS information of the vehicle, setting a region based on the sensed radar information as the area where the other vehicle 277 is located, calculating the probability that the GPS information of the target vehicle will be located in the set region, and identifying the vehicle and / or object corresponding to the radar information and GPS information of the target vehicle based on the calculated probability.

[0118] In one embodiment, when a vehicle is determined to enter an area without network access, the solution described and depicted herein can be used to manage emergencies and vehicle characteristics. In one embodiment, the solution can also be used to manage and provide characteristics (such as audio, video, navigation, etc.) within a vehicle without network connectivity. In one embodiment, the solution can also be used to determine when the profile of a person near the vehicle matches the profile attributes of at least one occupant in the vehicle. A notification to establish communication is sent from the vehicle.

[0119] In one embodiment, the solution can also be used to analyze the availability of occupants in the corresponding vehicle for voice communication based on the amount of time remaining in the vehicle and the context of the communication to be performed. In one embodiment, the solution can also be used to determine two threat levels of road congestion and receive an alert indicating that the obstacle has not risen above a threshold and that the vehicle is moving along the road. In one embodiment, the solution can also be used to delete sensitive data from the vehicle when it is damaged to the point that it is unusable.

[0120] In one embodiment, the solution can also be used to verify that customer data to be removed has been genuinely removed from all required locations within the enterprise demonstrating GDPR compliance. In one embodiment, the solution can also be used to provide consideration for enhancing the autonomy of lower-level autonomous vehicles by exchanging data related to safety, important notifications, etc., from one vehicle to another. In one embodiment, the solution can also be used to provide the vehicle with the ability to receive data based on a first biometric associated with an occupant. The vehicle then decrypts the encrypted data based on verification of a second biometric, where the second biometric is a continuation of the first biometric. When only the occupant is capable of receiving unencrypted data, the vehicle provides the unencrypted data to the occupant, deleting sensitive portions while providing the sensitive portions of the unencrypted data, and deleting non-sensitive portions after the time period associated with the biometric has elapsed. In one embodiment, the solution can also be used to provide the vehicle with the ability to verify an individual based on the weight and grip pressure applied to the vehicle's steering wheel. In one embodiment, the solution can also be used to provide a vehicle with features that exist but are not currently enabled to present characteristics reflecting occupant characteristics to the vehicle's occupants.

[0121] In one embodiment, the solution can also enable modification of the vehicle, particularly its interior and exterior, to reflect and assist at least one occupant in one embodiment. In another embodiment, the re-creation of an occupant's work and / or home environment is disclosed. If a user is determined to be in "work mode" or "home mode," the system can attempt to "recreate" the user's work / home environment while the user is in the vehicle. All data related to the vehicle's interior and exterior, and the various occupants utilizing the vehicle, is stored on a blockchain and executed via smart contracts. In one embodiment, the solution can also detect occupant postures to assist communication with nearby vehicles, which can then be manipulated accordingly. In one embodiment, the solution can also provide the vehicle with the ability to detect expected postures using a posture definition data store. In one embodiment, the solution can also provide the vehicle with the ability to take various actions based on the user's gait and posture. In one embodiment, the solution can also ensure that the driver of a vehicle currently performing various operations (e.g., talking while driving with navigation on) does not exceed the number of unsafe actions before being permitted to perform postures.

[0122] In one embodiment, the solution can also be used to assign a state to each occupant in the vehicle and verify the occupant's posture based on the occupant's state. In another embodiment, the solution can also be used to collect details of collision-related sounds (location, direction, ascent or descent, originating device, device-related data such as type, manufacturer, owner, and the number and frequency of simultaneous sounds) and provide the system with analysis of data that helps determine details about the collision. In yet another embodiment, the solution can also be used to provide a determination that the vehicle's operation is unsafe. The vehicle includes multiple components that interoperate to control the vehicle, and each component is associated with a separate component key. An encryption key is sent to the vehicle to reduce its functionality. In response to receiving the encryption key, the vehicle disables one or more of the component keys. Disabling one or more component keys results in one or more restrictions on the vehicle not moving above a given speed, restrictions on the vehicle not approaching another vehicle at a certain distance, and restrictions on the vehicle not moving above a threshold distance.

[0123] In one embodiment, the solution can also utilize blockchain to perform authentication and coordination by providing instructions from one particular vehicle (about to vacate a space) to another particular vehicle (attempting to occupy a space). In one embodiment, the solution can also utilize partial ownership of the vehicle. In cases where multiple people own a single vehicle, the system updates partial ownership using the vehicle's usage, which can change over time. Other embodiments will be included in the application, including those based not on vehicle usage but on vehicle availability, and on minimum ownership of the vehicle determined by the vehicle's driver and others.

[0124] In one embodiment, the solution can also be used to authorize a user's subscription to be shared with a closed group of people, such as family members or friends, while on the vehicle. For example, a user might want to share membership, and if so, the relevant transactions are stored in a blockchain or traditional database. When subscription materials are requested by a user who is not the primary subscriber, a blockchain node (i.e., the vehicle) can verify that the person requesting the service is an authorized person with whom the subscriber has shared a profile. In one embodiment, the solution can also be used to enable people to use one or more supplemental transportation vehicles to reach their desired destination. Functional relationship values ​​(e.g., values ​​indicating various parameters and their importance in determining which type of alternative transportation vehicle to use) are used to determine the supplemental transportation vehicle. In one embodiment, the solution can also be used to enable occupants in an accident to obtain alternative transportation to continue to their initial destination.

[0125] In one embodiment, the solution can also be used to propagate software / firmware updates to a first subset of the vehicles. This first set of vehicles tests the update, and when the test is successful, the update is propagated to other sets of vehicles. In one embodiment, the solution can also be used to propagate software / firmware updates from the main vehicle to the vehicles, where the update is propagated through a network of vehicles in the first subset, then larger subsets, etc. A portion of the update may be sent first, followed by the remainder from that vehicle or another vehicle. In one embodiment, the solution can also be used to provide updates to the vehicle's computer to the vehicles and the devices of the vehicle's operators / occupants. This update may be authorized by all drivers and / or all occupants. The software update is provided to the vehicles and(one or more) devices. Users do not need to do anything; simply approaching the vehicle, the functionality appears automatically. A notification indicating the completion of the software update is sent to(one or more) devices. In one embodiment, the solution can also be used to verify that the OTA software update was performed by a qualified technician and that one or more vehicle components generate a status related to: the originator of the verification code, the process for wirelessly receiving the software update, the information contained in the software update, and the verification result.

[0126] In one embodiment, the solution may also provide the ability for a second component to parse software updates located in a first component. Then, a first portion of a critical update and a second portion of a non-critical update are verified. The verified first portion is assigned to a process within the transportation vehicle, run with a process for a period of time, and, in response to a positive result based on that period, run with other processes after that period. In one embodiment, the solution may also provide service options to passengers, where services are based on passenger profiles of the transportation vehicle and shared profiles shared with the passenger profiles. In one embodiment, the solution may also store user profile data in a blockchain and intelligently present offers and recommendations to users based on automatically collected user purchase history and preferences obtained from user profiles on the blockchain.

[0127] To ensure greater security for transport vehicles, it is essential to protect them from unauthorized physical access as well as unauthorized remote access. For example The impact of network threats. To prevent unauthorized physical access, in one embodiment, the transport vehicle is equipped with a secure access system such as keyless entry. Meanwhile, in another embodiment, security protocols are added to the transport vehicle's computers and computer networks to facilitate secure remote communication to and from the transport vehicle.

[0128] Electronic control units (ECUs) are nodes within a vehicle that control everything from activating windshield wipers to systems like anti-lock braking systems (ABS). ECUs are often interconnected via a central network within the vehicle, which may be referred to as a controller area network (CAN). State-of-the-art features such as autonomous driving heavily rely on the implementation of new and complex ECUs, such as advanced driver assistance systems (ADAS) and sensors. While these new technologies have helped improve vehicle safety and the driving experience, they have also increased the number of external communication units within the vehicle, making them more vulnerable to attack. Below are some examples of protecting vehicles from physical and remote intrusion.

[0129] Figure 2J The illustration shows a keyless entry system 290B, according to an example embodiment, for preventing unauthorized physical access to a means of transport 291B. (Refer to...) Figure 2JIn one embodiment, the key card 292B sends commands to the vehicle 291B using radio frequency signals. In this example, the key card 292B includes a transmitter 2921B with an antenna capable of transmitting short-range wireless radio signals. The vehicle 291B includes a receiver 2911B with an antenna capable of receiving short-range wireless signals transmitted from the transmitter 2921B. The key card 292B and the vehicle 291B also include CPUs 2922B and 2913B, respectively, for controlling the corresponding devices. Here, the memory (or CPU-accessible memory) of the CPUs 2922B and 2913B is also included. In one embodiment, each of the key card 292B and the vehicle 291B includes power supplies 2924B and 2915B for powering the corresponding devices.

[0130] When a user presses button 293B on key card 292B (or otherwise actuates the key card), CPU 2922B within key card 292B is activated and sends a data stream output via antenna to transmitter 2921B. This data stream can be a long signal of 64 to 128 bits, including one or more of a preamble, command code, and rolling code. Signals can be transmitted at rates between 2 kHz and 20 kHz, but embodiments are not limited thereto. In response, receiver 2911B of vehicle 291B captures the signal from transmitter 2921B, demodulates the signal, and sends the data stream to CPU 2913B. CPU 2913B decodes the signal and sends a command to command module 2912B. For example (Locking and unlocking doors, etc.).

[0131] If the key card 292B and the vehicle 291B use a fixed code between them, a replay attack can be performed. In this case, if an attacker is able to capture / sniff the fixed code during short-range communication, the attacker can replay the code to gain access to the vehicle 291B. To improve security, the key card and the vehicle 291B can use a rolling code that changes after each use. Here, the key card 292B and the vehicle 291B are connected to the initial seed 2923B ( For example (Random numbers, pseudo-random numbers, etc.) are synchronized. This is called pairing. The key card 292B and the vehicle 291B also include a shared algorithm for modifying the initial seed 2914B each time a button 293B is pressed. The next button press will take the result of the previous press as input and transform it into the next number in the sequence. In some cases, the vehicle 291B can store multiple subsequent codes (…). For example (255 subsequent lines of code) in case the transport vehicle 291B cannot detect the buttons on the key card 292B. Therefore, multiple button presses on the key card 292B that the transport vehicle 291B cannot hear do not prevent the transport vehicle from becoming out of sync.

[0132] Besides the rolling code, the key card 292B and the transport vehicle 291B can employ other methods to make attacks more difficult. For example, different frequencies can be used to send the rolling code. As another example, a secure session can be established using bidirectional communication between the transmitter 2921B and the receiver 2911B. As yet another example, the code may have a limited expiration or timeout. Additionally, exploits such as those relative to... can be used in this network and other networks and / or systems (including those described and depicted herein). Figure 2J This solution is described and depicted.

[0133] Figure 2K The illustration shows a Controller Area Network (CAN) 290C within a vehicle according to an example embodiment. (Refer to...) Figure 2K The CAN 290C includes a CAN bus 297C with high-side and low-side terminals, and multiple electronic control units (ECUs) 291C, 292C, 293C, etc., connected to the CAN bus 297C via wired connections. The CAN bus 297C is designed to enable microcontrollers and devices to communicate with each other in masterless applications. The CAN bus 297C implements a message-based protocol (…). Right now According to the ISO 11898 standard, this protocol enables ECUs 291C-293C to send commands to each other at the root level. Meanwhile, ECUs 291C-293C represent controllers used to control electrical systems or subsystems within a vehicle. Examples of electrical systems include power steering, anti-lock braking, air conditioning, tire pressure monitoring, cruise control, and many other features.

[0134] In this example, ECU 291C includes a transceiver 2911C and a microcontroller 2912C. The transceiver can be used to send messages to and receive messages from the CAN bus 297C. For example, transceiver 2911C can convert data from the microcontroller 2912C into the format of the CAN bus 297C, and can also convert data from the CAN bus 297C into the format of the microcontroller 2912C. Meanwhile, in one embodiment, the microcontroller 2912C uses ECU software installed therein to interpret messages and also determines what messages to send.

[0135] To protect the CAN 290C from network threats, various security protocols can be implemented. For example, subnets can be used ( For example Sub-networks (A and B, etc.) divide the CAN 290C into smaller sub-CANs and restrict an attacker's ability to remotely access the vehicle. Figure 2KIn the example, ECUs 291C and 292C can be part of the same subnet, while ECU 293C is part of a separate subnet. Furthermore, a firewall 294C (or gateway, etc.) can be added to prevent messages from crossing the subnets and traversing the CAN bus 297C. If an attacker gains access to one subnet, they will not gain access to the entire network. To further secure the subnets, in one embodiment, the most critical ECUs are not placed on the same subnet.

[0136] Despite Figure 2K Not shown, but examples of other security controls within the CAN may include an intrusion detection system (IDS), which can be added to each subnet and read all transmitted data to detect malicious messages. If a malicious message is detected, the IDS can notify the vehicle occupant. Other possible security protocols include encryption / security keys that can be used to hide messages. As another example, in one embodiment, an authentication protocol is implemented that enables messages to authenticate themselves.

[0137] In addition to protecting the internal network of a transportation vehicle, it can also be protected when communicating with external networks such as the Internet. One benefit of connecting a transportation vehicle to a data source such as the Internet is that information from the vehicle can be transmitted over the network to remote locations for analysis. Examples of transportation vehicle information include GPS, on-board diagnostics, tire pressure, etc. These communication systems are often referred to as telematics because they involve a combination of telecommunications and computer science. Furthermore, technologies such as those described and depicted herein can be utilized in this network and other networks and / or systems (including those described and depicted herein). Figure 2K This solution is described and depicted.

[0138] Figure 2L The illustration depicts a secure end-to-end vehicle communication channel according to an example embodiment. (Refer to...) Figure 2L The telematics network 290D includes a vehicle 291D and a host server 295D located at a remote location (e.g., a web server, cloud platform, database, etc.) and connected to the vehicle 291D via a network such as the Internet. In this example, a device 296D associated with the host server 295D can be installed within the network inside the vehicle 291D. Furthermore, although not shown, the device 296D can connect to other components of the vehicle 291D such as a CAN bus, an onboard diagnostic (ODBII) port, a GPS system, a SIM card, a modem, etc. The device 296D can collect data from any of these systems and transmit the data to the server 295D via the network.

[0139] Secure data management begins with the vehicle 291D. In some embodiments, the device 296D may collect information before, during, and after the trip. This data may include GPS data, driving data, passenger information, diagnostic data, fuel data, speed data, etc. However, the device 296D may only transmit the collected information back to the host server 295D in response to vehicle ignition and trip completion. Furthermore, communication may be initiated solely by the device 296D and not by the host server 295D. Thus, in one embodiment, the device 296D will not accept communication initiated by external sources.

[0140] To perform communication, device 296D can establish a secure private network between device 296D and host server 295D. Here, device 296D may include a tamper-proof SIM card, which provides secure access to carrier network 294D via radio tower 292D. When ready to send data to host server 295D, device 296D can establish a one-way secure connection with host server 295D. Carrier network 294D can communicate with host server 295D using one or more security protocols. As a non-limiting example, carrier network 294D can communicate with host server 295D via a VPN tunnel that allows access to host server 295D through firewall 293D. As another example, carrier network 294D can use data encryption when sending data to host server 295D. For example (e.g., AES encryption). In some cases, systems can use multiple security measures, such as VPNs and encryption, to further protect data.

[0141] In addition to communicating with external servers, vehicles can also communicate with each other. Specifically, vehicle-to-vehicle (V2V) communication systems enable vehicles to communicate with each other via wireless networks and with roadside infrastructure. For example Communication can be achieved through various means, including traffic lights, signs, cameras, parking meters, etc. Wireless networks can include one or more of Wi-Fi networks, cellular networks, and Dedicated Short Range Communication (DSRC) networks. Vehicles can use V2V communication to provide other vehicles with information about their speed, acceleration, braking, and direction (to name just a few). Therefore, vehicles can gain insight into conditions ahead before they become visible, significantly reducing the risk of collisions. Additionally, communication can be utilized in this network and other networks and / or systems (including those described and depicted herein) such as those related to... Figure 2L This solution is described and depicted.

[0142] Figure 2M The illustration shows an example 290E of transport vehicles 293E and 292E performing secure V2V communication using a security certificate according to an example embodiment. (Refer to...) Figure 2M Vehicles 293E and 292E can communicate with each other via V2V communication over short-range networks, cellular networks, etc. Before sending a message, vehicles 293E and 292E can sign the message using their respective public key certificates. For example, vehicle 293E can sign a V2V message using public key certificate 294E. Similarly, vehicle 292E can sign a V2V message using public key certificate 295E. In one embodiment, public key certificates 294E and 295E are associated with vehicles 293E and 292E, respectively.

[0143] Upon receiving communication from each other, the transport vehicle can verify the signature using an authority such as Authentication Authority 291E. For example, transport vehicle 292E can verify with Authentication Authority 291E that the public key certificate 294E used by transport vehicle 293E to sign V2V communication is trustworthy. If transport vehicle 292E successfully verifies public key certificate 294E, the transport vehicle knows that the data comes from a legitimate source. Similarly, transport vehicle 293E can verify with Authentication Authority 291E that the public key certificate 295E used by transport vehicle 292E to sign V2V communication is trustworthy. Additionally, features such as those described and depicted herein can be utilized in this network and other networks and / or systems (including those described and depicted herein). Figure 2M This solution is described and depicted.

[0144] Figure 3A A flowchart 300 according to an example embodiment is illustrated. (Refer to...) Figure 3A The vehicle determines that a problem based on sensor data 114 will soon occur on the vehicle, determines the time when the problem will occur, and displays the time when the problem will occur, 306. In one embodiment, sensor data 114 can be received from one or more sensors 110 associated with the vehicle 120. In another embodiment, sensor data 114 can be received from one or more sensors 110 associated with other vehicles(s) 154.

[0145] Figure 3B Another flowchart 320 according to an example embodiment is illustrated. (Refer to...) Figure 3BIn block 322, the vehicle 120 determines one or more actions to resolve the problem; in block 324, it selects an action from the one or more actions; in block 326, it displays the action; in block 328, it includes a history of sensor data 114 in the sensor data indicating an approaching threshold that suggests a problem will occur soon; in block 330, it determines a problem in response to the vehicle 120 being stationary and inactive; and in block 332, it provides a notification of the problem to the device. In one embodiment, sensor data 114 may be received from one or more sensors 110 associated with the vehicle 120. In another embodiment, sensor data 114 may be received as sensor data 114 from other (one or more) vehicles(s).

[0146] Figure 3C A further flowchart 340 according to an example embodiment is illustrated. (Refer to...) Figure 3C The method includes receiving verification of a problem from the consensus of the transportation vehicle 342 and having the transportation vehicle perform a smart contract to record the verification and the time when the problem will occur 126 on the blockchain 344.

[0147] Figure 4 The diagram illustrates a machine learning transportation network 400 according to an example embodiment. Network 400 includes transportation nodes 402 connected to a machine learning subsystem 406 via an interface. Each transportation node includes one or more sensors 404.

[0148] The machine learning subsystem 406 includes a learning model 408, which is a mathematical product created by a machine learning training system 410 that generates predictions by finding patterns in one or more training datasets. In some embodiments, the machine learning subsystem 406 resides in the transport node 402. In other embodiments, the machine learning subsystem 406 resides outside the transport node 402.

[0149] Transport node 402 sends data from one or more sensors 404 to machine learning subsystem 406. Machine learning subsystem 406 provides the data from one or more sensors 404 to learning model 408, which returns one or more predictions. Machine learning subsystem 406 sends one or more instructions to transport node 402 based on the predictions from learning model 408.

[0150] In other embodiments, transport node 402 may send data from one or more sensors 404 to machine learning training system 410. In another embodiment, machine learning subsystem 406 may send sensor 404 data to machine learning subsystem 410. One or more of the applications, features, steps, solutions, etc., described and / or depicted herein may utilize the machine learning network 400 described herein.

[0151] Figure 5A The illustration depicts an example vehicle configuration 500 for managing database transactions associated with a vehicle, according to an example embodiment. (Refer to...) Figure 5A When a specific means of transport / vehicle 525 engages in transactions (e.g., vehicle service, dealership transactions, delivery / pickup, transportation services, etc.), the vehicle can receive assets 510 and / or evict / transfer assets 512 according to (one or more) transactions. A means of transport processor 526 resides in vehicle 525, and communication exists between means of transport processor 526, database 530, and transaction module 520. Transaction module 520 can record information such as assets, parties, credit, service description, date, time, location, results, notifications, and unexpected events. Transactions in transaction module 520 can be replicated to database 530. Database 530 can be one of SQL database, RDBMS, relational database, non-relational database, blockchain, or distributed ledger, and can be on the means of transport, off the means of transport, directly accessed and / or accessed via a network, or accessible to the means of transport.

[0152] Figure 5B The illustration depicts an example vehicle configuration 550 for managing database transactions between various vehicles, according to an example embodiment. When vehicle 525 reaches a state where it needs to share services with another vehicle, vehicle 525 can establish a close relationship with another vehicle 508 to perform various actions such as sharing, transferring, and requesting service. For example, vehicle 508 may be scheduled to charge its battery and / or may have a tire problem and be on its way to pick up a package to be delivered. A vehicle processor 528 resides in vehicle 508, and there is communication between vehicle processor 528, database 554, and transaction module 552. Vehicle 508 can notify another vehicle 525 operating in its network and on its blockchain member service. A vehicle processor 526 resides in vehicle 525, and there is communication between vehicle processor 526, database 530, and transaction module 520. Vehicle 525 can then receive information from vehicle 508 and / or a server (not shown) via a wireless communication request to perform package retrieval. Transactions are recorded in transaction modules 552 and 520 of the two vehicles. Credit is transferred from vehicle 508 to vehicle 525, and the record of the transferred service is recorded in databases 530 / 554 (assuming the blockchains are different from each other) or in the same blockchain available to all members. Database 554 can be one of the following: SQL database, RDBMS, relational database, non-relational database, blockchain, distributed ledger, and can be on the means of transport, off the means of transport, and can be accessed directly and / or via a network.

[0153] Figure 6A The illustration shows a blockchain architecture configuration 600 according to an example embodiment. (Refer to...) Figure 6A The blockchain architecture 600 may include certain blockchain elements, such as a group of blockchain member nodes 602-606 as part of blockchain group 610. In one example embodiment, not all parties can access the permissioned blockchain; only those members with permission to access the blockchain data can access it. Blockchain nodes participate in many activities such as the blockchain entry addition and verification process (consensus). One or more blockchain nodes may endorse entries based on an endorsement policy and may provide a sorting service for all blockchain nodes. Blockchain nodes may initiate blockchain actions (such as authentication) and attempt to write to the immutable blockchain ledger stored in the blockchain, a copy of which may also be stored on the underlying physical infrastructure.

[0154] Blockchain transaction 620 is stored in the computer's memory when it is received and approved by the consensus model defined by the member nodes. Approved transactions 626 are stored in the current block of the blockchain and submitted to the blockchain via a commit process that includes hashing the data content of the transaction in the current block and referencing previous hashes from previous blocks. Within the blockchain, one or more smart contracts 630 may exist. Smart contracts define the terms of transaction protocols and actions, such as registered recipients, vehicle characteristics, requests, permissions, sensor thresholds, etc., included in the smart contract executable application code 632. The code can be configured to identify whether a requesting entity is registered to receive vehicle services, which service characteristics they are authorized / requested to receive given their profile status, and whether their actions are monitored in subsequent events. For example, when a service event occurs and a user is in the vehicle, sensor data monitoring can be triggered, and specific parameters such as the vehicle's battery level can be identified as being above / below a specific threshold within a specific time period. The result can then be changed to a current state requiring a warning to be sent to management (i.e., the vehicle owner, vehicle operator, server, etc.), thus identifying the service and storing information for reference. The collected vehicle sensor data can be based on the type of sensor data used to collect information about the vehicle's status. Sensor data can also form the basis of vehicle event data 634, such as the location(s) to be traveled, average speed, maximum speed, acceleration rate, presence of any collisions, whether a planned route has been taken, the next destination, whether safety measures are in place, and whether the vehicle has sufficient battery / fuel. All such information can form the basis of smart contract terms 630, which are then stored in the blockchain. For example, sensor thresholds stored in the smart contract can be used as the basis for determining whether a detected service is necessary and when and where the service should be performed.

[0155] Figure 6B The illustration shows a shared ledger configuration according to an example embodiment. (Refer to...) Figure 6B Blockchain logic example 640 includes a blockchain application interface 642, which serves as an API or plug-in application. This blockchain application interface 642 links to a computing device and execution platform for a specific transaction. Blockchain configuration 640 may include one or more applications that link to the application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.). This program / application code may be created according to a customized configuration sought by the participants and may maintain its own state, control its own assets, and receive external information. It can be deployed as an entry and installed on all blockchain nodes via attachment to the distributed ledger.

[0156] Smart contract application code 644 provides the foundation for blockchain transactions by establishing application code that activates the terms and conditions of the transactions upon execution. Smart contract 630, upon execution, generates certain approved transactions 626, which are then forwarded to the blockchain platform 652. This platform includes security / authorization 658, computing devices for executing transaction management 656, and a storage unit 654 that stores transactions and smart contracts on the blockchain.

[0157] A blockchain platform can include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and the physical computer infrastructure that supports receiving and storing new entries and providing access to auditors attempting to access data entries. The blockchain can expose interfaces that provide access to the virtual execution environment necessary to process program code and establish a close relationship with the physical infrastructure. Cryptographic trust services can be used to verify entries such as asset exchange entries while maintaining information privacy.

[0158] Figure 6A and Figure 6B The blockchain architecture configuration can process and execute program / application code via one or more interfaces exposed by the blockchain platform and the services it provides. As a non-restricted example, smart contracts can be created to execute alerts, updates, and / or other notifications of changes, updates, etc. Smart contracts can themselves be used to identify authorization and access requests related to the ledger and the rules associated with their use. For example, this information may include a new entry, which can be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The result may include deciding to reject or approve the new entry based on criteria defined in the smart contract and / or the consensus of the peers. Any of the data or information described herein can be retrieved using physical infrastructure.

[0159] Within the executable code of a smart contract, smart contracts can be created using high-level applications and programming languages, and then written into blocks in the blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated using a blockchain (e.g., a distributed network of blockchain peers). An entry is the execution of smart contract code that can be executed in response to the satisfaction of conditions associated with the smart contract. Execution of a smart contract can trigger trusted modifications(s) to the state of the digital blockchain ledger. Modifications(s) to the blockchain ledger caused by the execution of a smart contract can be automatically replicated throughout the distributed network of blockchain peers via one or more consensus protocols.

[0160] Smart contracts can write data to the blockchain in key-value pair format. Furthermore, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. This code can be used to create temporary data structures in virtual machines or other computing platforms. Data written to the blockchain can be public and / or can be encrypted and kept private. Temporary data used / generated by smart contracts is kept in memory by the supplied execution environment and then deleted once the data needed by the blockchain is identified.

[0161] Smart contract executable code can include a code interpretation of the smart contract with additional features. As described herein, smart contract executable code can be program code deployed on a computing network, executed on the network, and verified by chain validators during the consensus process. The smart contract executable code receives a hash and retrieves a hash from the blockchain associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches a hash created using the stored identifier template data, the smart contract executable code sends an authorization key to the requested service. The smart contract executable code can write data associated with cryptographic details to the blockchain.

[0162] Figure 6C The illustration depicts a blockchain configuration for storing blockchain transaction data according to an example embodiment. (Refer to...) Figure 6C Example configuration 660 enables vehicle 662, user equipment 664, and server 666 to share information with a distributed ledger (i.e., blockchain) 668. The server may act on behalf of a service provider entity that, knowing an established user profile is attempting to rent a vehicle with an established rating profile, consults the vehicle service provider to share user profile rating information. Server 666 may be receiving and processing data related to vehicle service requests. When service events occur, such as vehicle sensor data indicating a need for fuel / electricity, maintenance services, etc., smart contracts can be used to invoke rules, thresholds, sensor information collection, etc., that can be used to invoke vehicle service events. For various transactions such as access events, subsequent updates to the vehicle service status, event updates, etc., blockchain transaction data 670 is maintained. The transaction may include the parties, requirements (e.g., being 18 years of age or older, a qualified candidate, a valid driver's license, etc.), compensation level, distance traveled during the event, registered recipients authorized to access the event and host the vehicle service, permissions / permissions, sensor data retrieved during the vehicle event operation to record details of the next service event and identify the vehicle's condition status, and thresholds used to determine whether the service event is completed and whether the vehicle's condition status has changed.

[0163] Figure 6D The illustration shows a blockchain block 680 that can be added to the distributed ledger according to an example embodiment, and block structures 682A to 682. n The content. (Refer to...) Figure 6D A client (not shown) can submit entries to a blockchain node to establish an activity on the blockchain. As an example, the client could be an application that proposes an action for an entry on the blockchain on behalf of a requester such as a device, person, or entity. Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and copies of the distributed ledger. Different types of blockchain nodes / peers can exist in a blockchain network, including endorsement peers that simulate and endorse entries proposed by clients, and submission peers that verify endorsements, confirm entries, and submit them to the distributed ledger. In this example, a blockchain node can act as an endorser node, a submitter node, or both.

[0164] This system comprises a blockchain that stores immutable sequential records in blocks and a state database (current world state) that maintains the current state of the blockchain. Each channel can have a distributed ledger, and each peer maintains its own distributed ledger copy for each channel it belongs to. This blockchain is an entry log, constructed as a hashed chain of blocks where each block contains a sequence of N entries. Blocks can include, for example... Figure 6D The blockchain comprises various components, such as the elements shown. Blocks can be linked by adding a hash of the header of the previous block to the current block's block header. In this way, all entries on the blockchain are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of the links, the latest block in the blockchain represents every entry that came before it. This blockchain can be stored on a peer-to-peer file system (local or attached storage) that supports attaching only blockchain workloads.

[0165] The current state of the blockchain and its distributed ledger can be stored in a state database. Here, the current state data represents the latest values ​​of all keys ever included in the blockchain's entry log. Smart contract executables call and execute entries that refer to the current state in the state database. To make these smart contract executable interactions highly efficient, the latest values ​​of all keys are stored in the state database. The state database can include an indexed view in the blockchain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored after peer startup but before entries are accepted (or generated when needed).

[0166] Endorsing nodes receive entries from clients and endorse them based on the simulation results. Each endorsing node holds a smart contract proposing the simulated entry. When an endorsing node endorses an entry, it creates an entry endorsement, which is a signed response from the endorsing node to the client application instructing the simulated entry to be endorsed. The method of endorsing an entry depends on the endorsement policy, which can be specified within the smart contract's executable code. An example of an endorsement policy is "most endorsing peers are required to endorse the entry." Different channels can have different endorsement policies. The client application forwards the endorsed entry to the ordering service.

[0167] The ordering service accepts endorsed entries, sorts them into blocks, and then passes the blocks to committing peers. For example, the ordering service can initiate a new block when a threshold for entries is reached, a timer times out, or another condition occurs. In this example, the blockchain node is a committing peer that has received data block 682A to be stored on the blockchain. The ordering service can consist of a cluster of orderers. The ordering service does not handle entries, smart contracts, or the shared ledger. Specifically, the ordering service can accept endorsed entries and specify the order in which these entries are committed to the distributed ledger. The architecture of the blockchain network can be designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) become pluggable components.

[0168] Entries are written to the distributed ledger in a consistent order. Establishing this order ensures that updates to the state database are valid when they are committed to the network. Unlike cryptocurrency blockchain systems that sort entries by solving cryptographic puzzles or mining (e.g., Bitcoin), in this example, the parties to the distributed ledger can choose the sorting mechanism best suited to the network.

[0169] Reference Figure 6DBlock 682A (also referred to as a data block) stored on the blockchain and / or distributed ledger may include multiple data segments such as block headers 684A to 684n, transaction-specific data 686A to 686n, and block metadata 688A to 688n. It should be understood that the various boxes and contents depicted, such as block 682A and its contents, are merely illustrative and are not intended to limit the scope of the exemplary embodiments. In some cases, both block header 684A and block metadata 688A may be smaller than the transaction-specific data 686A storing entry data; however, this is not required. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 690A to 690n. Block 682A may also include links to previous blocks (e.g., on the blockchain) within block header 684A. Specifically, block header 684A may include the hash of the headers of previous blocks. Block header 684A may also include a unique block number, the hash of block data 690A of the current block 682A, etc. The block number of block 682A can be unique and assigned incrementally / sequentially starting from zero. The first block in the blockchain can be called the genesis block, which includes information about the blockchain, its members, the data stored in it, etc.

[0170] Block data 690A can store entry information for each entry recorded within a block. For example, entry data may include entry type, version, timestamp, channel ID of the distributed ledger, entry ID, period, payload visibility, smart contract executable code path (deployment tx), smart contract executable code name, smart contract executable code version, inputs (smart contract executable code and functions), client (creator) identifiers such as public keys and certificates, client signature, endorser identifier, endorser signature, proposal hash, smart contract executable code event, response status, namespace, read set (a list of keys and versions read by the entry, etc.), write set (a list of keys and values, etc.), start key, end key, list of keys, Merkel tree query digest, etc. Entry data for each of N entries can be stored.

[0171] In some embodiments, block data 690A may also store transaction-specific data 686A of the chain of hash links of blocks that add additional information to the blockchain. Thus, data 686A can be stored in the immutable log of blocks on the distributed ledger. Some benefits of storing such data 686A are reflected in the various embodiments disclosed and depicted herein. Block metadata 688A may store multiple fields of metadata (e.g., as a byte array, etc.). Metadata fields may include a signature at the time of block creation, a reference to the last configured block, an entry filter identifying valid and invalid entries within the block, the last offset maintained by a sorting service that sorts the blocks, etc. The signature, the last configured block, and the sorter metadata can be added via the sorting service. Simultaneously, the block submitter (e.g., a blockchain node) may add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The entry filter may include a byte array of size equal to the number of entries in block data 610A and a verification code identifying whether an entry is valid / invalid.

[0172] Other blocks 682B through 682n in the blockchain also have headers, files, and values. However, unlike the first block 682A, each of the headers 684A through 684n in the other blocks includes the hash value of the previous block. The hash value of the previous block can be exactly the hash value of the header of the previous block, or it can be the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, a traceback from the Nth block back to the genesis block (and the associated original file) can be performed block by block as indicated by arrow 692, to establish an auditable and immutable chain of custody.

[0173] The above embodiments can be implemented in hardware, as a computer program executed by a processor, as firmware, or a combination thereof. The computer program can be implemented on a computer-readable medium such as a storage medium. For example, the computer program can reside in random access memory (“RAM”), flash memory, read-only memory (“ROM”), erasable programmable read-only memory (“EPROM”), electrically erasable programmable read-only memory (“EEPROM”), registers, hard disks, removable disks, optical disc read-only memory (“CD-ROM”), or any other form of storage medium known in the art.

[0174] An exemplary storage medium can be coupled to a processor, allowing the processor to read information from and write information to the storage medium. In an alternative form, the storage medium can be integrated with the processor. The processor and storage medium can reside in an application-specific integrated circuit (“ASIC”). Alternatively, the processor and storage medium can reside as separate components. For example, Figure 7The illustration shows an example computer system architecture 700, which can be represented or integrated into any of the aforementioned components.

[0175] Figure 7 This is not intended to imply any limitation on the scope or functionality of the embodiments of the applications described herein. In any case, the compute node 700 is capable of implementing and / or performing any of the functions set forth above.

[0176] Within compute node 700, there exists a computer system / server 702 that can operate alongside numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with computer system / server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0177] The computer system / server 702 can be described within the overall context of a computer system executing computer system executable instructions such as program modules. Typically, program modules can include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. The computer system / server 702 can be implemented in a distributed cloud computing environment, where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules can reside on both local computer system storage media and remote computer system storage media, including memory storage devices.

[0178] like Figure 7 As shown, a computer system / server 702 in a cloud computing node 700 is illustrated in the form of a general-purpose computing device. Components of the computer system / server 702 may include, but are not limited to, one or more processors or processing units 704, system memory 706, and buses that couple various system components, including system memory 706, to processor 704.

[0179] A bus represents one or more of several types of bus architectures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses that use any of the various bus architectures. For example, and not as a limitation, such architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0180] Computer system / server 702 typically includes a variety of computer system readable media. This media can be any available media accessible to computer system / server 702, and it includes both volatile and non-volatile media, removable and non-removable media. In one embodiment, system memory 706 implements a flowchart of another diagram. System memory 706 may include computer system readable media in the form of volatile memory such as random access memory (RAM) 708 and / or cache 710. Computer system / server 702 may also include other removable / non-removable, volatile / non-volatile computer system storage media. For example only, memory 706 may be provided for reading and writing from non-removable non-volatile magnetic media (not shown and generally referred to as a "hard disk drive"). Although not shown, disk drives for reading and writing to non-removable non-volatile disks (e.g., "floppy disks") and optical disk drives for reading or writing to removable non-volatile optical disks such as CD-ROMs, DVD-ROMs, or other optical media may be provided. In this case, each may be connected to a bus via one or more data media interfaces. As will be further depicted and described below, memory 706 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of this application.

[0181] A program / utility having a set (at least one) of program modules can be stored in memory 706 (for example, but not limited to) as well as in an operating system, one or more applications, other program modules, and program data. Each of the operating system, one or more applications, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. The program modules typically perform functions and / or methods as described herein in various embodiments of this application.

[0182] As those skilled in the art will understand, aspects of this application can be implemented as a system, method, or computer program product. Therefore, aspects of this application can take the form of a fully hardware embodiment, a fully software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which may generally be referred to herein as a “circuit,” “module,” or “system.” Furthermore, aspects of this application can take the form of a computer program product implemented on one or more computer-readable media having computer-readable program code embodied thereon.

[0183] The computer system / server 702 can also communicate with one or more external devices via I / O devices 712 (such as I / O adapters), one or more devices enabling users to interact with the computer system / server 702, and / or any device enabling the computer system / server 702 to communicate with one or more other computing devices (e.g., network interface cards, modems, etc.). I / O devices 712 may include keyboards, pointing devices, displays, voice recognition modules, etc. This communication can occur via the I / O interface of device 712. Again, the computer system / server 702 can communicate with one or more networks such as local area networks (LANs), general area networks (WANs), and / or public networks (e.g., the Internet) via network adapters. As depicted, device 712 communicates with other components of the computer system / server 702 via a bus. It should be understood that, although not shown, other hardware and / or software components can be used in conjunction with the computer system / server 702. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archiving storage systems.

[0184] Although exemplary embodiments of at least one of the systems, methods, and non-transient computer-readable media are illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that this application is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications, and substitutions as set forth and defined in the appended claims. For example, the capabilities of the systems in the various figures can be implemented by one or more of the modules or components described herein or in a distributed architecture, and may include transmitters, receivers, or pairs of both. For example, all or part of the functions performed by individual modules can be performed by one or more of these modules. In addition, the functions described herein can be performed internally or externally to modules or components at various times in relation to various events. Furthermore, information transmitted between modules can be transmitted via at least one of the following: data networks, the Internet, voice networks, Internet Protocol networks, wireless devices, wired devices, and / or via multiple protocols. Additionally, messages sent or received by any of the modules can be sent or received directly and / or via one or more of the other modules.

[0185] Those skilled in the art will understand that the "system" can be implemented as a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartphone, or any other suitable computing device or combination of these devices. Presenting the above-described functions as being performed by the "system" is not intended to limit the scope of this application in any way, but rather to provide one example of many embodiments. In fact, the methods, systems, and apparatuses disclosed herein can be implemented in local and distributed forms consistent with computing technologies.

[0186] It should be noted that some system features described in this specification have been presented as modules to more specifically emphasize their implementation independence. For example, modules can be implemented as hardware circuits comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Modules can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0187] Modules can also be implemented, at least partially, in software for execution by various types of processors. The identified executable code unit may, for example, comprise one or more physical or logical blocks of computer instructions that can be organized, for example, into objects, procedures, or functions. However, the executable files of the identified module do not need to be physically located together, but may include different instructions stored in different locations that, when logically combined, encompass the module and achieve its stated purpose. Additionally, the module may be stored on a computer-readable medium, such as a hard disk drive, flash memory device, random access memory (RAM), magnetic tape, or any other such medium for storing data.

[0188] In practice, executable code modules can be single instructions or multiple instructions, and can even be distributed across several different code segments, different programs, and multiple storage devices. Similarly, operational data can be identified and illustrated within the modules herein, and can be implemented in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single dataset, or it can be distributed across different locations, including across different storage devices, and can exist at least partially as electronic signals within the system or network.

[0189] It will be readily understood that the components of this application, as generally described and illustrated in the accompanying drawings, can be arranged and designed in a wide variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments of the application.

[0190] It will be readily understood by those skilled in the art that the above can be practiced in a different order of steps and / or with hardware components configured differently from the disclosed configuration. Therefore, although this application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be readily apparent.

[0191] Although preferred embodiments of the present application have been described, it is to be understood that the described embodiments are merely illustrative, and the scope of the present application will be defined solely by the appended claims when considering a range of equivalents and modifications thereof (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A method for approximating the time of a problem, comprising: The transportation vehicle receives sensor data from the sensor within a time period; The rate of change of the sensor data within the time period is identified by the means of transport; The average time period during which the sensor data identified by the vehicle reaches a threshold, wherein reaching the threshold leads to a change in the operation of the vehicle; The timing of future problems for a transport vehicle is predicted by identifying, based on the rate of change of the sensor data, that the time when the sensor data will reach the threshold is less than the average time period. The time of the future occurrence is displayed on a monitor via the transport vehicle; The operator of the transport vehicle was not checking the displayed time, as detected by the transport vehicle itself. as well as In response to the detection, the characteristics of the vehicle are dynamically changed until the operator views the displayed time.

2. The method according to claim 1, comprising: One or more actions are determined by the means of transport to address the problem; The means of transport selects an action from the one or more actions; as well as The selected action is displayed via the display.

3. The method according to claim 1, wherein, The average time period during which the identified data reaches the threshold also includes: The average time period is calculated based on historical sensor data.

4. The method according to claim 1, wherein, Indicating the time of future occurrences also includes: The time is displayed via a device associated with one or more of the means of transport and its owner.

5. The method according to claim 1, comprising: The time at which the future event is determined by the means of transport is earlier than the time when the means of transport is expected to arrive at its destination. as well as Provide recommendations to mitigate the problem within a timeframe preceding the time when the future event occurs.

6. The method according to claim 1, comprising: The vehicle receives verification of one or more of the following: the problem, the sensor data, the threshold, and the time when the problem will occur, wherein the verification includes blockchain consensus among a group of peers including the vehicle and one or more other vehicles.

7. The method of claim 6, comprising: The means of transport fulfills a smart contract based on the blockchain consensus to verify and record the time of the future occurrence on the blockchain.

8. A means of transport, comprising: The processor, when executing instructions stored in associated memory, is configured to: Receive sensor data from the sensor within a time period; Identify the rate of change of the sensor data within the time period; Identify the average time period during which the sensor data reaches a threshold, wherein reaching the threshold leads to a change in the operation of the vehicle; The timing of future problems with the transportation vehicle is predicted by identifying, based on the rate of change of the sensor data, that the time when the sensor data will reach the threshold is less than the average time period. The display shows the time when the future event will occur. It was detected that the operator of the transport vehicle did not check the displayed time; as well as In response to the detection, the characteristics of the vehicle are dynamically changed until the operator views the displayed time.

9. The means of transport according to claim 8, wherein, Configured as: Determine one or more actions to solve the problem; Select an action from the one or more actions; and The selected action is displayed via the display.

10. The means of transport according to claim 8, wherein, When the processor identifies data over an average time period that reaches a threshold, the processor is further configured to: The average time period is calculated based on historical sensor data.

11. The means of transport according to claim 8, wherein, When the processor causes the display to show a time that will occur in the future, the processor is configured to: The time is displayed via a device associated with one or more of the means of transport and its owner.

12. The means of transport according to claim 8, wherein, The processor is also configured to: Determine that the future occurrence occurs earlier than the expected arrival time of the means of transport at its destination; and Provide recommendations to mitigate the problem within a timeframe preceding the time when the future event occurs.

13. The means of transport according to claim 8, wherein, The processor is also configured to: The system receives verification of one or more of the following: the problem, the sensor data, the threshold, and the time when the problem will occur, wherein the verification includes blockchain consensus among a group of peers including the vehicle and one or more other vehicles.

14. The means of transport according to claim 13, wherein, The processor is also configured to: The means of transport fulfills a smart contract based on blockchain consensus to record the verification and the time of the future occurrence on the blockchain.

15. A non-transient computer-readable medium comprising instructions, when executed by a processor of a means of transport, to cause the processor to perform the following steps: Receive sensor data from the sensor within a time period; Identify the rate of change of the sensor data within the time period; Identify the average time period during which the sensor data reaches a threshold, wherein reaching the threshold leads to a change in the operation of the vehicle; The timing of future problems with the transportation vehicle is predicted by identifying, based on the rate of change of the sensor data, that the time when the sensor data will reach the threshold is less than the average time period. The time of the future occurrence is displayed on a monitor via a means of transport; It was detected that the operator of the transport vehicle did not check the displayed time; as well as In response to the detection, the characteristics of the vehicle are dynamically changed until the operator views the displayed time.

16. The non-transient computer-readable medium according to claim 15, wherein, The instruction also causes the processor to execute: Determine one or more actions to solve the problem; Select an action from the one or more actions; and The selected action is displayed via the display.

17. The non-transient computer-readable medium according to claim 15, wherein, The average time period during which the identified data reaches the threshold also includes: The average time period is calculated based on historical sensor data.

18. The non-transient computer-readable medium according to claim 15, wherein, Indicating the time of future occurrences also includes: The time is displayed via a device associated with one or more of the means of transport and its owner.

19. The non-transient computer-readable medium according to claim 15, wherein, The instruction also causes the processor to execute: Determine that the future occurrence occurs earlier than the expected arrival time of the means of transport at its destination; and Provide recommendations to mitigate the problem within a timeframe preceding the time when the future event occurs.

20. The non-transient computer-readable medium according to claim 15, wherein, The instruction also causes the processor to execute: The system receives verification of one or more of the following: the problem, the sensor data, the threshold, and the time when the problem will occur, wherein the verification includes blockchain consensus among a group of peers comprising the vehicle and one or more other vehicles; and The smart contract is executed based on the blockchain consensus, and the verification and the time of the future occurrence are recorded on the blockchain.

Images