Estimate the time of the problem

Abstract

Exemplary operations include one or more of determining that a problem will soon occur with the vehicle, determining a time at which the problem will occur with the vehicle, and displaying a time at which the problem will occur with the vehicle, the problem being based on sensor data approaching a threshold value in a time period that is faster than an average time period.

Description

Background Art

[0001] Vehicles or transportation means such as cars, motorcycles, trucks, airplanes, trains, etc. generally provide transportation needs for passengers and / or goods in various ways. The functions related to the transportation means are identified and utilized by various computing devices such as smartphones or computers disposed on and / or outside the transportation means.

Summary of the Invention

[0002] One exemplary embodiment provides a method including one or more of: determining by a transportation means that a problem will soon occur; determining by the transportation means the time at which the problem will occur; and displaying by the transportation means the time at which the problem will occur. The problem is based on sensor data approaching a threshold within a period earlier than an average period.

[0003] Another exemplary embodiment provides a system including a memory communicably coupled to a processor, the processor being configured to perform one or more of: determining by a transportation means that a problem will soon occur; determining by the transportation means the time at which the problem will occur; and displaying by the transportation means the time at which the problem will occur. The problem is based on sensor data approaching a threshold within a period earlier than an average period.

[0004] Yet another exemplary embodiment provides a non-transitory computer-readable medium including instructions that, when read by a processor, cause the processor to perform one or more of: determining by a transportation means that a problem will soon occur; determining by the transportation means the time at which the problem will occur; and displaying by the transportation means the time at which the problem will occur. The problem is based on sensor data approaching a threshold within a period earlier than an average period.

Brief Description of the Drawings

[0005]

Figure 1A

Figure 1B

Figure 2A

Figure 2B

Figure 2C

Figure 2D

Figure 2E

Figure 2F

Figure 2G

Figure 2H

Figure 2I

Figure 2J

Figure 2K

Figure 2L

Figure 2M

Figure 3A

Figure 3B

Figure 3C

Figure 4

Figure 5A

Figure 5B

Figure 6A

Figure 6B

Figure 6C

Figure 6D

Figure 7

Modes for Carrying Out the Invention

[0006] It will be readily understood that the components as generally described and shown in the figures of this specification can be configured and designed in a wide variety of different configurations. For this reason, the following detailed description of at least one embodiment of a method, apparatus, non-transitory computer-readable medium, and system as represented in the accompanying drawings is not intended to limit the scope of the present application in the claims, but merely represents a selected embodiment.

[0007] Communication between a transportation agency and an entity such as a remote server, another transportation agency, and a local computing device (e.g., a smartphone, a personal computer, an in-vehicle computer, etc.) is transmitted and / or received and processed by one or more "components" that can be hardware, firmware, software, or a combination thereof. The components are part of any of these entities, computing devices, or some other computing device. In one example, the determination of consensus regarding a blockchain transaction is performed by one or more computing devices or components (which can be any element described and / or depicted herein) associated with the transportation agency and one or more components located outside or remote from the transportation agency.

[0008] The features, structures, or characteristics described throughout this specification can be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrases "exemplary embodiments", "some embodiments", or other similar terms refers to the fact that the particular features, structures, or characteristics described in connection with the embodiments are included in at least one embodiment. Thus, throughout this specification, the appearances of the phrases "exemplary embodiments", "in some embodiments", "in other embodiments", or other similar terms are not necessarily all referring to the same group of embodiments, and the described features, structures, or characteristics are combined in any suitable manner in one or more embodiments. In the figures, any connection between elements enables one-way and / or two-way communication, whether the depicted connection is a one-way or two-way arrow. In current solutions, transportation agencies include one or more of vehicles, trucks, pedestrian area battery electric vehicles (BEVs), e-pallets, fuel cell buses, motorcycles, scooters, bicycles, boats, recreational vehicles, airplanes, and any object used to transport people and / or goods from one place to another.

[0009] In addition, although the term "message" may have been used in the description of the embodiments, other types of network data such as packets, frames, datagrams, etc. may also be used. Further, although certain types of messages and signal transmissions may be depicted, in the exemplary embodiments, these are not limited to certain types of messages and signal transmissions.

[0010] Exemplary embodiments provide a method, system, component, non-transitory computer-readable medium, device, and / or network, and provide at least one of a transportation vehicle (also referred to herein as a vehicle or car), a data collection system, a data monitoring system, a verification system, an authentication 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 is processed to identify the status of the vehicle / transportation vehicle and provide feedback regarding the status and / or changes of the transportation vehicle. In one example, a user profile is applied to a particular transportation vehicle / car to approve current vehicle events, approve service stops at service stations, approve subsequent vehicle rental services, and enable vehicle-to-vehicle communication.

[0011] In a communication infrastructure, a distributed database is a distributed storage system that includes multiple nodes that communicate with each other. A blockchain is an example of a distributed database that includes an append-only immutable data structure (i.e., a distributed ledger) that can maintain records among untrusted parties. In this specification, untrusted parties are referred to as peers, nodes, or peer nodes. Each peer maintains a copy of the database records, and no single peer can modify the database records unless a consensus is reached among the distributed peers. For example, a peer can execute a consensus protocol to verify storage entries of the blockchain, group the storage entries into blocks, and construct a hash chain through the blocks. This process forms a ledger by ordering the storage entries as necessary for consistency. In a public blockchain or permissionless blockchain, anyone can participate without a specific ID. A public blockchain includes cryptocurrencies and can use consensus based on various protocols such as proof of work (PoW). Conversely, a permissioned blockchain database can protect exchanges among groups of entities that share a common goal, such as a business that exchanges funds, goods, information, etc., but cannot fully trust each other. This solution can function in the setting of a permissioned blockchain and / or a permissionless blockchain.

[0012] A smart contract is a trusted distributed application that leverages the immutability of a shared or distributed ledger (existing in the form of a blockchain) and a basic agreement among member nodes, referred to as endorsement or endorsement policy. Generally, entries in a blockchain are "endorsed" before being committed to the blockchain, and unendorsed entries are ignored. A typical endorsement policy enables the executable code of a smart contract to identify the endorsers of an entry in the form of a set of peer nodes required 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 an ordering phase, where a consensus protocol is used to generate an ordered sequence of the endorsed entries grouped into blocks.

[0013] A node is a communication entity in a blockchain system. A "node" performs a logical function in the sense that multiple nodes of various types can operate on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control the nodes in various ways. Nodes include various types such as client nodes or submitting client nodes that submit entry invocations to an endorser (e.g., a peer) and broadcast entry proposals to an ordering service (e.g., an ordering node). Another type of node is a peer node that can receive entries submitted by a client, commit the entries, and maintain a copy of the state of the blockchain entries and the ledger. A peer can also serve as an endorser. An ordering service node or orderer is a node that performs a communication service for all nodes and implements delivery guarantees such as broadcasting to each of the peer nodes in the system when committing an entry to modify the world state of the blockchain. The world state can build the first blockchain entry that typically contains control and setup information.

[0014] A ledger is a sequenced, tamper-resistant record of all state transitions in a blockchain. State transitions result from calls to executable code of smart contracts (i.e., entries) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Entries commit sets of key-value pairs of assets to the ledger as one or more operands such as create, update, delete, etc. The ledger includes a blockchain (also referred to as a chain) that is used to store the immutable sequenced records in blocks. The ledger also includes a state database that maintains the current state of the blockchain. Typically, there is one ledger per channel. Each peer node maintains a copy of the ledger for each channel of which they are members.

[0015] A chain is an entry log structured as hash-linked blocks, each block containing a sequence of N entries, where N is greater than or equal to 1. The block header contains the hash of the block's entries and the hash of the previous block's header. In this way, all entries in the ledger are sequenced and cryptographically linked to each other. Therefore, it is not possible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents all entries on the chain that came before it, thereby ensuring that all peer nodes are in a consistent and trusted state. The chain is stored in a peer node file system (i.e., local, attached storage, cloud, etc.) and efficiently supports the append-only nature of the blockchain workload.

[0016] The current state of the immutable ledger represents the latest values for all keys included in the chain entry log. The current state is sometimes referred to as the world state as it represents the latest key values known to the channel. Calls to smart contract executable code execute entries against the current state data of the ledger. To efficiently facilitate the interaction of smart contract executable code, the latest values of keys are stored in a state database. Since the state database is merely an indexed view into the chain's entry log, it can be regenerated from the chain at any time. The state database is automatically restored (or generated as needed) upon startup of the peer node before entries are accepted.

[0017] A blockchain differs from a conventional database in that the blockchain is a distributed immutable and secure storage where nodes, rather than a central storage, must share changes to records in the storage. Some of the characteristics inherent in the blockchain and useful for the implementation of the blockchain include, but are not limited to, immutable ledger, smart contract, security, privacy, decentralization, consensus, endorsement, accessibility, etc.

[0018] Exemplary embodiments provide services to a particular vehicle and / or a user profile applied to the vehicle. For example, the user is the owner of the vehicle or an operator of a vehicle owned by another party. The vehicle may require services at certain intervals, and the service needs require authentication before permission to receive the service. Also, the service center provides services to vehicles in the neighboring area based on the vehicle's current route plan and the relative level of service requirements (e.g., immediate, critical, intermediate, minor, etc.). The needs of the vehicle are monitored via road sensors or cameras that report sensed data to one or more vehicles and / or a central controller computer device within and / or away from the vehicle. This data is transferred to the management server for review and action. The sensors are disposed on one or more of the interior of the transportation vehicle, the exterior of the transportation vehicle, fixed objects away from the transportation vehicle, and another transportation vehicle in proximity to the transportation vehicle. Also, the sensors are related to the speed of the transportation vehicle, the braking of the transportation vehicle, the acceleration of the transportation vehicle, the fuel level, the service needs, the gear shifting of the transportation vehicle, the steering of the transportation vehicle, etc. The sensors described herein may be devices such as wireless devices within and / or in proximity to the transportation vehicle. Also, the sensor information may be used to identify whether the vehicle is operating safely and whether the occupants are engaged in an unexpected vehicle condition such as during the access and / or use period of the vehicle. The vehicle information collected before, during, and / or after the operation of the vehicle is stored in a transaction on a shared / distributed ledger, and this transaction is committed to an immutable ledger in a "distributed" manner such as via a permissioned consortium and thus via a blockchain membership group as determined.

[0019] Each stakeholder (i.e., owner, user, company, agency, etc.) desires to limit the exposure of personal information, and for this reason, blockchain and its immutability can be used to manage permissions for each specific user vehicle profile. Smart contracts are used to provide rewards, quantify scores / evaluations / reviews of user profiles, apply permissions for vehicle events, determine when services are needed, identify collision and / or degradation events, identify safety concern events, identify the parties involved in an event, and provide distribution to registered entities that request access to data of such vehicle events. Also, based on the consensus approach related to the blockchain, the necessary information can be shared among registered companies and / or individuals. Such an approach could not be implemented on a conventional centralized database.

[0020] The various driving systems of this solution can utilize software, an array of sensors, as well as machine learning capabilities, light detection and ranging (LIDAR) projectors, radar, ultrasonic sensors, etc. to create maps of terrain and roads that can be used by transportation agencies for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, etc. can also be used in autonomous vehicles instead of LIDAR.

[0021] This solution, in one embodiment, involves authenticating a vehicle for a service via an automated and rapid authentication scheme. For example, driving to a charging station or a fuel pump is done by the vehicle's operator or an autonomous transportation agency, and the authentication for receiving charging or fuel is executed without delay if the authentication is received by the service and / or the charging station. The vehicle provides a communication signal that provides identification information of the vehicle having a currently active profile linked to an account that has been authenticated to receive the service, which can later be corrected by a reward. Additional means may be used to provide further authentication. For example, another identifier may be wirelessly transmitted from the user's device to the service center to replace or supplement the initial authentication operation between the transportation agency and the service center with an additional authentication operation.

[0022] The shared and received data is stored in a database, and the database maintains the data generally in one specific location in a single database (e.g., a database server). This location is often a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. The information stored in the centralized database is typically accessible from multiple different locations. Since the centralized database is in a single location, it is easy to manage, maintain, and control, especially for security purposes. Within the centralized database, the single storage location for all data also means that a given dataset has only one primary record, thus minimizing data redundancy. The blockchain is used to store data related to the transportation agency and transactions.

[0023] Any of the actions described in this specification is performed by one or more processors (such as a microprocessor, sensor, ECU, head unit, etc.) disposed on or outside the transportation vehicle. The one or more processors can communicate with other processors on or outside other transportation vehicles to utilize the data transmitted by the transportation vehicle. The one or more processors and the other processors can send data, receive data, and utilize this data to perform one or more of the actions described or depicted in this specification.

[0024] Generally, a transportation vehicle displays many parameters regarding the transportation vehicle and its operating state. During normal operation, warning lights or other forms of warning announcements do not occur, and the occupants of the transportation vehicle simply desire to check the status of the transportation vehicle or observe the current operating state. During abnormal operation, when a problem occurs, one or more warning lights or warning announcements are displayed. This warns the driver or the occupants of the transportation vehicle that it is necessary to address the problem at the current time (when the problem has already occurred). This application addresses predicted problems between these two states.

[0025] Figure 1A shows an exemplary flowchart 100 of data display of a transportation vehicle. Figure 1A shows a flowchart depicting the message flow between three entities, a sensor 110, a transportation vehicle 120, and a display 130 of the transportation vehicle. The sensor 110 is a sensor of the transportation vehicle 120 or a sensor external to the transportation vehicle 120. For example, the sensor 110 can be a sensor of a different transportation vehicle, a sensor 110 at a location close to the transportation vehicle 120, or a sensor 110 within the detection range of the transportation vehicle 120. Examples of the sensor 110 include, but are not limited to, cameras (both still cameras and video cameras), microphones, optical sensors, magnetic sensors, temperature sensors, pressure sensors, impact sensors, vibration sensors, or other types of sensors known in the art. The transportation vehicle 120 is any type of vehicle that transports or conveys any combination of passengers or cargo. The transportation vehicle 120 includes any processor associated with the transportation vehicle 120, including but not limited to a computer of the transportation vehicle, an infotainment system, a navigation computer, an ECU, or other components within the transportation vehicle including a processor and a memory. The display 130 of the transportation vehicle is a device that presents a visual image to the driver or passenger of the transportation vehicle 120 and will be described in more detail with respect to Figure 1B.

[0026] The sensor 110 obtains sensor data 112 via any wired or wireless means. The obtained sensor data 112 has a source from a device within / on the transportation vehicle 120 itself, another nearby transportation vehicle, or an external source of the transportation vehicle 120 such as a weather satellite, a building, a TV station, a radio station, the Internet, a network, or the cloud. The sensor 110 represents one sensor 110 or multiple sensors 110, and the number of sensors from which the sensor data 112 is obtained may change over time. After obtaining the sensor data 112, the sensor 110 transfers the sensor data 114 to the transportation vehicle 120. The sensor data 114 is transmitted via either a wired interface or a wireless interface.

[0027] After receiving sensor data 114 from sensor 110, transportation vehicle 120 determines a problem 122 based on the received sensor data 114. In one embodiment, transportation vehicle 120 determines that a problem will occur soon based on the received sensor data 114. The problem is based on sensor data 114 that approaches a threshold within a period earlier than an average period. The threshold represents a level of sensor data 114 corresponding to a time when a change to transportation vehicle 120, a change in the operation of transportation vehicle 120, or a safety concern should or must be addressed. The period earlier than the average period occurs before the average period. In one embodiment, transportation vehicle 120 observes the received sensor data 114 over time and determines a rate of change of the sensor data 114. This enables transportation vehicle 120 to predict future values of the sensor data 114. In one embodiment, the problem includes a maintenance recommendation based on a maintenance schedule corresponding to transportation vehicle 120. In another embodiment, the problem includes a safety warning.

[0028] In one embodiment, the average period is based on the history of transportation vehicle 120, other transportation vehicles, and / or similar types of transportation vehicles that have experienced the problem. In another embodiment, the average period is based on one or more predetermined (factory) predicted nominal maintenance intervals for transportation vehicle 120, other transportation vehicles, and / or similar types of transportation vehicles. In another embodiment, the average period takes into account season, geographical location conditions, weather (temperature, humidity, wind, snowfall, precipitation), driver identification information, and / or past acceleration, braking, shift change, and / or steering data corresponding to the current driver of transportation vehicle 120. Additionally, transportation vehicle 120 determines the time when the problem will occur 124 and provides the time when the problem will occur 126 to the display 130 of the transportation vehicle. The display 130 of the transportation vehicle is described in more detail with respect to FIG. 1B.

[0029] The transport mechanism 120 can determine the time when a problem occurs in several different ways. In one embodiment, a processor within an electronic control unit (ECU) continuously monitors the hydraulic pressure within the engine. Over time, the ECU's processor detects a steady increase in hydraulic pressure. High hydraulic pressure occurs when an external force is required to pump oil into the engine. The amount of pressure required to push the oil through the engine is set as a default parameter. In many common transport mechanisms, if the measured value slightly reaches 80 pounds per square inch (psi) or more, that value indicates that the transport mechanism should consider immediate repair. In another embodiment, a processor of the navigation system detects that the transport mechanism 120 does not include a map corresponding to the current location of the transport mechanism 120. After a series of such readings, the transport mechanism 120 concludes that it should obtain the necessary map or notifies the crew and / or the owner of the transport mechanism to obtain the necessary map.

[0030] The display 130 of the transport mechanism receives the time 126 when a problem occurs through any means, wired or wireless. After obtaining the time 126 when a problem occurs, the display 130 of the transport mechanism displays the time when the problem occurs 132 on one or more displays 130 of the transport mechanism. In one embodiment, displaying the sensor data 114 includes verbally notifying the crew of one or more transport mechanisms 120 or using sound or other visual indicators. In one embodiment, the information displayed is directly correlated with the sensors 110 that are affected based on the current operation of the transport mechanism 120. The information may be provided as sensor data 114 when there is a problem that will ultimately occur.

[0031] In one embodiment, the time 126 at which the problem occurs is based on a single type of sensor data 114. In another embodiment, the time 126 at which the problem occurs is based on multiple types of sensor data 114. In another embodiment, the time 126 at which the problem occurs is based on a single instance of sensor data 114. In another embodiment, the time 126 at which the problem occurs is based on multiple instances of sensor data 114.

[0032] The sensor data 114 includes any combination of text, audio, still images, video, telemetry, GPS coordinates, electroencephalograms, numerical values, or odors. The sensor data 114 is sourced from one or more sensors 110 on the transportation vehicle 120, another transportation vehicle, aircraft, or drone (such as a camera viewing the area of the transportation vehicle 120 of interest, a spark coming from under the transportation vehicle 120, smoke coming from the transportation vehicle 120, etc.), or a building or structure adjacent to the road on which the transportation vehicle 120 is traveling.

[0033] In one embodiment, the display 130 of the transportation vehicle always displays the most recently received sensor data 114 based on the current state and environment of the transportation vehicle 120. In another embodiment, the display 130 of the transportation vehicle always displays all of the sensor data 114 received within a predetermined time frame based on the current state and environment of the transportation vehicle 120. The predetermined time frame is measured in seconds, minutes, hours, days, weeks, or years. These states, environments, and predetermined time frames may change unpredictably, and as a result, the display of the sensor data 114 changes. The sensor data 114 may include various data items of different importance. More important sensor data 114 includes data that has more important results for the transportation vehicle 120, the owner of the transportation vehicle, the passengers of the transportation vehicle, or data that has a greater current temporal impact than other data. For example, sensor data 114 indicating the likelihood of an imminent collision by the transportation vehicle 120 is considered more important than sensor data 114 indicating the current fuel level state. Sensor data 114 indicating the road conditions for the next 300 feet is considered more important than the road conditions one mile ahead. One or more processors associated with the transportation vehicle 120 can make this determination. These one or more processors receive sensor data 114 from any combination of sensors 110, other transportation vehicles, satellites, and internal or external devices, classify the type and amount of the received data 114, and determine the importance based on the type and classification of the sensor data 114.

[0034] In one embodiment, the displayed sensor data 114 varies based on the eye position of the driver of the transportation vehicle or another passenger of the transportation vehicle. The transportation vehicle 120 includes an eye position sensor that detects when the driver or passenger is looking at the display 130 of the transportation vehicle or another location. For example, the transportation vehicle 120 determines that the driver is looking at the display 130 of the transportation vehicle and displays the sensor data 114 related to the driving state or navigation state. If the eye position sensor determines that the driver is not looking at the display 130 of the transportation vehicle, the display 130 of the transportation vehicle may instead be blanked to eliminate potential distraction. This advantageously provides the driver with safe and useful driving information when desired while minimizing the likelihood of driver distraction.

[0035] In one embodiment, when important data needs to be presented on the display 130 of the transportation vehicle, the data is displayed in an increasing fashion. In one embodiment, this increasing fashion continues until the eye sensor recognizes that the driver is looking at the display 130 of the transportation vehicle. The increasing fashion means increasing the font size, changing the color of the text, blinking the text, creating an audible sound, vibrating the steering wheel and / or the seat, etc., based on the importance of the sensor data 114. The importance of the sensor data 114 is determined in various ways. For example, the sensor data 114 used to reduce the injury of the occupants of the transportation vehicle or the damage of the transportation vehicle 120 (e.g., the sensor data 114 reporting that the transportation vehicle 120 is moving on a road opposite to the one-way sign) is considered important sensor data 114, while the sensor data 114 indicating that the radio station program does not reflect the current preference of the driver of the transportation vehicle is considered not important. It should be understood that only important sensor data 114 may be shown so as not to distract the driver. Initially, the sensor data 114 is simply displayed, but when the sensor does not indicate that the driver's eyes are looking at the display 130 of the transportation vehicle, one or more processors of the transportation vehicle 120 increase the attempt to notify the driver and / or the occupants. Visual and / or auditory warnings may be increased corresponding to the importance of the sensor data 114.

[0036] In one embodiment, the transportation vehicle 120 is stationary and not moving. The transportation vehicle 120 is parked, in a garage, unmanned, or stationary for some other reason. In some embodiments, the transportation vehicle 120 is stationary and not operating. While stationary, the transportation vehicle 120 can determine problems as described above. For example, the transportation vehicle 120 detects a tire pressure leak approaching a threshold tire pressure. In response, the transportation vehicle 120 provides a notification of the problem to a device associated with one or both of the transportation vehicle 120 or the owner of the transportation vehicle 120. The device includes, but is not limited to, a transportation vehicle computer, a transportation vehicle display 130 and / or a passenger device 156.

[0037] In one embodiment, the transportation vehicle 120 determines that the time 126 at which a problem occurs is earlier than the expected arrival time at the destination. In one embodiment, a driver or a passenger of the transportation vehicle may have entered or selected the destination into the navigation system of the transportation vehicle 120. In another embodiment, a driver or a passenger of the transportation vehicle may have given a voice command to the transportation vehicle 120 to identify the destination. In another embodiment, the transportation vehicle 120 may receive the destination from a source outside the transportation vehicle 120. After receiving the destination, the transportation vehicle 120 calculates the expected time to arrive at the destination from its current location. The transportation vehicle 120 compares the predicted time to arrive at the destination with the expected time 126 at which a problem occurs. If the expected time to arrive at the destination is before the time 126 at which a problem occurs, the transportation vehicle 120 displays both facts on one or more transportation vehicle displays 130 or on the passenger device 156, or sends a notification to a device corresponding to a repair facility or the owner of the transportation vehicle 120. If the expected time to arrive at the destination is after the time 126 at which a problem occurs, the transportation vehicle 120 provides a notification of the problem to a device associated with one or both of the transportation vehicle 120 or the owner of the transportation vehicle. In one embodiment, the transportation vehicle 120 proposes a route change of the transportation vehicle 120 to an entity (e.g., an open repair shop) that can address the problem rather than to the destination. The proposal is displayed on the transportation vehicle display 130, sent to one or more transportation vehicle passengers as an email or text message, sent as a call to a communication device, and / or presented as a voice notification to the transportation vehicle passengers. In one embodiment, the transportation vehicle 120 provides recommendations for mitigating the problem within a time frame prior to the time 126 at which the problem occurs. The recommendations are presented through any known means including those described above with respect to the proposal.

[0038] In one embodiment, the transportation vehicle 120 broadcasts an indication in response to the transportation vehicle 120 being operated contrary to the sensor data 114. For example, the sensor data 114 indicates that the transportation vehicle 120 is in good repair condition, the weather and road conditions are good, the traffic volume in the area is low and it is moving smoothly. If the transportation vehicle 120 is being operated with frequent and / or large speed changes and / or steering changes (i.e., hard steering or frequent lane changes), this may be a symptom of a driver having a problem such as a serious medical condition. In such a case, it is advantageous to broadcast to the emergency responders an indication of a possible medical condition occurring in the transportation vehicle 120 so that appropriate assistance can be directed to the transportation vehicle 120. In one embodiment, a computer of the transportation vehicle within the transportation vehicle 120 receives sensor data 114 indicating changes in steering, acceleration, and braking that are significantly different from what the driver of the transportation vehicle 120 normally does. In another embodiment, a voice control computer of the transportation vehicle 120 detects coughs and other sounds from the driver that are determined to be abnormal and identifies adverse medical conditions that may be occurring to the driver. The computer of the transportation vehicle or the voice control computer creates a notification to a communication processor within the transportation vehicle or to a communication device associated with the occupants of the transportation vehicle and then broadcasts the indication to the emergency responders. As another example, the sensor data 114 indicates stopped traffic in front of the transportation vehicle 120. If the transportation vehicle 120 does not start to decelerate, it is advantageous to provide an indication to the emergency responders to immediately mobilize the police, fire, EMS, or tow truck. In one case, the driver of the transportation vehicle 120 is asleep and does not notice the stopped traffic in front.

[0039] In another embodiment, the sensor data 114 includes a timestamp indicating when 112 the data was acquired. The timestamp reflects the time at which the sensor 110 generated the sensor data 114. The timestamp provides useful information that can identify current data, old data, or help order the data. In response to the sensor data 114 representing the same parameter or the same data type, data with a later timestamp is displayed. In one embodiment, only the sensor data 114 with a later timestamp is displayed. In some cases, the sensor data 114 with an older timestamp "ages out" and is ultimately replaced by newer data. For example, if it is useful to display a series of data points for a given parameter, such as the outside air temperature, the transportation vehicle 120 displays the most recent five temperature measurements. When a new temperature measurement is received from the sensor data 114. The oldest value among the number of data points displayed (e.g., five) is replaced by the new temperature measurement. This feature has the advantage of prioritizing sensor data 114 that is later or more recent than older sensor data 114, thereby presenting more accurate data on the display 130 of one or more transportation vehicles.

[0040] In another embodiment, the transportation vehicle 120 displays all of the received sensor data 114. While this may be acceptable for many applications, in applications where a large number of items of sensor data 114 are displayed, the display becomes cluttered and it becomes difficult to identify and understand the data. In particular, the driver of the transportation vehicle 120 can only glance at the vehicle's display 130 during operation so as not to take their eyes off the road or other transportation vehicles / objects in the vicinity of the transportation vehicle 120. This makes it difficult to identify important data items when the vehicle's display 130 is cluttered with many data objects. For this reason, it is advantageous to limit the sensor data 114 displayed to less than a threshold amount when combinations of various sensor data 114 exceed the threshold amount of data (where the threshold reflects the amount of data that can be identified or understood on the display 130). One or more processors associated with the transportation vehicle 120 determine the threshold. In one embodiment, the threshold is a predetermined value that reflects previous human factors research and analysis. In another embodiment, the threshold reflects a previous value corresponding to the total amount of data being displayed. In another embodiment, the threshold is a value input into the transportation vehicle 120 by an occupant of the transportation vehicle 120. In another embodiment, a stationary transportation vehicle 120 presents an increasing amount of sensor data 114 to the vehicle's occupants until the vehicle's occupants indicate that they are not perceiving the most recently displayed sensor data 114. In that case, the threshold corresponds to the amount of sensor data 114 displayed when the transportation vehicle 120 receives the indication or just prior thereto.

[0041] In one embodiment, the sensor data 114 causes the transportation vehicle 120 to change the operating parameters of the transportation vehicle. The operating parameters of the transportation vehicle may be changed autonomously when safety is not directly affected (for example, cruise control settings, headlight control, volume of the transportation vehicle, etc.). In addition, when safety is directly affected, the operating parameters of the transportation vehicle are proposed and approval by the passengers of the transportation vehicle 120 is required (i.e., not changed autonomously). In one embodiment, a computer associated with the transportation vehicle 120 (referred to as the transportation vehicle's computer) analyzes one or more data, and the transportation vehicle's computer initializes the change of the operating parameters of the transportation vehicle.

[0042] In one embodiment, the transportation vehicle 120 is included in a blockchain network, and the transportation vehicle 120 receives verification of one or more of the problem, the sensor data 114, the threshold value, and / or the time 126 when the problem occurs. The verification includes a blockchain consensus among a peer group consisting of the transportation vehicle 120 and one or more other transportation vehicles. In one embodiment, the transportation vehicle 120 executes a smart contract for recording the verification and the time 126 when the problem occurs on the blockchain based on the blockchain consensus.

[0043] In one possible use case of the present application, the transportation vehicle 120 detects that the tire pressure is approaching the threshold value at which a notification is issued. The actual video of the moving transportation vehicle 120 is focused on the tire and blinked / displayed. In another use case, the delta is inspected before / after the video / image sensor data 114 is presented. A notification indicating that the tire pressure has dropped, for example, from 34 psi to 25 psi, is associated with the transportation vehicle 120 / tire. The notification may also include a history. If the threshold value of the tire pressure is 30 psi and the current air pressure has dropped from 35 psi to 33 psi, the notification indicates that the tire will become a problem in a short time. In this case, the notification simply provides a warning.

[0044] In another possible use case for the present application, the history of tire pressure (such as received by tire sensor 110) indicates the severity of the problem. For example, the tire pressure was 36 psi a week ago and 32 psi four days ago, etc. Based on the history and timing, transportation institution 120 estimates that the threshold of tire pressure will be met tomorrow. Transportation institution 120 and the display 130 of the transportation institution inform the driver that the tire pressure is approaching or rapidly approaching the threshold. A similar scenario may also occur with hydraulic pressure, transmission temperature, fluid level, etc. This generates actual data when it occurs and generates one or more warnings if there is a problem estimated to occur soon.

[0045] In yet another possible use case for the present application, transportation institution 120 observes, as a new problem, that the wear of a particular tire is earlier than expected based on the received sensor data 114. Thereafter, transportation institution 120 determines the wear of other tires and recommends actions to correct the problem. Actions recommended to solve the problem include replacing the worn tire with a new tire, rotating / not rotating a particular tire, adjusting the tire pressure, or performing an alignment. The recommended actions are displayed on the display 130 of the transportation institution and otherwise communicated to the driver or passengers of transportation institution 120.

[0046] Figure 1B shows an exemplary view of a vehicle 150 of a transportation vehicle with further illustration of data display of the transportation vehicle. Figure 1B shows exemplary details of the interior 152 of a representative transportation vehicle, including a front view through the windshield, dashboard, and steering wheel. The transportation vehicle 120 includes a plurality of data displays 130 for providing data viewable by the driver and passengers of the transportation vehicle 120. The dashboard of the transportation vehicle includes a vehicle display 158 disposed generally centrally. The vehicle display 158 may be a monitor that only displays images and data. In other embodiments, the vehicle display 158 includes a touch screen or other functionality that enables data input and data manipulation in addition to data display. Data manipulation enables the movement, resizing, transposition, addition, or deletion of data by the passengers of the transportation vehicle 120. In some embodiments, the vehicle display 130 is an internal display permanently mounted and associated with the transportation vehicle 120. In other embodiments, the vehicle display 130 is a passenger device 156 that is removable from the transportation vehicle 120. A computer (not shown) attached to the transportation vehicle 120 executes code that processes received data and presents further data to be displayed on the vehicle display 130. In one embodiment, the transportation vehicle 120 receives sensor data 114 from one or more sensors 110 associated with the transportation vehicle 120. In another embodiment, the transportation vehicle 120 receives sensor data 114 from another transportation vehicle 162. In yet another embodiment, the transportation vehicle 120 receives sensor data 114 from one or more sensors 110 associated with the transportation vehicle 120 and receives sensor data 114 from another transportation vehicle 162.

[0047] The transportation agency 120 also includes one or more heads-up displays 160 of the transportation agency. The transportation agency 120 overlays the sensor data 114, or the time 126 when a problem occurs, with the observation image outside the transportation agency 120 including roads, traffic, etc., and displays the sensor data 114, the problem, or the time 126 when a problem occurs on the front glass or other transparent surface. The idea of the heads-up display 160 is to provide useful data to the driver without requiring the driver to take their eyes off the road or block the driver's field of vision. The transportation agency 160 independently or simultaneously displays the sensor data 114, or the time 126 when a problem occurs, on one or both of the transportation agency's display 158 and / or the heads-up display 160. For this reason, the sensor data 114 may be simultaneously displayed on the passenger's device 156, the transportation agency's display 158, and the heads-up display 160. The time 126 when a problem occurs may be simultaneously displayed on the passenger's device 156, the transportation agency's display 158, and the heads-up display 160. The computer of the transportation agency 120 may receive the sensor data 114 and / or the time 126 when a problem occurs and transmit additional data to the heads-up display 160.

[0048] Figure 2A shows a network diagram 200 of a transportation agency according to an exemplary embodiment. The network comprises elements including a transportation agency node 202 including a processor 204 and a transportation agency node 202' including a processor 204'. The transportation agency nodes 202, 202' communicate with each other via the processor 204, 204' and other elements (not shown) including a transceiver, a transmitter, a receiver, a storage, a sensor, and other elements capable of providing communication. The communication between the transportation agency nodes 202, 202' occurs directly via a private network and / or a public network (not shown) or via other transportation agency nodes and elements comprising one or more of a processor, a memory, and software. Although depicted as a single transportation agency node and a processor, there may be multiple transportation agency nodes and processors. One or more of the applications, features, steps, solutions, etc. described and / or depicted herein are utilized and / or provided by this element.

[0049] Figure 2B shows another network diagram 210 of a transportation agency according to an exemplary embodiment. The network comprises elements including a transportation agency node 202 including a processor 204 and a transportation agency node 202' including a processor 204'. The transportation agency nodes 202, 202' communicate with each other via the processor 204, 204' and other elements (not shown) including a transceiver, a transmitter, a receiver, a storage, a sensor, and other elements capable of providing communication. The communication between the transportation agency nodes 202, 202' occurs directly via a private network and / or a public network (not shown) or via other transportation agency nodes and elements comprising one or more of a processor, a memory, and software. The processors 204, 204' can further communicate with one or more elements 230 including a sensor 212, a wired device 214, a wireless device 216, a database 218, a mobile phone 220, a transportation agency node 222, a computer 224, an I / O device 226, and a voice application 228. The processors 204, 204' can further communicate with elements comprising one or more of a processor, a memory, and software.

[0050] Although a single transportation node, processor, and element are depicted, multiple transportation nodes, processors, and elements may exist. Information or communication occurs to and / or from any of processors 204, 204’ and element 230. For example, mobile phone 220 provides information to processor 204, which causes transportation node 202 to initiate an action, and further provides information or additional information to processor 204’, which causes transportation node 202’ to initiate an action, and further provides information or additional information to mobile phone 220, transportation node 222, and / or computer 224. One or more of the applications, features, steps, solutions, etc. described and / or depicted herein are utilized and / or provided by this element.

[0051] FIG. 2C shows yet another transportation network diagram 240 according to an exemplary embodiment. The network comprises an element including node 205 that includes processor 204 and non-transitory computer-readable medium 242C. Processor 204 is communicatively coupled to computer-readable medium 242C and element 230 (depicted in FIG. 2B). Node 205 is a transportation vehicle, server, or any device including a processor and memory.

[0052] Processor 204 performs one or more of determining in block 244C that a problem based on sensor data will soon occur in the transportation vehicle, determining in block 246C the time at which the problem occurs, and displaying in block 248C the time at which the problem occurs. In one embodiment, sensor data 114 is received from one or more sensors 110 associated with transportation vehicle 120. In another embodiment, sensor data 114 is received as sensor data from another transportation vehicle 162.

[0053] Figure 2D shows a further transportation network diagram 250 according to an exemplary embodiment. The network comprises elements including a node 205 that includes a processor 204 and a non-transitory computer-readable medium 242D. The processor 204 is communicatively coupled to the computer-readable medium 242D and an element 230 (depicted in Figure 2B). The node 205 can be a transportation vehicle, a server, or any device including a processor and a memory.

[0054] The processor 204 performs one or more of: determining one or more actions for problem solving in block 244D; selecting one action from the one or more actions in block 246D; displaying the action in block 248D; including in the sensor data a history of sensor data 114 approaching a threshold indicating that a problem will soon occur in block 250D; determining a problem in response to the transportation vehicle 120 being stationary and not operating in block 252D; and providing a notification of the problem to a device in block 254D. In one embodiment, the notification includes the time 126 at which the problem occurred. In one embodiment, the device includes devices associated with the transportation vehicle 120. In another embodiment, the device includes the passenger device 156. In another embodiment, the device includes devices associated with one or more other transportation vehicles 154.

[0055] Figure 2E shows a further transportation network diagram 260 according to an exemplary embodiment. Referring to Figure 2E, the network diagram 260 includes a node 205 connected to other transportation vehicle nodes 202’ and an update server node 203 on a blockchain network 206. The transportation vehicle nodes 202 and 202’ represent transportation vehicles. The blockchain network 206 has a ledger 208 for storing software update verification data and sources of verification for future use (e.g., for auditing).

[0056] In this example, only one node 205 is described in detail, but multiple such nodes may be connected to the blockchain 206. It should be understood that node 205 may include additional components and that some of the components described herein may be removed and / or modified without departing from the scope of the present application. Node 205 has a computing device or a server computer, etc., and includes a processor 204, and the processor 204 is a semiconductor-based microprocessor, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a 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 the present application. Node 205 is a transportation vehicle, a server, or any device including a processor and a memory.

[0057] The processor 204 performs one or more of receiving verification of a problem from the consensus of the transportation vehicle in block 244E and executing a smart contract for recording the verification and the time 126 at which the problem occurs by the transportation vehicle 120 on the blockchain in block 246E. In one embodiment, only one of the verification and the time 126 at which the problem occurs is stored on the blockchain. In another embodiment, both the verification and the time 126 at which the problem occurs are stored on the blockchain. In yet another embodiment, neither the verification nor the time 126 at which the problem occurs is stored on the blockchain. The verification includes a blockchain consensus among a peer group consisting of the transportation vehicle 120 and one or more other transportation vehicles.

[0058] The processor and / or computer-readable medium 242E is fully or partially present inside or outside the transportation node. The steps or functions stored in the computer-readable medium 242E are fully or partially executed by either the processor and / or elements in any order. Additionally, one or more steps or functions can be added, omitted, combined, executed at a later time, etc.

[0059] Figure 2F shows Figure 265 depicting the electrification of one or more elements. In one embodiment, the transportation vehicle 266 provides the power stored in its battery to one or more elements including other transportation vehicles 268, charging stations 270, and the electrical grid 272. The electrical grid 272 is coupled to one or more charging stations 270 coupled to one or more transportation vehicles 268. This configuration enables the distribution of electricity / power received from the transportation vehicle 266. Also, the transportation vehicle 266 interacts with other transportation vehicles 268 via communication such as vehicle-to-vehicle (V2V) technology, cellular, WiFi, etc. Further, the transportation vehicle 266 interacts with other transportation vehicles 268, charging stations 270, and / or the electrical grid 272 in a wireless and / or wired manner. In one embodiment, the transportation vehicle 266 is routed (or routes itself) to the electrical grid 272, the charging station 270, or other transportation vehicles 268 in a safe and efficient manner. Using one or more embodiments of this solution, the transportation vehicle 266 can provide energy to one or more of the elements described herein in various advantageous ways as described and / or depicted herein. Additionally, as described and / or depicted herein, the safety and efficiency of the transportation vehicle can be improved, and a positive impact on the environment can be achieved.

[0060] The term "energy" is used to denote any form of energy received, stored, used, shared and / or lost by a transportation vehicle. Energy is referred to in relation to a voltage source and / or a current source of electric charge provided from an entity to a transportation vehicle during a charging / usage operation. Also, energy is in the form of fossil fuels (for use in hybrid transportation vehicles), or, without limitation, alternative power sources including lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, nuclear fusion-based energy sources, and energy generated on-the-fly during an energy sharing and / or usage operation to increase or decrease the energy level of one or more transportation vehicles at a given point in time.

[0061] In one embodiment, the charging station 270 manages the amount of energy transferred from the transportation vehicle 266 such that sufficient charge remains in the transportation vehicle 266 to reach the destination. In one embodiment, a wireless connection is used to wirelessly instruct the amount of energy transfer between the transportation vehicles 268 both in operation. In one embodiment, a non-moving vehicle such as the vehicle 266 (which may be autonomous) is instructed to provide a predetermined amount of energy to the charging station 270 and return to its original location (e.g., the original location of the vehicle or another destination). In one embodiment, a movable energy storage unit (not shown) is used to collect surplus energy from at least one other transportation vehicle 268 and transfer the stored surplus energy to the charging station 270. In one embodiment, factors such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, the state of the vehicle (weight, etc.), the schedule of the passengers using the vehicle, the schedule of prospective passengers waiting for the vehicle, etc. determine the amount of energy transferred to the charging station 270. In one embodiment, the transportation vehicle 268, the charging station 270 and / or the electrical grid 272 can provide energy to the transportation vehicle 266.

[0062] In one embodiment, the solutions described and depicted herein can be utilized to determine the impact of a load on a transportation vehicle and / or system, provide energy to the transportation vehicle and / or system based on future needs and / or priorities, and provide intelligence between a device including modules and a vehicle, with the processor of the device being capable of communicating wirelessly with the vehicle regarding the amount of energy stored in a battery on the vehicle. In one embodiment, the solutions can also be utilized to provide a charge from a transportation vehicle to a location based on factors such as the temperature of the location, the cost of energy, and the power level of the location. In one embodiment, the solutions can also be utilized to manage the amount of energy remaining in a transportation vehicle after a portion of the charge has been transferred to a charging station. In one embodiment, the solutions can also be utilized to notify a vehicle to provide a predetermined amount of energy from a battery on the transportation vehicle, with the amount of energy transferred being based on the distance from the transportation vehicle to the module receiving the energy.

[0063] In one embodiment, a solution can also be utilized to use a movable energy storage unit, which travels to a transportation vehicle having surplus energy using a determined route and deposits the stored energy into the electrical grid. In one embodiment, a solution can also be utilized to determine the priority of the decision of the transportation vehicle in need of providing energy to the grid and the priority of the current needs of the transportation vehicle, such as the priority of passengers, next passengers, current cargo, or next cargo. In one embodiment, a solution can also be utilized to determine that when the vehicle is not moving, the vehicle moves to a location where it discharges surplus energy into the energy grid and then returns to the previous location. In one embodiment, based on one or more conditions such as weather, traffic, road conditions, vehicle conditions, and passengers and / or goods in another transportation vehicle, the amount of energy required by a transportation vehicle is determined to provide the required energy to another transportation vehicle via energy transfer from one transportation vehicle to another transportation vehicle, and a solution can also be utilized to route the transportation vehicle to another transportation vehicle to instruct it to provide energy. In one embodiment, a solution can also be utilized to transfer energy from one operating vehicle to another operating vehicle. In one embodiment, a solution can also be utilized to recover energy by a transportation vehicle based on the energy consumed by the transportation vehicle to reach a gathering place with another transportation vehicle and to provide a service and the expected energy consumption to return to the original location. In one embodiment, a solution can also be utilized to provide the remaining distance required to reach a charging station and to determine the amount of energy that should be recovered from the transportation vehicle by the charging station, and the remaining charge amount is based on the remaining distance. In one embodiment, a solution can also be utilized to manage a transportation vehicle that is simultaneously charged by a plurality of points at the same time, such as both a charging station via a wired connection and another transportation vehicle via a wireless connection.In one embodiment, a solution can also be utilized to prioritize the distribution of energy to a transportation vehicle, and the priority is given to the transportation vehicle that would provide a portion of the stored charge of the transportation vehicle to another entity such as the electric grid, a residence, etc. Further, the solution described and depicted with respect to FIG. 2F can be utilized in this and other networks and / or systems.

[0064] Figure 2G is Figure 275 showing the interconnections between various elements. This solution is stored on and / or executed in whole or in part by one or more computing devices 278’, 279’, 281’, 282’, 283’, 284’, 276’, 285’, 287’ and 277’ associated with various entities communicatively coupled to and communicating with network 286. Database 287 is communicatively coupled to the network, enabling storage and retrieval of data. In one embodiment, the database is an immutable ledger. One or more of the various entities are transportation agencies 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructures 282, one or more residences 283, an electrical grid / charging station 284, a microphone 285, and / or another transportation agency 277. Other entities and / or devices such as one or more individual users using smartphones 278, laptops 280 and / or wearable devices can also interact with this solution. Smartphones 278, laptops 280, microphones 285 and other devices are 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 include various institutions. One or more public buildings 281 utilize computing device 281’. One or more service providers 279 include dealers, tow truck services, collision centers or other repair shops. One or more service providers 279 utilize computing device 279’. These various computer devices are directly and / or communicatively coupled to each other via, for example, a wired network, a wireless network, a blockchain network, etc. Microphone 285 is utilized as a virtual assistant in one embodiment. In one embodiment, one or more transportation infrastructures 282 include one or more sensors including one or more traffic signals, one or more cameras, vehicle speed sensors or traffic sensors, and / or other transportation infrastructures.One or more transportation infrastructures 282 utilize a computing device 282'.

[0065] In one embodiment, the transportation means 277 / 276 can transport people, objects, permanently or temporarily attached devices, etc. In one embodiment, the transportation means 277 communicates with the transportation means 276 via V2V communication through the computers associated with each transportation means 276' and 277', and is referred to as a transportation means, a car, a vehicle, an automobile, etc. The transportation means 276 / 277 is a self-propelled wheeled transporter such as a car, a sports utility vehicle (SUV), a truck, a bus, a van, or other motor or battery-driven or fuel cell-driven transportation means. For example, the transportation means 276 / 277 is an electric vehicle, a hybrid vehicle, a hydrogen fuel cell vehicle, a plug-in hybrid vehicle, or other types of vehicles having a fuel cell stack, a motor and / or a generator. Other examples of vehicles include bicycles, scooters, trains, airplanes or boards, and other forms of transporters capable of transportation. The transportation means 276 / 277 may be semi-autonomous or autonomous. For example, the transportation means 276 / 277 can drive itself and navigate without human input. An autonomous vehicle has and uses one or more sensors and / or a navigation unit to drive autonomously.

[0066] In one embodiment, the solutions described and depicted herein can be utilized to determine access to a transportation vehicle via blockchain consensus. In one embodiment, the solutions can also be utilized to perform profile verification before permitting a passenger to use the transportation vehicle. In one embodiment, the solutions can also be utilized to cause the transportation vehicle to display (visually, verbally in another embodiment, etc.) an action (which may be pre-recorded) that the user needs to perform on or from the transportation vehicle and to verify that it is the correct action. In one embodiment, the solutions can also be utilized to determine how to branch data based on a risk level related to the data and the driving environment, distribute a portion of the branched data with a low risk level to the passenger in a safe driving environment, and then provide the transportation vehicle with the ability to distribute the remaining portion of the branched data with a high risk level after the passenger has departed from the transportation vehicle. In one embodiment, the solutions can also be utilized to handle the transfer of a vehicle across boundaries (such as countries, states, etc.) through the use of blockchain and / or smart contracts and apply the rules of the new area to the vehicle.

[0067] In one embodiment, a solution can also be utilized to enable the transportation vehicle to continue operating outside the boundary when a consensus is reached by the transportation vehicle based on the operation of the transportation vehicle and the characteristics of the occupants of the transportation vehicle. In one embodiment, a solution can also be utilized to analyze the available data upload / download speed of the transportation vehicle, the size of the file, and the speed / direction at which the transportation vehicle is traveling, determine the distance required to complete the data upload / download, and assign the boundaries of a secure area for the data upload / download to be executed. In one embodiment, for example, when the system determines that an exit is approaching or when the transportation vehicle does not appear to be ready to exit (e.g., is in an inappropriate lane or is traveling at an inappropriate speed to exit the approaching exit), a solution can also be utilized to perform normally dangerous operations in a safe manner and instruct the transportation vehicle of interest and other nearby transportation vehicles to enable the transportation vehicle of interest to exit in a safe manner. In one embodiment, a solution can also be utilized to verify the diagnosis of another transportation vehicle using one or more vehicles while both the one or more vehicles and the other transportation vehicles are operating.

[0068] In one embodiment, the solution can also be used to detect lane usage in terms of location and time of day, notify passengers of a transportation vehicle, or instruct the transportation vehicle to recommend or not recommend a lane change. In one embodiment, the solution can also be used to eliminate the need to send information via email and the need for the driver / passenger to respond by paying via email or directly. In one embodiment, the solution can also be used to provide services to passengers of a transportation vehicle, where the services provided are based on a subscription and the permission is obtained from other transportation vehicles connected to the passenger's profile. In one embodiment, the solution can also be used to record changes in the state of a rented object. In one embodiment, the solution can also be used to request a blockchain consensus from other transportation vehicles in the vicinity of a damaged transportation vehicle. In one embodiment, the solution can also be used to receive media from a server such as an insurance entity server and receive media from the computer of a transportation vehicle involved in an accident. The server accesses one or more media files to access the damage to the transportation vehicle and stores the damage assessment on the blockchain. In one embodiment, the solution can also be used to obtain a consensus from a number of devices over various times prior to an event related to a transportation vehicle to determine the severity of the event.

[0069] In one embodiment, the solution can also be used to solve the problem of insufficient video evidence regarding an accident involving a transportation vehicle. The current solution details that the transportation vehicle involved in the accident queries the media regarding the accident from other transportation vehicles that may have been in the vicinity of the accident. In one embodiment, the solution can also be used to record specific parts of a damaged transportation vehicle using the transportation vehicle and other devices (e.g., a pedestrian's mobile phone, streetlight camera, etc.).

[0070] In one embodiment, the solution can also be utilized to warn passengers when the transportation vehicle is navigating towards a dangerous area and / or event, and it becomes possible to notify passengers or a central controller of potentially dangerous areas on or near the current transportation vehicle route. In one embodiment, the solution can also be utilized to detect when the transportation vehicle is traveling at high speed, and at least one other transportation vehicle is used to assist in decelerating the transportation vehicle in a manner that minimizes the impact on traffic. In one embodiment, the solution can also be utilized to identify a dangerous driving situation in which a medium is captured by a vehicle involved in the dangerous driving situation. A geofence is established based on the distance of the dangerous 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 utilized to send a notification to one or more passengers of the transportation vehicle that the transportation vehicle is approaching a traffic control sign on the road, and then, if the transportation vehicle crosses the sign, to receive signs of poor driving from other nearby transportation vehicles. In one embodiment, (in one embodiment) the solution can also be utilized to partially disable the transportation vehicle by restricting speed, restricting the ability to approach another nearby vehicle, limiting the speed to a maximum value, and permitting only a given number of miles per hour.

[0071] In one embodiment, the solution can also be utilized to overcome the need to rely on software updates to correct problems with a transportation vehicle when the transportation vehicle is not operating correctly. Through the observation of other transportation vehicles on the route, the server will receive data from a plurality of other potentially transportation vehicles that observe unsafe or inaccurate operation of the transportation vehicle. Through analysis, these observations will result in a notification to the transportation vehicle when the data suggests unsafe or inaccurate operation. In one embodiment, the solution can also be utilized to provide a notification between the transportation vehicle and a person outside the transportation vehicle who is potentially involved in a dangerous situation. In one embodiment, the solution can also be utilized to transmit data to the server by either a device associated with an accident involving the transportation vehicle or a device in proximity to the accident. Based on the severity of the accident or a nearby accident, the server will notify the sender of the data. In one embodiment, the solution can also be utilized to provide recommendations for operating the transportation vehicle to either the driver or a passenger of the transportation vehicle based on the analysis of the data. In one embodiment, the solution can also be utilized to establish a geofence related to a physical structure and determine liability for payment to the transportation vehicle. In one embodiment, the solution can also be utilized to adjust the ability to drop off a vehicle at a location using both the current state at the location and a proposed future state using the navigation destination of other vehicles. In one embodiment, the solution can also be utilized to adjust the ability to automatically arrange for the drop off of a vehicle at a location such as a rental entity of the transportation vehicle.

[0072] In one embodiment, the solution can also be utilized to move a transportation vehicle to another location based on a user event. More specifically, the system tracks the user's device and modifies the transportation vehicle to move close to the user at the end of the original or modified event. In one embodiment, the solution can also be utilized to enable verification of available locations within an area through existing transportation vehicles within the area. The approximate time when a location will become available is also determined based on verification from existing transportation vehicles. In one embodiment, the solution can also be utilized to move the transportation vehicle close to a parking space when the parking space becomes available and the elapsed time from the first parking is shorter than the average time of the event. Further, when the event is completed or according to the location of the device associated with at least one passenger of the transportation vehicle, the transportation vehicle is moved to the final parking space. In one embodiment, the solution can also be utilized to plan parking before upcoming congestion. The system interacts with the transportation vehicle to provide some services at a price lower than the regular fare and / or to direct the transportation vehicle to an alternative parking location based on the priority of the transportation vehicle, enhancing the optimization of the pre-arrival parking situation.

[0073] In one embodiment, the solution can also be utilized to sell fractional ownership of a transportation vehicle or in price setting and availability determination in a ridesharing application. In one embodiment, the solution can also be utilized to provide accurate and timely reports of dealer sales activities far beyond what is currently available. In one embodiment, the solution can also be utilized to enable a dealer to claim an asset on the blockchain. By using the blockchain, consensus is obtained before the asset is transferred. Additionally, the process is automated and payments are initiated on the blockchain. In one embodiment, the solution can also be utilized to orchestrate agreements made with multiple entities (such as a service center) where consensus is obtained and actions (such as a diagnosis) are performed. In one embodiment, the solution can also be utilized to associate digital keys with multiple users. The first user is an operator of a transportation vehicle and the second user is a responsible person for the transportation vehicle. These keys are authenticated by a server where the proximity of the keys is verified against the location of the service provider. In one embodiment, the solution can also be utilized to determine the required services at the destination of a transportation vehicle. One or more service bases are provided that are within the area along the route to the destination and have the availability to perform the required services. The navigation of the transportation vehicle is updated using the determined service bases. A smart contract including a reward value for the service is identified and a blockchain transaction is stored in the distributed ledger of the transaction.

[0074] In one embodiment, the solution can also be utilized to interact the service provider's transportation vehicle with the profile of the vehicle's passengers to determine services and goods that the vehicle's passengers may be interested in. These services and goods are determined by the passengers' history and / or preferences. The transportation vehicle then receives an offer from the service provider's transportation vehicle and meets with the transportation vehicle to provide the service / goods in another embodiment. In one embodiment, the solution can also be utilized to detect transportation vehicles within a predetermined range and send service offers (e.g., maintenance offers, product offers, etc.) to the transportation vehicles. An agreement is made between the system and the transportation vehicle, and the service provider is selected by the system to provide the agreement. In one embodiment, the solution can also be utilized to assign one or more transportation vehicles as road administrators, and the road administrators assist in traffic control. The road administrators generate road indicators (such as lights, displays, sounds) to assist in the traffic flow. In one embodiment, the solution can also be utilized to warn the driver of the transportation vehicle by a device, and the device is a traffic signal or is present near an intersection. A warning is sent when an event occurs, such as when the signal turns green and the transportation vehicle in front of the transportation vehicle list does not move.

[0075] Figure 2H is, in one example, another block diagram 290 showing the interconnections between different elements. A transportation vehicle 276 is presented and includes ECUs 295, 296 and a head unit (otherwise known as an infotainment system) 297. An electronic control unit (ECU) is an embedded system in automotive electronics that controls one or more of the electrical systems or subsystems in a transportation vehicle. The ECU includes, but is not limited to, management of the transportation vehicle's engine, braking system, gearbox system, door locks, dashboard, airbag system, infotainment system, electronic differential and active suspension. The ECU is connected to the transportation vehicle's Controller Area Network (CAN) bus 294. Also, the ECU communicates with the transportation vehicle's computer 298 via the CAN bus 294. The transportation vehicle's processor / sensor 298 (e.g., the transportation vehicle's computer) can communicate with external elements such as a server 293 via a network 292 (e.g., the Internet). Each ECU 295, 296 and head unit 297 includes its own security policy. The security policy defines allowable processes that are executable in an appropriate context. In one embodiment, the security policy is provided, in part or in whole, on the transportation vehicle's computer 298.

[0076] ECUs 295, 296, and the head unit 297 each include a custom security functional element 299 that defines an authenticated process and the context in which the operation of these processes is permitted. Context-based authentication to determine the validity of whether a process is executable enables the ECU to maintain secure operation and prevent unauthorized access from elements such as the vehicle's controller area network (CAN bus). If the ECU encounters an unauthorized process, the ECU can block the operation of that process. The vehicle's ECU can use various contexts, such as proximity contexts like nearby objects, distance to approaching objects, speed, and trajectory relative to other moving objects, signs of whether the vehicle is moving or parked, the current speed of the vehicle, operation contexts like the state of the transmission, devices connected to the vehicle via a wireless protocol, user-related contexts like the use of infotainment, cruise control, parking assistance, driving assistance, location-based context, and / or other contexts, to determine whether a process is operating within its permitted range.

[0077] In one embodiment, the solutions described and depicted herein can be utilized to partially disable a transportation vehicle by, in one embodiment, limiting speed, limiting the ability to approach another nearby vehicle, limiting speed to a maximum value, and permitting only a given number of miles per hour. In one embodiment, the solutions can also be utilized to facilitate the exchange of vehicle ownership using a blockchain, where data is sent to a server by either a device associated with an accident involving a transportation vehicle or a device in proximity to an accident. Based on the severity of the accident or nearby accident, the server notifies the sender of the data. In one embodiment, the solutions can also be utilized to assist a transportation vehicle in avoiding an accident by the server, for example when the transportation vehicle is involved in an accident, and the server queries other transportation vehicles in proximity to the accident. The server attempts to obtain data from the other transportation vehicles, enabling the server to understand the nature of the accident from multiple advantageous locations. In one embodiment, the solutions can also be utilized to determine that a sound from a transportation vehicle is atypical and send data regarding the sound and the location of the possible sound source to the server, where the server can determine the possible cause and avoid potentially dangerous situations. In one embodiment, the solutions can also be utilized to establish the boundaries of a location via a system when a transportation vehicle is involved in an accident. This boundary is based on decibels associated with the accident. Multimedia content regarding devices within the boundary is obtained to assist in further understanding the accident scenario. In one embodiment, the solutions can also be utilized to associate a vehicle with an accident and then capture media obtained by a device in proximity to the location of the accident. The captured media is stored as a media segment. The media segment is sent to another computing device that constructs an audio profile of the accident. This audio profile will assist in understanding the details surrounding the accident.

[0078] In one embodiment, a solution can be utilized to record an area where a potential event has occurred, such as when a transportation vehicle comes into contact or has the potential to come into contact with another transportation vehicle (while moving or parked), using sensors that record audio, video, movement, etc. The system captures data from sensors present on one or more of the transportation vehicle and / or fixed or moving objects. In one embodiment, a solution can also be utilized to identify a new state of the transportation vehicle during an event of the transportation vehicle using sensor data and compare that state to the state profile of the transportation vehicle to determine that the transportation vehicle has been damaged, thereby enabling important data to be securely and safely captured from a transportation vehicle that is about to engage in a harmful event.

[0079] In one embodiment, a solution can also be utilized to warn the passengers of a transportation vehicle when the transportation vehicle determines, via one or more sensors, that it is approaching or driving down a one-way road in the wrong direction. The transportation vehicle has sensors / cameras / maps that interact with the system of this solution. The system knows the geographical location of the one-way street. The system can, for example, audibly inform the passengers that "You are approaching a one-way street". In one embodiment, a solution can also be utilized to enable a transportation vehicle to receive payment, thereby enabling the owners of autonomous vehicles to monetize the data collected and stored by their vehicle sensors, creating an incentive for vehicle owners to share their data, providing additional data to entities to improve the performance of future vehicles, and providing services to vehicle owners, etc.

[0080] In one embodiment, the solution can also be utilized to increase or decrease the vehicle's functions according to the vehicle's actions over a certain period of time. In one embodiment, the solution can also be utilized to assign fractional ownership to a transportation agency. Sensor data regarding one or more transportation agencies and devices proximate to the transportation agencies is used to determine the state of the transportation agencies. The fractional ownership of the transportation agencies is determined based on the state, and new responsibilities for the transportation agencies are provided. In one embodiment, the solution can also be utilized to provide data to an exchange / attachment component, where the data attempts to disrupt the authenticated functions of the exchange / attachment component and, in response to non-disruption of the authenticated functions, the use of the authenticated functions of the exchange / attachment component by the component is permitted.

[0081] In one embodiment, the solution can also be utilized to provide an individual with the ability to ensure that a passenger is within a transportation agency and that the passenger reaches a specific destination. Further, the system ensures that the driver (in the case of a non-autonomous transportation agency) and / or other passengers are authenticated to interact with the passenger. Also, pick-up, drop-off, and locations are noted. All of the above are stored in an immutable form on a blockchain. In one embodiment, the solution can also be utilized to determine driver characteristics through analysis of driving style and other factors and to take action when the driver is not driving in a normal manner, such as the manner in which the driver has previously driven in certain conditions, e.g., during the day, at night, in the rain, in the snow, etc. Further, the attributes of the transportation agency are also considered. The attributes consist of weather, whether the headlights are on, whether navigation is being used, whether the HUD is being used, the volume of the media being played, etc. In one embodiment, the solution can also be utilized to notify the passengers of a transportation agency of a dangerous situation when items within the transportation agency indicate that the passengers may not be aware of the dangerous situation.

[0082] In one embodiment, the solution can also be used to attach a calibration device to a rig fixed to a vehicle, and various sensors on the transportation vehicle can automatically self-adjust based on what should be detected by the calibration device when compared to what is actually detected. In one embodiment, the solution can also be used to require consensus from multiple service centers using a blockchain when a transportation vehicle in need of service sends failure information that permits remote diagnostic capabilities, and consensus from other service centers is required as to what the critical threshold for the data is. When the consensus is received, the service center sends the security level of the failure to be stored to the blockchain. In one embodiment, the solution can also be used to determine the difference between sensor data external to the transportation vehicle and sensor data of the transportation vehicle itself. The transportation vehicle requests software from the server to correct the problem. In one embodiment, the solution can also be used to enable messaging of transportation vehicles in the vicinity or within the area when an event (e.g., a collision) occurs.

[0083] Referring to FIG. 2I, an operating environment 290A for a connected transportation vehicle according to some embodiments is shown. As depicted, the transportation vehicle 276 includes a controller area network (CAN) bus 291A that connects elements 292A - 299A of the transportation vehicle. Other elements may be connected to the CAN bus but are not depicted herein. The depicted elements connected to the CAN bus include a sensor set 292A, an electronic control unit 293A, an autonomous function or advanced driver assistance system (ADAS) 294A, and a navigation system 295A. In some embodiments, the transportation vehicle 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

[0084] Processor 296A includes an arithmetic logic unit, a microprocessor, a general-purpose controller, and / or a similar processor array for executing operations to provide an electronic display signal to display unit 299A. Processor 296A includes various computing architectures that process data signals and implement a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. Transportation vehicle 276 includes one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not shown) communicatively coupled to each other may be used with this solution.

[0085] Memory 297A is a non-transitory memory that stores instructions or data accessed and executed by processor 296A. The instructions and / or data include code for performing the techniques described herein. Memory 297A is a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory, or some other memory device. In some embodiments, memory 297A also includes a non-volatile memory or similar permanent storage device and media including a hard disk drive, a floppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device, a DVD-RW device, a flash memory device, or some other mass storage device for permanently storing information. A portion of memory 297A may be reserved for use as a buffer or virtual random access memory (virtual RAM). The transportation vehicle can include one or more memories 297A without departing from the current solution.

[0086] The memory 297A of the transport mechanism 276 stores one or more types of data such as the navigation route data 295A and the autonomous function data 294A. In some embodiments, the memory 297A stores the data necessary for the navigation application 295A to provide functions.

[0087] The navigation system 295A describes at least one navigation route including a starting point and an ending point. In some embodiments, the navigation system 295A of the transport mechanism 276 receives a request from the user regarding the navigation route, and the request includes a starting point and an ending point. The navigation system 295A can inquire (via the network 292) of a real-time data server 293 such as a server that provides a driving direction about the navigation route data corresponding to the navigation route including the starting point and the ending point. The real-time data server 293 transmits the navigation route data to the transport mechanism 276 via the wireless network 292, and the communication system 298A stores the navigation data 295A in the memory 297A of the transport mechanism 276.

[0088] The ECU 293A controls the operations of many systems of the transport mechanism 276 including the ADAS system 294A. In response to an instruction received from the navigation system 295A, the ECU 293A disables non-safe and / or unselected autonomous functions during the journey controlled by the ADAS system 294A. In this way, the navigation system 295A controls whether the ADAS system 294A is activated or enabled so that the ADAS system 294A is activated for a given navigation route.

[0089] Sensor set 292A includes any sensors within the transportation vehicle 276 that generate sensor data. For example, sensor set 292A includes short-range sensors and long-range sensors. In some embodiments, the sensor set 292A of transportation vehicle 276 includes the following vehicle sensors, namely, cameras, LIDAR sensors, ultrasonic sensors, automotive engine sensors, radar sensors, laser photometers, manifold absolute pressure sensors, infrared detectors, motion detectors, thermostats, sound detectors, carbon monoxide sensors, carbon dioxide sensors, oxygen sensors, air flow sensors, engine coolant temperature sensors, throttle position sensors, crankshaft position sensors, valve timers, air-fuel ratio meters, blind spot meters, curb feelers, defect detectors, Hall effect sensors, parking sensors, radar guns, speedometers, speed sensors, tire pressure monitoring sensors, torque sensors, transmission fluid temperature sensors, turbine speed sensors (TSS), variable reluctance sensors, vehicle speed sensors (VSS), water sensors, wheel speed sensors, GPS sensors, mapping functions, and one or more of other types of automotive sensors. Navigation system 295A stores the sensor data in memory 297A.

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

[0091] The transport mechanism 276 can communicate with other transport mechanisms 277 via V2V technology. In one embodiment, V2V communication includes sensing radar information corresponding to the relative distance from an external object, receiving the GPS information of the transport mechanism, setting an area as the area where the other transport mechanism 277 is located based on the sensed radar information, calculating the probability that the GPS information of the target vehicle is located in the set area, and identifying the transport mechanism and / or object corresponding to the radar information and the GPS information of the target vehicle based on the calculated probability.

[0092] In one embodiment, the solutions described and depicted herein can also be utilized to manage emergency scenarios and the functions of a transport mechanism when it is determined that the transport mechanism has entered an area without network access. In one embodiment, the solutions can be utilized to manage and provide the functions (such as audio, video, navigation, etc.) of a transport mechanism without a network connection. In one embodiment, the solutions can be utilized to determine when the profile of a person in proximity to the transport mechanism matches the profile attributes of the profile of at least one passenger within the transport mechanism. A notification is sent from the transport mechanism to establish communication.

[0093] In one embodiment, the solutions can also be utilized to analyze the availability of passengers in each transport mechanism available for voice communication based on the remaining time in the transport mechanism and the context of the communication to be executed. In one embodiment, the solutions can be utilized to determine two levels of threat of road obstacles, receive gestures indicating that the obstacle has not risen above a threshold warning, and proceed along the road by the transport mechanism. In one embodiment, the solutions can be utilized to delete confidential data from the transport mechanism when the transport mechanism has suffered damage such that it becomes inoperable.

[0094] In one embodiment, the solution can also be utilized to verify that customer data to be deleted has actually been deleted from all necessary locations within the company demonstrating GDPR compliance. In one embodiment, the solution can also be utilized to provide consideration from one transportation agency to another in exchange for data related to safety to enhance the autonomous capabilities of low-level autonomous vehicles, important notifications, etc. In one embodiment, the solution can also be utilized to provide the transportation agency with the ability to receive data based on a first biometric related to a passenger. Thereafter, the transportation agency decrypts the encrypted data based on the verification of a second biometric, and the second biometric is a continuum of the first biometric. The transportation agency provides the unencrypted data to the passenger only when the unencrypted data can be received by the passenger, deletes the confidential portion of the unencrypted data when the confidential portion is provided, and deletes the non-confidential portion after the time related to the biometric has elapsed. In one embodiment, the solution can also be utilized to provide the transportation agency with the ability to authenticate an individual based on the weight and grip applied to the steering wheel of the transportation vehicle. In one embodiment, the solution can also be utilized to provide the vehicle with features that exist but are not currently activated and present features reflecting the characteristics of the vehicle's passengers to the passengers of the vehicle.

[0095] In one embodiment, the solution can also be used to modify a transportation vehicle to assist in reflecting and assisting at least one passenger, in particular to enable changes inside and outside the transportation vehicle. In another embodiment, it is disclosed to reproduce the work environment and / or home environment of the passenger. When the system determines that the user is in "work mode" or "home mode", the system attempts to "reproduce" the user's work environment / home environment while the user is inside the transportation vehicle. All data regarding the inside and outside of the transportation vehicle and the various passengers using the transportation vehicle is stored on the blockchain and executed via a smart contract. In one embodiment, the solution can also be used to detect the passenger's gestures to assist in communicating with nearby transportation vehicles that the transportation vehicle can accordingly pilot. In one embodiment, the solution can also be used to provide the transportation vehicle with the ability to detect the intended gesture using a gesture definition data store. In one embodiment, the solution can also be used to provide the transportation vehicle with the ability to take various actions based on the user's walking style and gestures. In one embodiment, the solution can also be used to ensure that the driver of the transportation vehicle, who is currently engaged in various operations (such as driving while conversing with navigation), does not exceed a non-safe number of operations before a gesture is permitted.

[0096] In one embodiment, the solution can also be used to assign a status to each occupant within a transportation vehicle and verify gestures from the occupants based on the occupant's status. In one embodiment, the solution can also be used to provide a system that collects details about sounds related to a collision (where, in which direction, rising or falling, from which device, data related to the device such as type, manufacturer, owner, and the number of sounds occurring simultaneously, the time when the sound was emitted, etc.) and assists in determining details about the collision through data analysis. In one embodiment, the solution can also be used to provide a determination that the operation of a transportation vehicle is not safe. A transportation vehicle includes a plurality of components that interact to control the transportation vehicle, and each component is associated with a separate component key. An encryption key is sent to the transportation vehicle to degrade the functionality of the transportation vehicle. In response to receiving the encryption key, the transportation vehicle disables one or more of the component keys. Disabling one or more component keys results in one or more of restricting the transportation vehicle from moving faster than a given speed, restricting the transportation vehicle from getting closer to another transportation vehicle than a predetermined distance, and restricting the transportation vehicle from moving more than a threshold distance.

[0097] In one embodiment, the solution can also be used to provide an instruction from one particular transportation vehicle (trying to vacate a location) to another particular transportation vehicle (trying to occupy the location), and a blockchain is used to perform authentication and coordination. In one embodiment, the solution can also be used to determine partial liability for a transportation vehicle. For example, if multiple people own a transportation vehicle, the changing usage of the transportation vehicle over time is used by the system to update partial ownership. Other embodiments including a minimal ownership of the transportation vehicle based on the availability of the transportation vehicle rather than its usage, and the determination of the driver of the transportation vehicle and others will be included in the present application.

[0098] In one embodiment, the solution can also be used to allow a user in a transportation service to subscribe with a closed group of people such as family or friends. For example, a user may want to share membership, in which case the associated transactions are stored in a blockchain or a conventional database. When a user who is not the main subscriber requests subscribed materials, the blockchain node (i.e., the transportation service) can verify that the person requesting the service is an approved person with whom the subscriber has shared a profile. In one embodiment, the solution can also be used to enable a person to use an auxiliary transportation service to reach an intended destination. Functional relationship values (e.g., various parameters and their importance values in determining which type of alternative transportation service to use) are used in determining the auxiliary transportation service. In one embodiment, the solution can also be used to enable passengers in an accident to access another transportation service to continue to their original destination.

[0099] In one embodiment, the solution can also be utilized to propagate software / firmware uploads to a first subset of transportation vehicles. This first set of transportation vehicles tests the update, and upon successful testing, the update is propagated to a further set of transportation vehicles. In one embodiment, the solution can also be utilized to propagate software / firmware updates from a master transportation vehicle to a vehicle, in which case the update is propagated from the first subset through the vehicle's network and then to a larger subset, etc. A portion of the update is sent first, and then the remainder is sent from the same or another vehicle. In one embodiment, the solution can also be utilized to provide updates for the transportation vehicle's computer to the transportation vehicle and the devices of the transportation vehicle's operator / passengers. The update may be approved by all drivers and / or all passengers. Software updates are provided to the vehicle and the devices. The user does not need to do anything and simply approaches the vehicle, and the functionality occurs automatically. A notification indicating that the software update is complete is sent to the device. In one embodiment, the solution can also be utilized to verify that an OTA software update has been executed by a qualified technician, the originator of the verification code, the procedure for wirelessly receiving the software update, the information included in the software update, and the generation of status by one or more transportation vehicle components regarding the result of the verification.

[0100] In one embodiment, the solution can also be utilized to provide the ability to analyze software updates in a first component by a second component. Then, a first part of a critical update and a second part of a non-critical update are verified, the verified first part is assigned to one process in a transportation vehicle, the verified first part is operated in one process for a predetermined period, and after the predetermined period, the verified first part is operated in another process in response to a positive result based on the predetermined period. In one embodiment, the solution can also be utilized to provide a choice of services to passengers, and the services are based on the profile of the passengers of the transportation vehicle and a shared profile shared with the profile of the passengers. In one embodiment, the solution can also be utilized to store user profile data in a blockchain and intelligently present offers and recommendations to a user based on the automatically collected purchase history and preferences of the user obtained from the user profile on the blockchain.

[0101] To properly protect a transportation vehicle, the transportation vehicle must be protected from not only unauthorized physical access but also unauthorized remote access (e.g., cyber threats). In one embodiment, to prevent unauthorized physical access, the transportation vehicle is equipped with a secure access system such as keyless entry. On the other hand, in one embodiment, to facilitate secure remote communication with the transportation vehicle, security protocols are added to the computers and computer networks of the transportation vehicle.

[0102] An electronic control unit (ECU) is a node within a transportation vehicle that controls tasks ranging from tasks such as the operation of the windshield wipers to tasks such as the antilock braking system. ECUs are often connected to each other through a central network of the transportation vehicle called a controller area network (CAN). State-of-the-art features such as autonomous driving strongly rely on new and complex ECU implementations such as advanced driver assistance systems (ADAS), sensors, etc. These new technologies have helped improve the safety and driving experience of transportation vehicles, but have increased the number of external communication units within the transportation vehicle and made the external communication units more vulnerable to attacks. The following are some examples of protecting transportation vehicles from physical and remote intrusions.

[0103] FIG. 2J shows a keyless entry system 290B for preventing unauthorized physical access to a transportation vehicle 291B according to an exemplary embodiment. Referring to FIG. 2J, in one embodiment, a key fob 292B transmits commands to the transportation vehicle 291B using a radio frequency signal. In this example, the key fob 292B includes a transmitter 2921B having an antenna capable of transmitting a short-range wireless signal. The transportation vehicle 291B includes a receiver 2911B having an antenna capable of receiving the short-range wireless signal transmitted from the transmitter 2921B. The key fob 292B and the transportation vehicle 291B also each include CPUs 2922B and 2913B that control their respective devices. Here, there is memory for the CPUs 2922B and 2913B (or accessible to the CPU). In one embodiment, each of the key fob 292B and the transportation vehicle 291B includes a power source 2924B and 2915B for powering their respective devices.

[0104] When the user presses a button 293B on the key fob 292B (or activates the fob otherwise), the CPU 2922B starts up within the key fob 292B and transmits a data stream output via the antenna to the transmitter 2921B. The data stream is a signal with a length of 64 bits to 128 bits, including one or more of a preamble, a command code, and a rolling code. The signal is transmitted at a speed between 2KHz and 20KHz, but the embodiment is not limited to this. In response, the receiver 2911B of the transportation device 291B captures the signal from the transmitter 2921B, demodulates the signal, transmits the data stream to the CPU 2913B, and the CPU 2913B decodes the signal and transmits a command (e.g., door lock, door unlock, etc.) to the command module 2912B.

[0105] If the key fob 292B and the transportation device 291B use a fixed code between them, a replay attack becomes possible. In this case, if an attacker can capture / eavesdrop on the fixed code during short-range communication, the attacker can replay this code to penetrate the transportation device 291B. To improve security, the key fob and the transportation device 291B can use a rolling code that changes each time it is used. Here, the key fob 292B and the transportation device 291B are synchronized with an initial seed 2923B (e.g., a random number, a pseudo-random number, etc.). This is called pairing. The key fob 292B and the transportation device 291B also include a shared algorithm for modifying the initial seed 2914B each time the button 293B is pressed. The next key press receives the result of the previous key press as input and converts it into the next number in the sequence. In some cases, the transportation device 291B can store a plurality of next codes (e.g., 255 next codes) in case the key presses on the key fob 292B are not detected by the transportation device 291B. For this reason, a large number of key presses on the key fob 292B that are inaudible to the transportation device 291B do not prevent the transportation device from getting out of sync.

[0106] In addition to the rolling code, the key fob 292B and the transport mechanism 291B may employ other methods to make attacks even more difficult. For example, various frequencies can be used to transmit the rolling code. As another example, two-way communication between the transmitter 2921B and the receiver 2911B may be used to establish a secure session. As another example, the code may have an expiration date or a timeout. Further, the solution described and depicted with respect to FIG. 2J can be utilized in this network and in other networks and / or systems including those described and depicted herein.

[0107] FIG. 2K shows a Controller Area Network (CAN) 290C within a transport mechanism, according to an exemplary embodiment. Referring to FIG. 2K, the CAN 290C includes a CAN bus 297C having a high terminal and a low terminal, and a plurality of electronic control units (ECUs) 291C, 292C, 293C, etc. connected to the CAN bus 297C via a wired connection. The CAN bus 297C is designed to enable microcontrollers and devices to communicate with each other in an application that does not have a host computer. The CAN bus 297C implements a message-based protocol (i.e., ISO 11898 standard) that enables the ECUs 291C - 293C to send commands to each other at the root level. On the other hand, the ECUs 291C - 293C represent controllers for controlling electrical systems or subsystems within the transport mechanism. Examples of electrical systems include power steering, antilock brakes, air conditioning, tire pressure monitoring, cruise control, and many other functions.

[0108] In this example, ECU291C includes transceiver 2911C and microcontroller 2912C. The transceiver is used to transmit messages to CAN bus 297C and receive messages from CAN bus 297C. For example, transceiver 2911C converts data from microcontroller 2912C into the format of CAN bus 297C and converts data from CAN bus 297C into the format for microcontroller 2912C. On the other hand, in one embodiment, microcontroller 2912C interprets messages and determines which messages to transmit using the ECU software installed in microcontroller 2912C.

[0109] To protect CAN290C from cyber threats, various security protocols can be implemented. For example, sub-networks (such as sub-network A and B, etc.) can be used to divide CAN290C into smaller sub-CANs, limiting the ability of attackers accessing the transportation institution remotely. In the example of Figure 2K, ECU291C and 292C are part of the same sub-network, and ECU293C is part of an independent sub-network. Further, a firewall 294C (or gateway, etc.) can be added to block messages from crossing CAN bus 297C across sub-networks. When an attacker accesses one sub-network, the attacker cannot access the entire network. In one embodiment, to make the sub-network more secure, the most important ECUs are not placed on the same sub-network.

[0110] Although not shown in FIG. 2K, other examples of security control within the CAN include an intrusion detection system (IDS) that is added to each subnetwork and can read all passing data to detect malicious messages. When a malicious message is detected, the IDS can notify the vehicle's user. Other possible security protocols include encryption / security keys used to make messages invisible. As another example, in one embodiment, an authentication protocol is implemented that allows a message to authenticate itself.

[0111] In addition to protecting the internal network of a transportation agency, the transportation agency can also be protected when communicating with an external network such as the Internet. One advantage of connecting a transportation agency to a data source such as the Internet is that information from the transportation agency can be transmitted remotely through the network for analysis. Examples of transportation agency information include GPS, on-board diagnostics, tire pressure, etc. Since these communication systems include a combination of telecommunications and informatics, they are often referred to as telematics. Furthermore, the present solution as described and depicted with respect to FIG. 2K can be utilized in this network, as well as other networks and / or systems including those described and depicted herein.

[0112] Figure 2L shows a secure end-to-end transport vehicle communication channel according to an exemplary embodiment. Referring to Figure 2L, the telematics network 290D includes a transport vehicle 291D and a host server 295D that is located at a remote location (such as a web server, cloud platform, database, etc.) and is connected to the transport vehicle 291D via a network such as the Internet. In this example, a device 296D associated with the host server 295D is installed within the network in the transport vehicle 291D. Further, although not shown, the device 296D may be connected to other elements of the transport vehicle 291D such as a CAN bus, an on-board diagnostic (ODBII) port, a GPS system, a SIM card, a modem, etc. The device 296D collects data from any of these systems and transmits the data to the server 295D via the network.

[0113] Secure management of the data begins at the transport vehicle 291D. In some embodiments, the device 296D collects information before, during, and after a trip. The data includes GPS data, driving data, passenger information, diagnostic data, fuel data, speed data, etc. However, the device 296D can return the collected information to the host server 295D only in response to the ignition of the transport vehicle and the completion of the trip. Further, the communication may be initiated only by the device 296D and not by the host server 295D. Thus, in one embodiment, the device 296D does not accept communications initiated by an external source.

[0114] To perform communication, device 296D can establish a secure private network between device 296D and host server 295D. Here, device 296D includes an anti-tampering SIM card that provides secure access to carrier network 294D via radio tower 292D. When preparing to send data to host server 295D, device 296D establishes a one-way secure connection with host server 295D. Carrier network 294D communicates with host server 295D using one or more security protocols. As a non-limiting example, carrier network 294D communicates with host server 295D via a VPN tunnel that enables access through host server 295D's firewall 293D. As another example, carrier network 294D uses data encryption (such as AES encryption, etc.) when sending data to host server 295D. In some cases, the system can use multiple security means such as both VPN and encryption to further secure the data.

[0115] In addition to communicating with external servers, transportation agencies can also communicate with each other. In particular, a vehicle-to-vehicle (V2V) communication system enables transportation agencies to communicate with each other and with roadside infrastructure (such as traffic lights, signs, cameras, parking meters, etc.) via a wireless network. The wireless network includes one or more of a WiFi network, a cellular network, a dedicated short-range communication (DSRC) network, etc. Transportation agencies use V2V communication to provide information about a transportation agency's speed, acceleration, braking, and direction, etc. to other transportation agencies. Thus, transportation agencies can grasp such situations before they become visible, and thus can significantly reduce collisions. Further, the solution described and depicted with respect to FIG. 2L can be utilized in this network and in other networks and / or systems described and depicted herein.

[0116] FIG. 2M shows an example 290E of transport vehicles 293E and 292E that perform secure V2V communication using a security certificate according to an exemplary embodiment. Referring to FIG. 2M, transport vehicles 293E and 292E communicate with each other through V2V communication via a short-range network, a cellular network, etc. Before sending a message, transport vehicles 293E and 292E sign the message using their respective public key certificates. For example, transport vehicle 293E signs the V2V message using public key certificate 294E. Similarly, transport vehicle 292E signs the V2V message using public key certificate 295E. In one embodiment, public key certificates 294E and 295E are associated with transport vehicles 293E and 292E, respectively.

[0117] When receiving communication from each other, the transport vehicle verifies the signature using a certification authority 291E or the like. For example, transport vehicle 292E uses certification authority 291E to verify that public key certificate 294E used by transport vehicle 293E to sign the V2V communication is genuine. If transport vehicle 292E successfully verifies public key certificate 294E, the transport vehicle knows that the data is from a legitimate source. Similarly, transport vehicle 293E uses certification authority 291E to verify that public key certificate 295E used by transport vehicle 292E to sign the V2V communication is genuine. Further, the solution as described and depicted with respect to FIG. 2M can be utilized in this network, as well as in other networks and / or systems including those described and depicted herein.

[0118] FIG. 3A shows a flowchart 300 according to an exemplary embodiment. Referring to FIG. 3A, the transport vehicle determines 302 that a problem based on sensor data 114 will soon occur in the transport vehicle, determines 304 the time at which the problem will occur, and displays 306 the time at which the problem will occur. In one embodiment, sensor data 114 is received from one or more sensors 110 associated with transport vehicle 120. In another embodiment, sensor data 114 is received from one or more sensors 110 associated with another transport vehicle 154.

[0119] Figure 3B shows another flowchart 320 according to an exemplary embodiment. Referring to Figure 3B, the transportation agency 120 determines one or more actions to solve the problem at block 322, selects one action from the one or more actions at block 324, displays the action at block 326, includes in the sensor data a history of sensor data 114 approaching a threshold indicating that a problem will occur soon at block 328, determines a problem in response to the transportation agency 120 being stationary and not operating at block 330, and provides a notification of the problem to the device at block 332. In one embodiment, the sensor data 114 is received from one or more sensors 110 associated with the transportation agency 120. In another embodiment, the sensor data 114 is received as sensor data 114 from another transportation agency 154.

[0120] Figure 3C shows yet another flowchart 340 according to an exemplary embodiment. Referring to Figure 3C, the method includes one or more of receiving verification of a problem from a consensus of transportation agencies at 342 and executing, by the transportation agencies, a smart contract for recording the verification and the time 126 at which the problem occurred on a blockchain at 344.

[0121] Figure 4 shows a machine learning transportation agency network diagram 400 according to an exemplary embodiment. The network 400 includes transportation agency nodes 402 that interface with a machine learning subsystem 406. The transportation agency nodes include one or more sensors 404.

[0122] The machine learning subsystem 406 includes a learning model 408, which is a mathematical artifact created by a machine learning system 410 that generates predictions by finding patterns in one or more training data sets. In some embodiments, the machine learning subsystem 406 is present within the transportation agency node 402. In other embodiments, the machine learning subsystem 406 is present outside the transportation agency node 402.

[0123] The transportation node 402 transmits data from one or more sensors 404 to the machine learning subsystem 406. The machine learning subsystem 406 provides the data from one or more sensors 404 to the learning model 408, and the learning model 408 returns one or more predictions. The machine learning subsystem 406 transmits one or more instructions to the transportation node 402 based on the predictions from the learning model 408.

[0124] In a further embodiment, the transportation node 402 transmits the data from one or more sensors 404 to the machine learning training system 410. In yet another embodiment, the machine learning subsystem 406 transmits the data of the sensors 404 to the machine learning subsystem 410. One or more of the applications, features, steps, solutions, etc. described and / or depicted herein can utilize the machine learning network 400 as described herein.

[0125] FIG. 5A shows an exemplary vehicle configuration 500 for managing database transactions related to a vehicle, according to an exemplary embodiment. Referring to FIG. 5A, when a particular transportation agency / vehicle 525 is engaged in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, transportation service, etc.), the vehicle receives an asset 510 and / or spits out / transfers an asset 512 according to the transaction. A processor 526 of the transportation agency is present within the vehicle 525, and there is communication between the processor 526 of the transportation agency and the database 530, and between the processor 526 of the transportation agency and the transaction module 520. The transaction module 520 records information such as assets, parties, credits, service descriptions, dates, times, locations, results, notifications, unexpected events, etc. These transactions in the transaction module 520 are replicated within the database 530. The database 530 is one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, is installed on the transportation agency, is installed outside the transportation agency, is directly accessible to the transportation agency, and / or is accessible to the transportation agency via a network.

[0126] FIG. 5B shows an exemplary vehicle configuration 550 for managing database transactions conducted between various vehicles according to an exemplary embodiment. Vehicle 525 engages with another vehicle 508 to perform various actions such as sharing, transferring, and obtaining services when the vehicle reaches a state where it needs to share services with another vehicle. For example, vehicle 508 may be at a time for battery charging and / or may have problems with tires and may be on a route to pick up goods for delivery. A transporter's processor 528 exists within vehicle 508, and there is communication between the transporter's processor 528, database 554, and transaction module 552. Vehicle 508 notifies another vehicle 525 that is within its network and operates on its blockchain membership service. A transporter's processor 526 exists within vehicle 525, and there is communication between the transporter's processor 526, database 530, and transaction module 520. Subsequently, vehicle 525 receives information for performing a goods pickup from vehicle 508 and / or from a server (not shown) via a wireless communication request. The transaction is recorded in the transaction modules 552 and 520 of both vehicles. Assuming that credit is transferred from vehicle 508 to vehicle 525 and the record of the transferred service is recorded in database 530 / 554, the record is recorded in a blockchain that is either different for each or the same blockchain used by all members. Database 554 is one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, and a distributed ledger, is installed in the transporter, is installed outside the transporter, is directly accessible, and / or is accessible via a network.

[0127] FIG. 6A shows a blockchain architecture configuration 600 according to an exemplary embodiment. Referring to FIG. 6A, the blockchain architecture 600 includes a group of blockchain member nodes 602-606 as part of a blockchain element, such as blockchain group 610. In one exemplary embodiment, a permissioned blockchain is not accessible to all parties, but only to members who are permitted access to the blockchain data. Blockchain nodes participate in a number of activities such as the addition and verification process (consensus) of blockchain entries. One or more of the blockchain nodes approve entries based on an endorsement policy and provide an ordering service for all blockchain nodes. The blockchain nodes initiate blockchain actions (such as authentication), attempt to write to the immutable ledger of the blockchain stored thereon, and a copy thereof is also stored on the underlying physical infrastructure.

[0128] Once a transaction is received and approved by the consensus model directed by the member nodes, the blockchain transaction 620 is stored in the computer memory. The approved transaction 626 is stored in the current block of the blockchain and committed to the blockchain via a commit procedure that includes executing a hash of the data content of the transactions in the current block and referencing the previous hash of the previous block. Within the blockchain, there are one or more smart contracts 630 that define the transaction agreements and the conditions of actions included in the smart contract executable application code 632 such as registered recipients, vehicle functions, requirements, permissions, sensor thresholds, etc. The code is configured to identify whether the requesting entity is registered to receive vehicle services, what service functions it is eligible to receive / requested to receive considering the profile status, and whether to monitor these actions in subsequent events. For example, when a service event occurs and the user is in the vehicle, the monitoring of sensor data is triggered, and it is identified that a predetermined parameter such as the vehicle charge level exceeds / falls below a specific threshold for a specific period, as a result, the current status changes, which requires sending an alert to the administrator (i.e., vehicle owner, vehicle operator, server, etc.) so that it can be stored for service identification and reference. The vehicle sensor data collected is based on the type of sensor data used to collect information about the status of the vehicle. Also, the sensor data forms the basis of data for vehicle event data 634 such as where to drive, average speed, maximum speed, acceleration, presence or absence of a collision, whether the expected route has been followed, where the next destination is, whether safety measures have been taken, whether the vehicle has sufficient charge / fuel, etc. All such information forms the basis of the smart contract conditions 630, and then the smart contract conditions 630 are stored in the blockchain.For example, the sensor thresholds stored in the smart contract can be used as criteria for determining whether the detected service is required and when and where the service should be executed.

[0129] Figure 6B shows a shared ledger configuration according to an exemplary embodiment. Referring to Figure 6B, an example 640 of blockchain logic includes a blockchain application interface 642 as an API or plugin application that links to a computing device and an execution platform for a specific transaction. The blockchain configuration 640 includes one or more applications linked to an application programming interface (API) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.) that can be created according to customized configurations required by participants, and the one or more applications can maintain their own states, control their own assets, and receive external information. This can be deployed as an entry and installed on all blockchain nodes via append to the distributed ledger.

[0130] The smart contract application code 644 provides the basis for blockchain transactions by establishing the application code, and when the application code is executed, the transaction conditions become active. When the smart contract 630 is executed, a certain approved transaction 626 is generated and then transferred to the blockchain platform 652. The platform includes security / authentication 658, a computing device 656 that executes transaction management, and a storage unit 654 as a memory for storing transactions and smart contracts in the blockchain.

[0131] The blockchain platform includes various layers of blockchain data, services (such as encryption trust services, virtual execution environments, etc.) and the underlying physical computer infrastructure, and these layers are used to receive and store new entries and provide access to auditors who attempt to access data entries. The blockchain exposes an interface that processes program code to provide access to the virtual execution environment necessary to participate in the physical infrastructure. Encryption trust services are used to verify entries such as asset exchange entries and maintain information privately.

[0132] The blockchain architecture configurations of FIGS. 6A and 6B process and execute program / application code through one or more interfaces exposed by the blockchain platform and services provided by the blockchain platform. As a non-limiting example, smart contracts are created to execute reminders, updates, and / or other notifications subject to change, updates, etc. The smart contracts themselves can be used to identify authentication and access requirements and rules related to the use of ledgers. For example, the information includes new entries processed by one or more processing entries (such as processors, virtual machines, etc.) included in the blockchain layer. The result includes a decision to reject or approve new entries based on criteria defined in the smart contract and / or peer consensus. The physical infrastructure is utilized to read any of the data or information described herein.

[0133] Within the executable code of a smart contract, the smart contract is created via a high-level application and programming language and then written to a block within a blockchain. A smart contract includes executable code that is registered, stored, and / or replicated on 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 conditions related to the smart contract being met. The execution of a smart contract causes a trusted modification to the state of the digital blockchain ledger. The modification to the blockchain ledger resulting from the execution of a smart contract is automatically replicated across the distributed network of blockchain peers through one or more consensus protocols.

[0134] A smart contract writes data to the blockchain in the form of key and value pairs. Further, smart contract code can read values stored on the blockchain and use this value in application operations. Smart contract code can write the output of various logical operations into the blockchain. The code is used to create temporary data structures in a virtual machine or other computing platform. Data written to the blockchain can be made public and / or encrypted and maintained as private. Temporary data used / generated by a smart contract is held in memory by the provided execution environment and then deleted once the data necessary for the blockchain is identified.

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

[0136] Figure 6C shows a blockchain configuration for storing blockchain transaction data according to an exemplary embodiment. Referring to Figure 6C, an exemplary configuration 660 provides a vehicle 662, a user device 664, and a server 666 that share information with a distributed ledger (i.e., a blockchain) 668. The server represents a service provider entity that queries a vehicle service provider to share user profile evaluation information when a known established user profile is attempting to rent a vehicle having an established evaluation profile. The server 666 receives and processes data regarding the service requirements of the vehicle. When a service event occurs, for example, when vehicle sensor data indicates a need for fuel / charging, maintenance service, a smart contract is used to call rules, thresholds, sensor information collection, etc. used to call a vehicle service event. Blockchain transaction data 670 is saved for each transaction such as access events, subsequent updates to the service status of the vehicle, event updates, etc. The transaction includes the parties, requirements (e.g., 18 years old, service candidate, valid driver's license, etc.), reward levels, distance traveled during the event, registered recipients permitted to access the event and operate vehicle services, rights / permissions, sensor data read during the operation of the vehicle event to record details of the next service event and identify the status of the vehicle, and thresholds used to determine whether the service event has been completed and whether the status of the vehicle has changed.

[0137] Figure 6D shows a blockchain block 680 that can be added to the distributed ledger and the content of block structures 682A - 682n according to an exemplary embodiment. Referring to Figure 6D, a client (not shown) submits an entry to a blockchain node to perform an activity on the blockchain. As an example, the client is an application that operates on behalf of a requester such as a device, person, or entity that proposes an entry to the blockchain. Multiple blockchain peers (e.g., blockchain nodes) maintain the state of the blockchain network and a copy of the distributed ledger. There are various types of blockchain nodes / peers in the blockchain network, including an approval peer that simulates and approves the entry proposed by the client, and a commit peer that verifies the approval, verifies the entry, and commits the entry to the distributed ledger. In this example, the blockchain node performs the role of an endorser node, a committer node, or both.

[0138] This system includes a blockchain that stores immutable and ordered records in blocks, and a state database (current world state) that maintains the current state of the blockchain. There is one distributed ledger per channel, and each peer maintains its own copy of the distributed ledger for each channel of which it is a member. This blockchain is an entry log structured as hash-linked blocks, where each block contains a sequence of N entries. Blocks contain various components such as those shown in FIG. 6D. The link of a block is generated by adding the hash of the previous block's header into the block header of the current block. In this way, all entries on the blockchain are ordered and cryptographically linked, which prevents the tampering of blockchain data without breaking the hash link. Further, the link makes the latest block in the blockchain represent all entries that came before it. This blockchain is stored in a peer file system (local or attached storage) that supports an append-only blockchain workload.

[0139] The current state of the blockchain and the distributed ledger is stored in the state database. Here, the current state data represents the latest values for all keys included in the blockchain's chain entry log. Calls to smart contract executable code execute entries against the current state of the state database. To make the interactions of these smart contract executable codes extremely efficient, the latest values of all keys are stored in the state database. Since the state database includes an indexed view into the blockchain's entry log, it can be regenerated from the chain at any time. The state database is automatically restored (or generated as needed) at the startup of the peer before entries are accepted.

[0140] The approval node receives an entry from the client and approves the entry based on the simulation results. The approval node holds a smart contract that simulates the proposal of the entry. When the approval node approves an entry, the approval node creates an entry endorsement, which is a signed response from the approval node to the client application indicating approval of the simulated entry. The method of approving an entry depends on the endorsement policy specified within the smart contract executable code. An example of an endorsement policy is that a majority of approval peers must approve the entry. Different channels can have different endorsement policies. The approved entry is transferred by the client application to the ordering service.

[0141] The ordering service accepts the approved entries, orders them into blocks, and distributes the blocks to the commit peers. For example, the ordering service starts a new block when the threshold of entries is reached, when a timer times out, or when another condition is met. In this example, the blockchain node is the commit peer that received the data block 682A for storage on the blockchain. The ordering service is composed of a cluster of orderers. The ordering service does not process entries and smart contracts, nor does it maintain a shared ledger. Rather, the ordering service accepts the approved entries and specifies the order in which these entries are committed to the distributed ledger. The architecture of the blockchain network is designed such that a particular implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0142] Entries are written to the distributed ledger in a consistent order. The order of the entries is established to ensure that updates to the state database are valid when committed to the network. Unlike cryptocurrency blockchain systems (such as Bitcoin) where ordering occurs through the solution of cryptographic puzzles or mining, in this example, the parties to the distributed ledger select the ordering mechanism most suitable for this network.

[0143] Referring to FIG. 6D, a block 682A (also referred to as a data block) stored in the blockchain and / or distributed ledger includes a plurality of 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 depicted blocks and their contents, such as block 682A and its contents, are for illustrative purposes only and are not meant to limit the scope of the exemplary embodiments. In some cases, both block header 684A and block metadata 688A may be smaller than transaction-specific data 686A that stores entry data, but this is not a requirement. Block 682A stores transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 690A to 690n. Block 682A also includes a link to a previous block (e.g., on the blockchain) within block header 684A. In particular, block header 684A includes the hash of the header of the previous block. Block header 684A also includes a unique block number, the hash of block data 690A of the current block 682A, etc. The block number of block 682A is unique and is assigned in an incremental / sequential order starting from zero. The first block in the blockchain is sometimes referred to as the genesis block and includes information about the blockchain, the members of the blockchain, the data stored in the blockchain, etc.

[0144] The block data 690A stores the entry information of each entry recorded in the block. For example, the entry data includes the type, version, timestamp, channel ID of the distributed ledger, entry ID, epoch, visibility of the payload, smart contract executable code path (deploy tx), smart contract executable code name, smart contract executable code version, input (smart contract executable code and functions), client (creator) identification information such as public key and certificate, client signature, endorser identification information, endorser signature, proposal hash, smart contract executable code event, response status, namespace, read set (list of keys and versions read by the entry, etc.), write set (list of keys and values, etc.), start key, end key, list of keys, summary of Merkle tree query, etc. The entry data is stored for each of the N entries.

[0145] In some embodiments, the block data 690A also stores the transaction-specific data 686A, and the transaction-specific data 686A adds additional information to the hash-linked chain of blocks in the blockchain. Thus, the data 686A can be stored in the immutable log of the blocks on the distributed ledger. Some of the advantages of storing such data 686A are reflected in the various embodiments disclosed and depicted herein. The block metadata 688A stores a plurality of fields of metadata (e.g., as a byte array or the like). The metadata fields include a signature in block creation, a reference to the last configuration block, an entry filter that identifies valid and invalid entries within the block, the last persisted offset of the ordering service that ordered the block, and the like. The signature, the last configuration block, and the metadata of the orderer are added by the ordering service. On the other hand, a block committer (e.g., a blockchain node) adds valid / invalid information based on an endorsement policy, verification of read / write sets, and the like. The entry filter includes a byte array of a size equal to the number of entries in the block data 610A and a verification code that identifies whether the entry was valid / invalid.

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

[0147] The above-described embodiments are implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination thereof. The computer program is embodied on a computer-readable medium such as a recording medium. For example, the computer program resides in a random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), register, hard disk, removable disk, compact disk read-only memory ("CD-ROM"), or other forms of storage media known in the art.

[0148] The exemplary recording medium is coupled to the processor such that the processor can read information from, and write information to, the recording medium. Alternatively, the recording medium may be integral with the processor. The processor and the recording medium may reside within an application specific integrated circuit ("ASIC"). Alternatively, the processor and the recording medium may exist as discrete components. For example, FIG. 7 shows an exemplary computer system architecture 700, which represents or is integrated with any of the components described above.

[0149] FIG. 7 is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the applications described herein. Nevertheless, computing node 700 can implement and / or execute any of the functions described above.

[0150] The computing node 700 includes a computer system / server 702 that operates in many other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations suitable for use with the computer system / server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld devices, laptop devices, multiprocessor systems, multiprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of these systems or devices.

[0151] The computer system / server 702 is described in the general context of computer system-executable instructions, such as program modules executed by a computer system. Generally, program modules include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 702 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

[0152] As shown in FIG. 7, the computer system / server 702 in the cloud computing node 700 is shown in the form of a general-purpose computing device. The components of the computer system / server 702 include, but are not limited to, one or more processors or processing units 704, a system memory 706, and a bus that couples various system components including the system memory 706 to the processor 704.

[0153] The bus represents any one or more of several types of bus structures including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of various bus architectures. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Extended ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0154] The computer system / server 702 typically includes various computer system-readable media. Such media can be any available media accessible by the computer system / server 702 and includes both volatile and non-volatile media, removable and non-removable media. In one embodiment, the system memory 706 implements the flow diagrams of other figures. The system memory 706 can include computer system-readable media in the form of volatile memory such as random access memory (RAM) 708 and / or cache memory 710. The computer system / server 702 can further include other removable / non-removable volatile / non-volatile computer system storage media. By way of example only, the memory 706 is provided for reading from and writing to a non-removable non-volatile magnetic medium (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media can be provided. In such a case, each is connected to the bus by one or more data media interfaces. As further depicted and described below, the memory 706 includes at least one program product having a set (e.g., at least one) of program modules configured to execute the functions of various embodiments of the application.

[0155] A program / utility having a set (at least one) of program modules is stored in memory 706, by way of example and not limitation, along with an operating system, one or more application programs, other program modules, and program data. Each or some combination of the operating system, one or more application programs, other program modules, and program data includes implementation of a network environment. Program modules generally execute the functionality and / or methodologies of the various embodiments of the applications as described herein.

[0156] As will be understood by one of ordinary skill in the art, aspects of the present application may be embodied as a system, method, or computer program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects that are generally referred to herein as a “circuit,” “module,” or “system.” Furthermore, aspects of the present application may take the form of a computer program product embodied in one or more computer readable media having computer readable program code embodied thereon.

[0157] In addition, computer system / server 702 communicates with one or more external devices via an I / O device 712 (such as an I / O adapter), and the I / O device 712 includes one or more devices that enable a user to interact with the computer system / server 702, such as a keyboard, a pointing device, a display, a voice recognition module, etc., and / or any device that enables the computer system / server 702 to communicate with one or more computing devices (for example, a network card, a modem, etc.). Such communication occurs via the I / O interface 712 of the device. Nevertheless, the computer system / server 702 can communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (such as the Internet), via a network adapter. As depicted, the device 712 communicates with other components of the computer system / server 702 via a bus. Although not shown, it should be understood that other hardware and / or software components can be used with the computer system / server 702. By way of example, and not limitation, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems, etc. are included.

[0158] At least one exemplary embodiment of a system, method, and non-transitory computer-readable medium is shown in the accompanying drawings and has been described in the foregoing detailed description, but the present application is not limited to the disclosed embodiments and it should be understood that numerous rearrangements, modifications, and substitutions are possible as defined by the following claims. For example, the functions of the systems of the various figures can be performed by one or more of the modules or components described herein or in a distributed architecture, and can include a transmitter, a receiver, or a pair of both. For example, all or part of the functions performed by individual modules are performed by one or more of these modules. Further, the functions described herein are performed in association with various events internal or external to the modules or components at various times. Also, the information transmitted between the various modules is transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or a plurality of protocols. Also, messages transmitted or received by any of the modules are transmitted or received directly and / or via one or more of the other modules.

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

[0160] Note that some of the system functions described in this specification are presented as modules to particularly emphasize implementation independence. For example, a module may be implemented as a hardware circuit including off-the-shelf semiconductors such as custom very large scale integration (VLSI) circuits or gate arrays, logic chips, transistors, or other discrete components. Also, a module may be implemented in a programmable hardware device such as a field programmable gate array, programmable array logic, programmable logic device, graphics processing unit, and the like.

[0161] Also, a module is at least partially implemented in software for execution by various types of processors. An identified unit of executable code comprises, for example, one or more physical or logical blocks of computer instructions organized as an object, procedure, or function. Nevertheless, the executable files of the identified modules need not be physically disposed together and may include heterogeneous instructions stored in different locations that, when logically combined, constitute the module and achieve the intended purpose of the module. Further, a module is stored on a computer-readable medium which is, for example, a hard disk drive, flash device, random access memory (RAM), tape, or other such medium used to store data.

[0162] In fact, a module of executable code may be a single instruction or many instructions and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data is identified and illustrated within a module in this specification, embodied in any suitable form, and organized within any suitable type of data structure. The operational data is collected as a single data set, distributed to different locations including different storage devices, and may exist at least partially simply as electronic signals on a system or network.

[0163] It will be readily understood that the components of the present application, generally described herein and shown in the drawings, can be arranged and designed in a wide variety of different configurations. For this reason, the detailed description of the embodiments is not intended to limit the scope of the present application in the claims, but rather to merely represent selected embodiments of the present application.

[0164] Those skilled in the art will readily understand that the above can be implemented using steps in a different order and / or using hardware elements of a configuration different from those disclosed. For this reason, although the present application has been described based on these preferred embodiments, certain modifications, variations, and alternative configurations will be apparent to those skilled in the art.

[0165] Although preferred embodiments of the present application have been described, the described embodiments are merely examples, and it should be understood that the scope of the present application should be defined only by the appended claims when considering the full scope of equivalents and modifications thereto (such as protocols, hardware devices, software platforms, etc.). The present disclosure includes the following aspects. (1) Determining by a transportation agency that a problem based on sensor data approaching a threshold within a period earlier than an average period will occur soon; Determining by the transportation agency the time at which the problem will occur; Displaying by the transportation agency the time at which the problem will occur A method including. (2) Determining by the transportation agency one or more actions for solving the problem; Selecting by the transportation agency one action from the one or more actions; Displaying the action The method according to (1) above, including. (3) The method according to (1) above, wherein the sensor data includes a history of the sensor data approaching the threshold indicating that the problem will occur soon. (4) When the transportation agency is stationary and not operating, in response, Determining by the transportation agency the problem; Providing a notification of the problem to one or more devices related to the transportation agency or an owner of the transportation agency The method according to (1) above, including. (5) Determining by the transportation agency that the time at which the problem will occur is earlier than a predicted arrival time at a destination; Providing recommendations for mitigating the problem in a time frame prior to the time at which the problem will occur The method according to (1) above, including. (6) The method according to (1) above, including receiving by the transportation agency a verification of one or more of the problem, the sensor data, the threshold, and the time at which the problem will occur, the verification including a blockchain consensus among a peer group consisting of the transportation agency and one or more other transportation agencies. (7) The method according to (6) above, including executing by the transportation agency a smart contract for recording the verification and the time at which the problem will occur on a blockchain based on the blockchain consensus. (8) A processor; A memory coupled to the processor and including instructions A system comprising, The instructions, when executed by the processor, The transport agency determines that a problem based on sensor data approaching a threshold within a period shorter than the average period will soon occur, the transport agency determines the time at which the problem will occur, a system configured to display, by the transport agency, the time at which the problem will occur. (9) The instructions are the transport agency determines one or more actions to solve the problem, the transport agency selects one action from the one or more actions, the system according to (8) above, configured to display the action. (10) The sensor data includes a history of the sensor data approaching the threshold indicating that the problem will soon occur, for the system according to (8) above. (11) If the transport agency is stationary and not operating, in response, the instructions are the transport agency determines the problem, the system according to (8) above, configured to provide a notification of the problem to one or more devices associated with the transport agency or the owner of the transport agency. (12) The instructions are the transport agency determines that the time at which the problem will occur is earlier than the expected arrival time at the destination, the system according to (8) above, configured to provide recommendations for mitigating the problem within a time frame prior to the time at which the problem will occur. (13) The instructions are the transport agency is configured to receive verification of one or more of the problem, the sensor data, the threshold, and the time at which the problem will occur, the verification including a blockchain consensus among a peer group consisting of the transport agency and one or more other transport agencies, for the system according to (8) above. (14) The instructions are the transport agency is configured to execute a smart contract for recording, on a blockchain, the verification and the time at which the problem will occur based on the blockchain consensus, for the system according to (13) above. (15) A non-transitory computer-readable medium including instructions, which, when read by a processor, cause the processor to determine, by a transport agency, that a problem based on sensor data approaching a threshold within a period shorter than the average period will soon occur, determine, by the transport agency, the time at which the problem will occur, display, by the transport agency, the time at which the problem will occur A non-transitory computer-readable medium that causes the above to be executed. (16) The instructions cause the processor to determine, by the transportation agency, one or more actions for solving the problem; select, by the transportation agency, one action from the one or more actions; display the action The non-transitory computer-readable medium according to (15) above, which further causes the above to be executed. (17) The non-transitory computer-readable medium according to (15) above, wherein the sensor data includes a history of the sensor data approaching a threshold value indicating that the problem will occur soon. (18) When the transportation agency is stationary and not operating, in response, the instructions cause the processor to determine the problem by the transportation agency; provide a notification of the problem to one or more devices related to the transportation agency or the owner of the transportation agency The non-transitory computer-readable medium according to (15) above, which further causes the above to be executed. (19) The instructions cause the processor to determine, by the transportation agency, that the time when the problem occurs is earlier than the expected arrival time at the destination; provide recommendations for mitigating the problem in a time frame prior to the time when the problem occurs The non-transitory computer-readable medium according to (15) above, which further causes the above to be executed. (20) The instructions cause the processor to receive, by the transportation agency, verification of one or more of the problem, the sensor data, the threshold value, and the time when the problem occurs, the verification including a blockchain consensus among a peer group consisting of the transportation agency and one or more other transportation agencies; execute, by the transportation agency, a smart contract for recording, on the blockchain, the verification and the time when the problem occurs based on the blockchain consensus The non-transitory computer-readable medium according to (15) above, which further causes the above to be executed.

Claims

1. Based on sensor data approaching a threshold within a period earlier than the average period in which problems related to the operation of the transportation vehicle occur, the transportation vehicle determines that the problem will occur soon; The transportation vehicle determines the time at which the problem occurs; The transportation vehicle displays the time at which the problem occurs on a display of the transportation vehicle; Dispose an eye position sensor for detecting whether a driver of the transportation vehicle is looking at the display of the transportation vehicle; When the eye position sensor determines that the driver is not looking at the display, increase visual and / or auditory warnings; A method comprising the above.

2. The transportation vehicle determines one or more actions for solving the problem; The transportation vehicle selects one action from the one or more actions; Display the action The method according to claim 1, comprising the above.

3. The method according to claim 1 or 2, wherein the sensor data includes a history of the sensor data approaching the threshold indicating that the problem will occur soon.

4. In response to the transportation vehicle being stationary and not operating, The transportation vehicle determines the problem; Provide notification of the problem to one or more devices related to the transportation vehicle or the owner of the transportation vehicle The method according to claim 1 or 2, comprising the above.

5. The transportation vehicle determines that the time at which the problem occurs is earlier than the expected arrival time at the destination; Provide recommendations for mitigating the problem within a time frame prior to the time at which the problem occurs The method according to claim 1 or 2, comprising the above.

6. The method according to claim 1 or 2, comprising receiving verification of one or more of the problem, the sensor data, the threshold, and the time at which the problem occurs, the verification including a blockchain consensus among a peer group consisting of the transportation vehicle and one or more other transportation vehicles.

7. The method according to claim 6, comprising executing a smart contract for recording the verification and the time at which the problem occurs on a blockchain based on the blockchain consensus.

8. A processor, A system comprising a memory coupled to the processor and containing instructions, wherein the instructions, when executed by the processor, cause the transportation vehicle to determine that a problem related to the operation of the transportation vehicle will occur soon based on sensor data approaching a threshold within a period earlier than the average period in which problems related to the operation of the transportation vehicle occur, cause the transportation vehicle to determine the time at which the problem will occur, cause the transportation vehicle to display the time at which the problem will occur on a display of the transportation vehicle, arrange an eye position sensor for detecting whether a driver of the transportation vehicle is looking at the display of the transportation vehicle, and when the eye position sensor determines that the driver is not looking at the display, cause visual and / or auditory warnings to be increased. A system configured as described above.

9. The instructions cause the transportation vehicle to determine one or more actions for solving the problem, cause the transportation vehicle to select one action from the one or more actions, and cause the system according to claim 8 to be configured to display the action.

10. The sensor data includes a history of the sensor data approaching the threshold indicating that the problem will occur soon, according to the system of claim 8 or 9.

11. When the transportation vehicle is stationary and not operating, in response, the instructions cause the transportation vehicle to determine the problem, and cause the system according to claim 8 or 9 to be configured to provide notification of the problem to one or more devices related to the transportation vehicle or the owner of the transportation vehicle.

12. The instructions cause the transportation vehicle to determine that the time at which the problem will occur is earlier than the expected arrival time at the destination, and cause the system according to claim 8 or 9 to be configured to provide recommendations for mitigating the problem in a time frame prior to the time at which the problem will occur.

13. The instructions cause the transportation vehicle to be configured to receive verification of one or more of the problem, the sensor data, the threshold, and the time at which the problem will occur, the verification including a blockchain consensus among a peer group consisting of the transportation vehicle and one or more other transportation vehicles, according to the system of claim 8 or 9.

14. The instructions ​ The system according to claim 13, wherein the transport mechanism is configured to execute a smart contract for recording the verification and the time at which the problem occurs on a blockchain based on the blockchain consensus. **Claim 15** A computer program, when read by a processor, causes the processor to determine that the problem is about to occur based on sensor data approaching a threshold within a period earlier than an average period in which a problem related to the operation of the transport mechanism occurs by the transport mechanism; determine, by the transport mechanism, the time at which the problem occurs; display, by the transport mechanism, the time at which the problem occurs on a display of the transport mechanism; arrange an eye position sensor for detecting whether a driver of the transport mechanism is looking at the display of the transport mechanism; increase visual and / or auditory warnings when the eye position sensor determines that the driver is not looking at the display; A computer program that causes the above to be executed.

Images