JP7789762B2 - Determining the use of transportation means - Google Patents

Description

Vehicles or vehicles, such as cars, motorcycles, trucks, airplanes, trains, and the like, generally meet the mobility needs of passengers and/or goods in a variety of ways. Functionality associated with the vehicle may be identified and utilized by various computing devices, such as smartphones or computers, located within and/or external to the vehicle.

In one exemplary embodiment, a method is provided that includes one or more of: acquiring, by a transportation vehicle, data related to the performance of the transportation vehicle; determining, by the transportation vehicle, a performance level of the transportation vehicle based on the acquired data; dynamically modifying, by the transportation vehicle, the performance level based on a current use of the transportation vehicle; and determining, by the transportation vehicle, a next use of the transportation vehicle based on the dynamically modified performance level.

In another exemplary embodiment, a system is provided that includes a memory communicatively coupled to a processor, where the processor performs one or more of: acquiring data related to performance of a vehicle; determining a performance level of the vehicle based on the acquired data; dynamically modifying the performance level based on current use of the vehicle; and determining a next use of the vehicle based on the dynamically modified performance level.

In an additional exemplary embodiment, a non-transitory computer-readable medium is provided that includes instructions that, when read by a processor, cause the processor to perform one or more of: acquiring, by the vehicle, data related to performance of the vehicle; determining, by the vehicle, a performance level of the vehicle based on the acquired data; dynamically modifying, by the vehicle, the performance level based on current use of the vehicle; and determining, by the vehicle, a next use of the vehicle based on the dynamically modified performance level.

In one exemplary embodiment, a method is provided that includes one or more of: acquiring, by a transportation vehicle, data related to the performance of the transportation vehicle; determining, by the transportation vehicle, a performance level of the transportation vehicle based on the acquired data; dynamically modifying, by the transportation vehicle, the performance level based on a current use of the transportation vehicle; and determining, by the transportation vehicle, a next use of the transportation vehicle based on the dynamically modified performance level.

In another exemplary embodiment, a system is provided that includes a memory communicatively coupled to a processor, wherein the processor performs one or more of: receiving characteristics associated with a vehicle for a period of time, the characteristics relating to a condition of the vehicle, an operational behavior of the vehicle, and a maintenance cost of the vehicle; providing one or more actions to be performed by the vehicle to increase a level of the characteristics; and determining a next use of the vehicle after the period of time in response to the increased level of the characteristics.

In an additional exemplary embodiment, a non-transitory computer-readable medium is provided that includes instructions that, when read by a processor, cause the processor to perform one or more of: acquiring, by the vehicle, data related to performance of the vehicle; determining, by the vehicle, a performance level of the vehicle based on the acquired data; dynamically modifying, by the vehicle, the performance level based on current use of the vehicle; and determining, by the vehicle, a next use of the vehicle based on the dynamically modified performance level.

FIG. 10 illustrates a process for dynamic performance levels in accordance with an illustrative embodiment. 1 is an illustration of dynamic performance levels for a vehicle in accordance with an illustrative embodiment; 10 is an illustration of a flowchart for determining the next use of a vehicle in accordance with an illustrative embodiment; FIG. 10 illustrates a vehicle history report in accordance with an exemplary embodiment. FIG. 10 illustrates another vehicle history report in accordance with an exemplary embodiment. FIG. 10 illustrates yet another vehicle history report in accordance with an exemplary embodiment; FIG. 10 illustrates another flowchart in accordance with an exemplary embodiment. FIG. 1 is an illustration of a transportation network diagram in accordance with an illustrative embodiment; FIG. 10 is an illustration of another transportation network diagram in accordance with an illustrative embodiment; FIG. 10 is an illustration of yet another vehicle network diagram in accordance with an illustrative embodiment; FIG. 10 is an illustration of an additional vehicle network diagram in accordance with an illustrative embodiment; 10 is an illustration of an additional transportation network diagram in accordance with an illustrative embodiment; 10 is an illustration of an additional transportation network diagram in accordance with an illustrative embodiment; 10 is an illustration of an additional transportation network diagram in accordance with an illustrative embodiment; FIG. 1 illustrates a diagram depicting charging of one or more elements in accordance with an exemplary embodiment. FIG. 1 illustrates a diagram depicting interconnections between different elements, according to an exemplary embodiment. 10A-10C illustrate additional diagrams depicting interconnections between different elements according to exemplary embodiments. FIG. 10 illustrates yet another diagram depicting interconnections between elements in accordance with an illustrative embodiment. 10A-10C illustrate additional diagrams depicting a keyless entry system according to exemplary embodiments. 10A-10C illustrate additional diagrams depicting a CAN within a vehicle in accordance with an illustrative embodiment; FIG. 10 illustrates yet an additional diagram depicting end-to-end communication channels in accordance with an exemplary embodiment. FIG. 10 illustrates yet an additional diagram depicting an example of a vehicle implementing secured V2V communications using security certificates, according to an exemplary embodiment. FIG. 1 illustrates a flowchart in accordance with an exemplary embodiment. FIG. 10 illustrates another flowchart in accordance with an exemplary embodiment. FIG. 10 illustrates yet another flowchart in accordance with an exemplary embodiment. FIG. 10 illustrates yet another flowchart in accordance with an exemplary embodiment. FIG. 10 illustrates yet another flowchart in accordance with an exemplary embodiment. FIG. 10 is an illustration of a machine learning vehicle network diagram in accordance with an illustrative embodiment; FIG. 1 illustrates an exemplary vehicle configuration for managing database transactions associated with a vehicle, according to an exemplary embodiment. FIG. 1 illustrates another exemplary vehicle configuration for managing database transactions performed between various vehicles, according to an exemplary embodiment. FIG. 1 illustrates a blockchain architecture configuration, according to an example embodiment. FIG. 1 illustrates another blockchain configuration according to an exemplary embodiment. FIG. 1 illustrates a blockchain configuration for storing blockchain transaction data, according to an exemplary embodiment. FIG. 2 illustrates an exemplary data block according to an exemplary embodiment. FIG. 1 illustrates an example system that supports one or more of the example embodiments.

It will be readily understood that the components of the present invention, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. As such, the following detailed description of at least one embodiment of a method, apparatus, non-transitory computer-readable medium, and system as illustrated in the accompanying figures is not intended to limit the scope of the present application as claimed, but is merely representative of selected embodiments.

Communications between a vehicle and particular entities, such as remote servers, other vehicles, and local computing devices (e.g., smartphones, personal computers, vehicle-embedded computers, etc.), may be received, transmitted, and processed by one or more "components," which may be hardware, firmware, software, or a combination thereof. A component may be part of any such entity or computing device, or of a particular other computing device. In one example, consensus decisions related to blockchain transactions may be performed by one or more computing devices or components (which may be any element described and/or illustrated herein) associated with the vehicle and one or more components external to or remote from the vehicle.

The features, structures, or characteristics of the invention described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrase "exemplary embodiment," "some embodiments," or other similar terms refers to the fact that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Thus, any appearance of the phrase "exemplary embodiment," "some embodiments," "other embodiments," or other similar terms throughout this specification does not necessarily refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the figures, even if the depicted connections are one-way or two-way arrows, any connection between elements may enable one-way and/or two-way communication. In the current solution, transportation vehicles may include one or more of a car, a truck, a pedestrian-only area battery electric vehicle (BEV), an e-Palette, a fuel cell bus, a motorcycle, a scooter, a bicycle, a boat, a recreational vehicle, an airplane, and any object that can be used to transport people and/or goods from one location to another.

Furthermore, although the term "message" may be used in describing the embodiments, other types of network data, such as packets, frames, datagrams, etc., may also be used. Furthermore, although particular types of messages and signaling may be illustrated in the exemplary embodiments, such messages and signaling are not limited to one particular type of message and signaling.

In an exemplary embodiment, a method, system, component, non-transitory computer-readable medium, device, and/or network is provided for providing at least one of a transportation means (also referred to herein as a vehicle or automobile), a data collection system, a data monitoring system, a verification system, an authorization system, and a vehicle data distribution system. Vehicle status data received in the form of communication messages, such as wireless data network communications and/or wired communication messages, may be processed to identify vehicle/vehicle status conditions and provide feedback regarding the status and/or changes of the transportation means. In one example, a user profile may be applied to a particular transportation means/vehicle to authorize current vehicle events, service stops at service stations, authorize subsequent vehicle rental services, and enable vehicle-to-vehicle communications.

Within communications infrastructures, a distributed database is a distributed storage system that includes multiple nodes communicating 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. The untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching consensus among the distributed peers. For example, peers execute a consensus protocol to validate blockchain storage entries, group the storage entries into blocks, and build a hash chain through the blocks. This process reorders the storage entries as necessary to create a ledger for consistency. In public or permissionless blockchains, anyone can participate without specific identity. Public blockchains include cryptocurrencies and can use consensus based on various protocols, such as proof-of-work (PoW). Permissioned blockchain databases, on the other hand, can secure interactions between groups of entities that share a common goal but do not or cannot fully trust each other, such as businesses exchanging funds, goods, or information. The solution of the present invention can function in permissioned and/or permissionless blockchain settings.

A smart contract is a trusted distributed application that leverages the tamper-proof properties of a shared or distributed ledger (which may be in the form of a blockchain) and a basic agreement between member nodes called an endorsement or approval policy. Blockchain entries are typically "endorsed" before being delegated to the blockchain, while unendorsed entries are ignored. A typical endorsement policy allows the smart contract executable code to specify endorsers for the entry, in the form of a set of peer nodes required for endorsement. When a client submits an entry to the peers specified in the endorsement policy, the entry is executed, validating the entry. After validation, the entry enters the ordering phase, where a consensus protocol is used to generate an ordered sequence of approved entries grouped into blocks.

A node is a communicating entity in a blockchain system. A "node" may perform a logical function, meaning multiple nodes of different types can run on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control them in various ways. Nodes may include various types, such as client or submitting client nodes, which send entry calls to endorsers (e.g., peers) and broadcast entry proposals to an ordering service (e.g., ordering node). Another type of node is a peer node, which can receive client-submitted entries, delegate entries, and maintain the ledger state and copies of blockchain entries. Peers may also have endorser roles. An ordering service node, or orderer, is a node that performs communication services for all nodes and enforces delivery guarantees, such as broadcasting to each of the peer nodes in the system, when delegating entries and modifying the blockchain world state. The world state may constitute the initial blockchain entry, which typically contains control and setup information.

A ledger is an ordered, tamper-proof record of all state transitions in a blockchain. A state transition may result from a smart contract executable code invocation (i.e., an entry) submitted by a participant (e.g., client node, order node, endorser node, peer node, etc.). An entry may result in a set of key-value pairs of assets being delegated to the ledger as one or more operands, such as create, update, or delete. A ledger includes a blockchain (also called a chain) that is used to store immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel it is a member of.

A chain is an entry log structured as hash-linked blocks, where each block contains 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 as well as the hash of the previous block's header. In this way, all entries in the ledger may be ordered and cryptographically linked. This makes it impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents every entry on the chain that preceded it, ensuring that all peer nodes are in a consistent and trusted state. The chain may be stored on the peer node file system (i.e., local attached storage, cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

The current state of the immutable ledger represents the most recent values of all keys contained in the chain's entry log. The current state is sometimes called the world state, as it represents the most recent key values known to the channel. Smart contract executable code invocations perform entries against the ledger's current state data. To streamline such smart contract executable code interactions, the most recent values of keys may be stored in a state database. The state database may simply be an indexed view into the chain's entry log, so it can be regenerated from the chain at any time. The state database may be automatically restored (or generated on demand) at peer node startup and before entries are accepted.

Blockchains differ from traditional databases in that they provide decentralized, immutable, and secure storage rather than centralized storage, and nodes must share changes to records in storage. Some properties that are unique to blockchains and that are useful for their implementation include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, authorization, and accessibility.

In an exemplary embodiment, services are provided to a specific vehicle and/or to a user profile applied to the vehicle. For example, a user may be the owner of the vehicle or an operator of a vehicle owned by another party. Vehicles may require service at regular intervals, and service requests may require consent before service is permitted. Alternatively, a service center may provide service to vehicles in a nearby area based on the vehicle's current route plan and the relative level of service requirements (e.g., immediate, heavy, moderate, light, etc.). Vehicle requests may be monitored via one or more vehicle and/or road sensors or cameras that report sensed data to a central control computer device within the vehicle and/or a central control computer device remote from the vehicle. This data is forwarded to a management server for review and action. Sensors may be located on one or more of the interior of the vehicle, the exterior of the vehicle, fixed objects remote from the vehicle, and other vehicles in proximity to the vehicle. Sensors may also be associated with vehicle speed, vehicle braking, vehicle acceleration, fuel level, service requests, vehicle gear shifts, vehicle steering, etc. As described herein, sensors may also be devices, such as wireless devices within the vehicle and/or in proximity to the vehicle. Sensor information may also be used to identify whether the vehicle is operating safely and whether an occupant is involved in any unexpected vehicle conditions, such as during vehicle access and/or use periods. Vehicle information collected before, during, and/or after vehicle operation may be identified and stored in transactions on a shared/distributed ledger. The transactions may be generated and delegated to an immutable ledger as determined by a permissioned community, and thus in a "decentralized" manner, such as via a blockchain membership group.

As each stakeholder (i.e., owner, user, company, agency, etc.) may wish to limit the disclosure of personal information, the blockchain and its immutability can be used to manage permissions for each specific user-vehicle profile. Smart contracts may be used to provide compensation, quantify user profile scores/ratings/reviews, apply vehicle event permissions, determine when service is required, identify collision and/or deterioration events, identify safety concern events, identify participants in the event, and provide distribution to registered entities seeking access to such vehicle event data. Additionally, outcomes may be identified, and the required information can be shared among registered companies and/or individuals based on a consensus approach associated with the blockchain. Such an approach may not be implemented with traditional centralized databases.

Various driving systems of the present solutions may utilize software, a suite of sensors, machine learning capabilities, light detection and ranging (LIDAR) projectors, radar, ultrasonic sensors, and the like to create maps of terrain and roads that vehicles can use for navigation and other purposes. In some embodiments, additional GPS, maps, cameras, sensors, and the like may be used by autonomous vehicles in place of LIDAR.

In certain embodiments, the solution of the present invention involves authorizing a vehicle for service via an automated, rapid authentication scheme. For example, a drive to a charging station or fuel pump may be performed by the vehicle operator or autonomous vehicle, and if authorization is received by the service and/or charging station, authorization to charge or receive fuel may be performed without delay. The vehicle may provide a communication signal that provides the identity of the vehicle with a currently valid profile linked to an account authorized to receive the service, which may later be modified with compensation. Additional means may be used to provide additional authentication, such as transmitting another identifier wirelessly from the user's device to the service center, replacing or supplementing the first authorization process between the vehicle and the service center with an additional authorization process.

The shared and received data may be stored in a database, which generally keeps the data in one specific location within one single database (e.g., a database server). This location may be a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a centralized database can typically be accessed from several different points. Because of its single location, a centralized database is easier to manage, maintain, and control, especially for security purposes. Additionally, storing all data in one location in a centralized database minimizes data redundancy, as it means there is only one primary record for a given data set. Blockchain may also be used to store transportation-related data and transactions.

In one embodiment, data obtained from and/or related to a vehicle is referred to herein as a dynamic performance level (DPL) and/or value. The data may be derived from one or more of: determining vehicle damage and health information; determining an aggressive event score based on the ratio of the number of detected aggressive events to the distance driven by the operator; driving behavior data including information about distance traveled, average speed, vehicle crash speed, safety, and service history; and the like.

This data and information may be provided by one or more sensors, which may be connected to the CAN bus. For example, a vehicle camera may be used to capture an image of a portion of the vehicle. This image may be used to determine whether that portion of the vehicle is damaged, for example, by comparing the image to a previous vehicle or to a stored set of images of undamaged vehicles. In one embodiment, the vehicle (via a processor within the vehicle, otherwise referred to as the vehicle computer) is connected over a network, such as the Internet, to an external server, which may retrieve and store such data.

Additionally, sensor data from the vehicle (e.g., from both critical and/or non-critical ECUs of the vehicle), signals from vibration sensors, monitored power signals, etc. may be used to determine whether vehicle components are operating within specifications, require maintenance, or are on the verge of failure. In one embodiment, this sensor data may be used to provide a vehicle health score. Similarly, sensors inside or outside the vehicle may be used to determine whether the vehicle's user (through driving and/or non-driving behavior) has damaged the vehicle or worsened the vehicle's health status.

In one embodiment, a detected aggressive event is one that exceeds a G-force threshold. The server and/or vehicle determines a penalty score for the operator/driver by adding the aggressive event score to the total event score. The penalty score for each aggressive event is based on a penalty coefficient for distance traveled over a period of time associated with the detected aggressive event. The penalty score is determined relative to one or more of the operator's previous scores and other drivers to improve driving behavior.

In one embodiment, a linear regression model can be used to score one or more movements of a given operator/driver based on actions such as acceleration, braking, cornering, etc. The G-force thresholds associated with each severity of a violent event (e.g., low, medium, high) are based on statistical calculations performed on longitudinal and lateral G-force distributions of historical driving data (which may be anonymized). The individual score for any given indicator of movement (e.g., acceleration/braking/cornering, etc.) is determined using the following formula:

In one embodiment, the metric score parameter in the formula takes the form of the bottom 3 percentile of (number of abusive metric events)/(number of miles driven) determined based on historical anonymized driving data. In another embodiment, the penalty factors for low, medium, and high severity events are 0, 1, and 2, respectively. In one embodiment, the scores for all drivers of a selected vehicle may be recorded as a cumulative score of the behavior of all drivers of that vehicle over the ownership period. In one embodiment, the driving behavior data includes miles driven, average speed, and vehicle crash speed. In one embodiment, the safety recall information includes manufacturer recalls, safety device installation and status (airbag deployment). The service history includes a record of service activities and the dates of such maintenance activities.

Actions utilizing one or more of the information described herein provide a detailed vehicle history, including component sensor data (e.g., via the CAN bus) and vehicle health, in addition to operator/driver usage/behavior data to determine an overall vehicle score (DPL). The DPL score may be increased based on actions such as proper driving, scheduled vehicle maintenance, and occupant behavior.

Any of the actions described herein may be performed by one or more processors (microprocessors, sensors, ECUs, head units, cameras, etc.) that may be located inside or outside the vehicle. The one or more processors may communicate with other processors inside or outside the vehicle to utilize data transmitted by the vehicle. Processors, including one or more processors, may transmit data, receive data, and utilize this data in conjunction with one or more memories to perform one or more of the actions described or illustrated herein.

If the DPL score is low (e.g., below a fixed or dynamic threshold), the system can provide actions the vehicle can take to improve the score. Such system-determined actions will improve one or more aspects of the vehicle's operations and are monitored by the system to notify the vehicle and/or driver of developments related to one or more of the vehicle's performance, operating behavior, maintenance costs, etc. Additionally, the system can provide detailed actions that can be taken in each such area. For example, vehicle status may consist of one or more of: a determination of vehicle damage and vehicle health information; a determination of an abusive event score based on the ratio of the number of abusive events detected to the distance driven by the operator; a miles/gallon or kW/mile rating; the efficiency with which the vehicle is operating, including measurements of acceleration, deceleration, and cornering speed; and the like. Driving behavior can consist of how the vehicle is driven, including measurements of average speed, high speeds, braking, speeding, turning, etc. Maintenance costs can consist of measures related to regular maintenance, system and diagnostic checks, tire pressure, etc.

In one embodiment, the owner or vehicle (if semi-autonomous or fully autonomous) can notify the server of an action to be taken, such as selling, trading in, or otherwise disposing of the vehicle. The system can utilize the data described herein to provide a DPL and/or value for the vehicle and, if acceptable, initiate the action. If not acceptable, the system and/or vehicle can provide optimal/timely/efficient actions that can be taken/avoided to increase the value of the vehicle.

In one embodiment, the system notifies the vehicle of specific items to resolve/address that will increase the vehicle's value based on current sales, past sales, requested features, current trends, etc. The system obtains this information by querying other processors or computers, such as the server, other vehicles, etc. Based on the vehicle's specific processing, the server can provide detailed actions that the vehicle can take and/or take on behalf of the vehicle to increase value.

In another embodiment, the system can notify the owner of actions they can take (e.g., at the end of a lease) to increase the value of the vehicle, such as performing a service or upgrading parts on the vehicle. The trample communicates with a server over the network to query the actions, whereupon a response to the query is presented to the user, such as via a response text displayed on a display associated with the vehicle. The server provides the vehicle with the best actions the user can take to increase the DPL and/or value of the vehicle, along with corresponding estimated results for implementing such actions.

FIG. 1A illustrates a process 100 involving a dynamic performance level (DPL) for a vehicle 104, according to an exemplary embodiment. The DPL 102 is derived from several areas and may relate to the current use 105 of the vehicle 104 and/or past use of the vehicle. One of the areas is based on performance 106, utilizing data from sensors attached to and/or proximate to the vehicle, such as cameras capable of detecting the damage or health status of the vehicle 104. The next area includes determining an optional aggressive event score based on the ratio of the number of detected aggressive events to the distance driven by the operator and driving behavior data 107, including distance traveled, average speed, and vehicle crash speed. The aggressive event score may be determined by a processor associated with the vehicle, such as a vehicle computer, where sensors associated with the vehicle transmit data to the vehicle computer to determine the aggressive event score. The sensors may include elements capable of determining movement, changes in movement, rates of change in movement, etc. The next area includes information regarding safety history and service history 108. The vehicle, such as through a vehicle computer, interacts with a server external to the vehicle, such as over a network, to obtain data regarding the vehicle's safety and service history. Other elements 109 may also be used to determine the DPL, which may or may not be described herein. Determination of the DPL may be either static or dynamic. Dynamic determination of the DPL involves determining the current use 105 of the vehicle 104 at different points in time, where the DPL is updated 103 with new data.

FIG. 1B illustrates a flowchart for determining the next use of a vehicle 110, according to an exemplary embodiment. Certain actions may be taken based on vehicle terms 112 known and stored by the server and/or vehicle. The terms may relate to time frames relevant to the disposition of the vehicle, such as the time before a lease agreement expires, a trade-in occurs, or a sale begins. The dynamic performance level (DPL) 102 and/or values associated with the DPL, along with one or more of the vehicle's current condition, vehicle desirability, vehicle location, vehicle characteristics (e.g., make, model, year, color, tone, installed options, retrofit options, etc.), etc., are used to determine the next use of the vehicle (114). The determined next use 114 may include a vehicle enrolled in another leasing program, such as the current lessee or another lessee 115, a vehicle enrolled in a ride-sharing program 116, a vehicle for sale (certified or non-certified) 117, or other actions 118, such as a trade-in or exchange of the vehicle.

In one embodiment, a tiered next use of the vehicle may be determined. For example, the server may determine, based on the greatest increase in revenue/value, to enroll the vehicle in a leasing program for one year, followed by a ride-pooling program for two years, depending on the age/condition of the vehicle. Within this timeframe, while the vehicle is leased, but prior to enrolling in the ride-pooling program, the server/vehicle may provide the vehicle/owner with a notification regarding actions to be taken to entice the owner to surrender the vehicle using the appropriate DPL for use in the ride-pooling program. The enticement may include the server/vehicle offering monetary or non-monetary value to the owner (e.g., consideration for purchasing or otherwise gaining access to the next vehicle).

In another embodiment, the server may recommend certain actions that need to be taken or not taken to ensure maximum revenue/value based on the intended disposition of the vehicle. In one embodiment, arbitrage may occur by offering favorable offers (e.g., lower lease rates than are typically available) in exchange for the owner/operator's adherence to the DPL and/or values associated with the DPL (e.g., ensuring adherence to not exceeding a certain number of miles within a certain time frame). In an additional embodiment, the server/vehicle, based on adherence to the DPL and/or values associated with the DPL, may specify terms for the initial sale of the vehicle based on the vehicle's potential repurchase (e.g., a dealer repurchasing a vehicle that is about to be sold).

FIG. 1C shows an exemplary system diagram 120 according to an exemplary embodiment. In this example, three vehicles 122, 123, and 124 may communicate with each other, with a server 128 directly via a wireless protocol, and/or with a server 128 via a network 126. In one embodiment, the DPL for one vehicle 122 may be provided to another vehicle 123 via a more direct connection, or provided by the vehicle 124 via a network 126, etc. In this example, the vehicles are in approximately the same physical area or are in close proximity to each other. One or more of the vehicles 122, 123, 124 and/or the server 128 may determine whether the vehicles 122, 123, 124 are similar in some respects based on vehicle-specific attributes such as make, model, year, total mileage, average mileage, etc. This may be determined by the vehicle/system/server obtaining information from the vehicles, where data is transmitted via a wireless protocol and/or the server 128. Additionally, it can be determined whether vehicles generally operate or are used in roughly the same area, such as a particular city or part of a city. One or more of the vehicles and/or the system can receive the DPLs for each similar vehicle, derive vehicle values based on the DPLs, and compare the vehicle values. Because such vehicles are similar in terms of vehicle-specific attributes and areas of use, they can compare and share factors that make one more valuable than another. This information can be used by lower-scoring vehicles to improve their DPLs by focusing on the attributes with the lowest scores (e.g., performance, operating behavior, maintenance costs, etc.). The reasons why the attributes of the higher-scoring vehicles are at a particular level can be provided to the lower-scoring vehicles and used to change the current and future use of the lower-scoring vehicles. For example, the average speed, speed in a particular area, braking data, driving mode (e.g., eco, sport), steering data, maintenance data, etc., of the higher-value vehicles can be analyzed and provided to the lower-value vehicles to prompt behavioral changes. This change will result in a safer driving experience for lower value vehicles, as well as all adjacent vehicles, and will lead to increased value for lower value vehicles when vehicles are traded in, sold, or otherwise disposed of.

In another embodiment, a server receives data related to vehicle performance, vehicle operational behavior, and vehicle maintenance costs. The server determines a performance level for the vehicle based on the obtained data. The performance level is dynamically modified based on current use of the vehicle. The server determines the next use of the vehicle based on the dynamically modified performance level.

FIG. 1D illustrates a vehicle/vehicle report 130 according to an exemplary embodiment. The report includes one or more elements used in determining the DPL and/or values associated with the DPL. The report 130 includes a vehicle history portion 131, a vehicle driving behavior portion 132, and a safety portion 133. The vehicle history portion includes details of the make, model, condition, chassis number, color, production date, and a link to the warranty, transferable warranty, window sticker, title history, and safety features 135. Additionally, the vehicle history portion includes the number of previous owners 136, odometer reading 137, number of collisions 138, number of open recalls 139, number of driving notices 140, and number of service issues 141. The vehicle driving behavior portion 132 includes an aggressive driving score 142, e.g., comprised of 98% hard braking (much less than the comparison vehicle), 32% aggressive cornering (more aggressive than the comparison vehicle), and 58% hard acceleration (more aggressive than the comparison vehicle); a total mileage score 143, e.g., comprised of an average of 2,150 miles/year (slightly more than the average driver) and 8,419 miles on the odometer (as of July 2, 2020); and an average speed 144, e.g., comprised of an average of 57 miles/hour (indicating mostly highway driving). The safety section 133 includes owner-specific reports of manufacturing recalls 145 (e.g., no open recalls reported), owner-specific reports of safety devices 146 (e.g., safety device installations reported on September 7, 2020), and owner-specific reports of airbag deployments 147 (e.g., airbag deployments reported on September 4, 2020). The report also includes a header area 134 that includes the year, make model, condition, chassis number, and color of the vehicles in the report.

FIG. 1E shows another vehicle history report 150 according to an exemplary embodiment. The report includes an existing service alerts portion 151 and a service history portion 152. The existing service alerts 151 include a list of all service alerts currently installed on the vehicle, which may include one or more of an anti-lock brake system alert 153, an engine oil alert 156, a low tire pressure alert 159, a battery alert 154, a secondary collision braking system alert 157, a brake system alert 160, a check engine immediately alert 155, a front airbag alert 158, and a windshield washer fluid and wiper alert 161. The service history portion 152 includes a table with a header area 162 that includes the owner number, purchase date, and vehicle type of the service history. The table includes service item entries for each owner, such as vehicle owner 2. A year column 163 includes a year for each row. A date column 164 includes a date for each row. A total mileage column 165 includes a total mileage for each row. The vendor column 166 contains vendor details for each row, the diagnostic trouble code (DTC) column 167 contains service descriptions for each row, and the comments column 168 contains comments for each row.

For example, for 2020, there were three entries in the service history section 152. The third entry was dated February 6, 2020, and related to an odometer reading of 8,419 miles and the dealer (South Bay Toyota Gardena CA 310-323-7800 southbaytoyota.com) performing an oil and filter change. The second entry was dated February 4, 2020, and related to an odometer reading of 8,400 miles, and the dealer (finance company) indicated the leased vehicle had been returned. The first entry, dated January 1, 2020, relates to an odometer reading of 8,127 miles, and the dealer (California Damage Report) indicated an accident was reported with the airbag deployed. Accident details include damage reported after the accident, the airbag deployment and reported structural damage, and damage to the left side of the quarter post. A photo of the vehicle is included with the damaged area shaded. One 2019 entry, dated May 20, 2019, relates to an odometer reading of 5,690 miles, and the dealer (South Bay Toyota) performed an oil and filter change, a 5,000-mile service, a floor mat check, and verified tire condition and pressure. There is one 2018 entry, dated November 8, 2018, relating to an odometer reading of 3,246 miles and an oil and filter change and battery replacement performed by the dealer (South Bay Toyota).

Figure 1F shows yet another vehicle history report 170 according to an exemplary embodiment. It shows an inspection table with a header area 171 containing service history owner, purchase date, and vehicle type. The table contains inspection entry entries by owner, such as vehicle owner 1. Year column 172 contains a year per row. Date column 173 contains a date per row. Total mileage column 174 contains a total mileage per row. Dealer column 175 contains dealer details per row, DTC column 176 contains a service description per row, and comments column 177 contains comments per row.

For example, there is one inspection entry for fiscal year 2018. According to the South Bay Toyota dealer, this inspection was dated April 23, 2018, and the odometer read 1,825 miles. The vehicle inspection included an oil and filter change, an air filter change, and an exterior light bulb change. There are four inspection entries for fiscal year 2017. According to the South Bay Toyota dealer, the fourth inspection was dated November 27, 2017, and the odometer read 845 miles. This included an oil and filter change, an antifreeze/coolant flush, and a front wiper blade replacement. A third inspection was performed by the California Department of Motor Vehicles on June 20, 2017, when the title was issued or renewed and the oil and filter were changed. On June 7, 2017, the South Bay Toyota dealer sold the vehicle with an odometer reading of 57 miles, and a second inspection was performed. The first service was performed on June 2, 2017, by dealer NICB, when the vehicle was manufactured and shipped to the original dealer.

Reports 130, 150, and 170 may be assembled by the server, for example, into a single report or into two separate reports. Additionally, any of data 131-147, 151-168, and 171-177 may be assembled into one or more reports. Such reports may be provided to one or more of a carrier, a third party (e.g., a vehicle manufacturer, a parts manufacturer, a distributor, a reseller, a ride-share agency, a salvage agency, an individual, etc.), another server, and/or an individual or entity with access to a device capable of receiving and displaying such reports. In one embodiment, one or more of data 131-147, 151-168, and 171-177 may be assembled and/or provided in any format, not necessarily the format illustrated and/or described herein. For example, one or more of the data 131-147, 151-168, and 171-177 may be provided visually, audibly, textually, in a multimedia format, such as via video, to one or more vehicle and/or individual driver devices (e.g., cell phone, wearable device, etc.) while the vehicle is being driven by the driver or occupied by a passenger. In such situations, the server may receive information about the vehicle as it is being driven (or while the vehicle is driving itself, in whole or in part) and provide feedback to modify one or more vehicle or driver behaviors to improve the DPL and/or values associated with the DPL. For example, the server may determine (or be notified) that the vehicle's aggressive driving level/score 142 is increasing. This determination or notification may be based on one or more instances related to hard braking, hard turns, hard acceleration, as well as other factors (not shown), such as swerving, skidding, tailgating, etc. The server may then provide information relating to one or more of such instances, monitor any improvement and/or deterioration, and provide feedback intermittently and/or when aggressive driving has improved to an acceptable level/score.

FIG. 1G illustrates a flowchart 180 according to an exemplary embodiment. In one embodiment, the system can determine the disposition or preferred next use of a vehicle. For example, the system can utilize various attributes of the vehicle to make such a determination. In one embodiment, the system determines which vehicles qualify for preferred next use 182 based on attributes such as time period 1821 (e.g., the date a lease agreement ends, the date a final loan is paid, etc.), the vehicle's current condition 1822, and tolerance threshold 1823 (e.g., a metric measuring the likelihood of maintaining or improving the current condition within the time period). Vehicles within time period 1821 (e.g., six months from the end of the lease) are notified by the system. In another embodiment, vehicles can notify the system of their respective quality requirements, and the system can make an eligibility determination based on various characteristics and attributes of the vehicle.

The system further determines characteristics and attributes of the vehicle that provide a maximum value, which inform the system of preferred next uses, including re-leasing the vehicle, adding the vehicle to a ride-pool program, selling the vehicle, and other uses, such as exchanging the vehicle. In one embodiment, the system provides a notification to a device associated with the vehicle and/or the vehicle owner, operator, and/or occupant, which provides actions that can increase the value of the vehicle by the time period 1821 is completed. The system also determines the current condition 1822 of the vehicle, which is determined by one or more of vehicle performance, vehicle operating behavior, and vehicle maintenance costs, as further described herein. The system determines the acceptability 1823 of the vehicle by determining one or more of whether the vehicle is above or below an acceptable level. For example, if the vehicle is currently in good condition but is being operated in an exceptional manner, it may be useful to send a notification to the vehicle indicating the results of the determination/analysis and what actions, if any, need to be taken to maintain and/or increase the value of the vehicle before the end of the period. If the vehicle is below an acceptable threshold, it may not be beneficial to notify the vehicle because the vehicle's condition and/or performance is below an acceptable level. For example, the vehicle's condition is such that there is no action or course of action that increases the value sufficiently to warrant notification by the system. However, the system may use this information advantageously if the vehicle is presented as part of a potential transaction (e.g., for trade-in).

The system determines data to maximize the value of the vehicle 183 based on distance traveled 1831 (e.g., the current odometer reading is obtained by the system), vehicle non-use 1832 (e.g., the system sends notifications suggesting reduced vehicle use or no use for a period of time to maintain or increase value), and vehicle driving style 1833. In one embodiment, if vehicle non-use is suggested, the system may offer alternative transportation capacity by utilizing a vehicle more suited to such behavior (e.g., a merchant may offer an alternative or shared transportation option in place of the subject vehicle being driven).

The system can notify the vehicle operator (as well as the owner, occupants, etc.) of the data (184), and if the operator is interested in adhering to the recommendations provided by the system, the system continues to monitor the associated thresholds (186) to determine the optimal next use of the vehicle (188).

FIG. 2A illustrates a transportation network diagram 200 according to an exemplary embodiment. The network includes elements including a transportation node 202 including a processor 204, as well as a transportation node 202' including a processor 204'. Transportation nodes 202, 202' communicate with each other via processors 204, 204' and other elements (not shown), including transceivers, transmitters, receivers, storage, sensors, and other elements capable of providing communications. Communication between transportation nodes 202, 202' may be performed directly via private and/or public networks (not shown), or directly via other transportation nodes and elements including one or more of a processor, memory, and software. While illustrated as a single transportation node and processor, multiple transportation nodes and processors may be present. One or more of the applications, features, steps, solutions, etc. described and/or illustrated herein may be utilized and/or provided by elements of the present invention.

FIG. 2B illustrates another vehicle network diagram 210 according to an exemplary embodiment. The network includes elements including a vehicle node 202 including a processor 204, as well as a vehicle node 202' including a processor 204'. The vehicle nodes 202, 202' communicate with each other via the processors 204, 204' and other elements (not shown), including transceivers, transmitters, receivers, storage, sensors, and other elements capable of providing communications. Communication between the vehicle nodes 202, 202' may be performed directly over private and/or public networks (not shown), or directly between other vehicle nodes and elements including one or more of a processor, memory, and software. The processors 204, 204' may 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 vehicle node 222, a computer 224, an input/output device 226, and a voice application 228. Processors 204, 204' may further communicate with elements comprising one or more of a processor, memory, and software.

While illustrated as a single vehicle node, processor, and element, multiple vehicle nodes, processors, and elements may be present. Information or communication may occur between any of processors 204, 204' and element 230. For example, mobile phone 220 may provide information to processor 204, which may activate vehicle node 202 to perform an action and provide further information or additional information to processor 204', which may activate vehicle node 202' to perform an action and provide further information or additional information to mobile phone 220, vehicle node 222, and/or computer 224. One or more of the applications, features, steps, solutions, etc. described and/or illustrated herein may be utilized and/or provided by elements of the present invention.

Figure 2C shows yet another vehicle network diagram 240 according to an exemplary embodiment. The network comprises elements including a node 205 including a processor 204 and a non-transitory computer-readable medium 242C. The processor 204 is communicatively coupled to the computer-readable medium 242C and to element 230 (shown in Figure 2B). The node 205 can be a vehicle, a server, or any device including a processor and memory.

The processor 204 performs one or more of: acquiring data related to the performance of the vehicle 244C; determining a performance level of the vehicle based on the acquired data 246C; dynamically modifying the performance level based on current use of the vehicle 248C; and determining a next use of the vehicle based on the dynamically modified performance level 250C.

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

The processor 204 performs one or more of: dynamically modifying the performance level based on services performed on the vehicle, the services performed including one or more of replacing and upgrading one or more parts on the vehicle (244D); notifying one or more actions that can be performed to increase the performance level of the vehicle, the one or more actions increasing the value of the vehicle (246D); basing the performance level on an evaluation of the condition of the vehicle, the operational behavior of the vehicle, and the maintenance costs of the vehicle during use of the vehicle (248D); and the subsequent use includes one or more of enrolling the vehicle in a leasing program, enrolling the vehicle in a ride-sharing program, and selling the vehicle (250D).

Figure 2E illustrates yet another vehicle network diagram 260, according to an example embodiment. Referring to Figure 2E, network diagram 260 includes node 205 connected to other vehicle nodes 202' and update server node 203 via blockchain network 206. Vehicle nodes 202 and 202' may represent vehicles/vehicles. Blockchain network 206 may include ledger 208 for storing software update verification data and a source of verification for future use (e.g., for audits).

While only one node 205 is described in detail in this example, multiple such nodes may be connected to the blockchain 206. It should be understood that the node 205 may include additional components, and that some of the components described herein may be omitted and/or modified without departing from the scope of the present application. The node 205 may comprise a computing device or server computer, etc., and may include a processor 204, which may be 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. While a single processor 204 is illustrated, it should be understood that the node 205 may include multiple processors, multiple cores, etc., without departing from the scope of the present application. The node 205 may be a vehicle, a server, or any device including a processor and memory.

The processor 204 performs one or more of: receiving validation of the change in performance level, the validation including a blockchain consensus between a peer group of the vehicles and the server (244E); and, based on the blockchain consensus, executing a smart contract to record the validation in the blockchain (246E).

The processor and/or computer-readable medium 242E may reside, in whole or in part, internal or external to the vehicle node. The steps or features stored on the computer-readable medium may be performed, in whole or in part, by any of the processors and/or elements in any order. Furthermore, one or more steps or features may be added, omitted, combined, performed later, etc.

Figure 2F shows yet another vehicle network diagram 261 according to an exemplary embodiment. The network comprises elements including a node 205 including a processor 204 and non-transitory computer-readable medium 242F. Processor 204 is communicatively coupled to computer-readable medium 242F and element 230 (shown in Figure 2B). Node 205 can be a vehicle, a server, or any device including a processor and memory.

The processor 204 performs one or more of receiving characteristics associated with the vehicle within a period of time, the characteristics relating to the vehicle's condition, the vehicle's operational behavior, and the vehicle's maintenance costs (244F), providing one or more actions for the vehicle to perform to increase the level of the characteristics (246F), and determining the next use of the vehicle after the period of time in response to the increasing level of the characteristics (248F).

In another embodiment, the server sends a notification to the vehicle containing one or more actions that can increase the value of the vehicle within a certain period of time, verifies that the one or more actions have been performed on the vehicle, and determines the next use of the vehicle after a certain period of time based on the verification.

Figure 2G shows yet another vehicle network diagram 262 according to an exemplary embodiment. The network comprises elements including a node 205 including a processor 204 and a non-transitory computer-readable medium 242G. The processor 204 is communicatively coupled to the computer-readable medium 242G and to element 230 (shown in Figure 2B). The node 205 may be a vehicle, a server, or any device including a processor and memory.

The processor 204 performs one or more of: selecting a vehicle ahead of time based on terms and tolerance thresholds associated with the vehicle 244G; the one or more actions including changes to reduced vehicle use, changes to the vehicle's operating method, and vehicle maintenance 245G; monitoring the characteristics as the vehicle is being operated and providing one of the characteristics to the vehicle at a minimum level 246G; monitoring the characteristics as the vehicle is being driven and providing one of the characteristics to the vehicle at a minimum level 247G; receiving a request from the vehicle to increase the level of the characteristics and providing one or more actions to perform based on the vehicle's current use 248G; and monitoring the characteristics as the vehicle is being driven and providing one of the characteristics to the vehicle at a minimum level 249G. In one embodiment, the term "current use" may mean currently operated by a driver and/or owner and/or currently owned by a driver and/or owner, and the term "next use" may mean use after the current term (e.g., lease) is completed.

Figure 2H shows a diagram 265 representing the provision of power to one or more elements. In one embodiment, a vehicle 266 may provide power stored in its batteries to one or more elements, including other vehicles 268, charging stations 270, and a power grid 272. The power grid 272 is coupled to one or more charging stations 270, which may be coupled to one or more of the vehicles 268. This configuration allows for the distribution of electricity/power received from the vehicle 266. The vehicle 266 may also interact with the other vehicles 268 via vehicle-to-vehicle (V2V) technology, cellular communications, Wi-Fi, etc. The vehicle 266 may also interact with the other vehicles 268, charging stations 270, and/or the power grid 272 wirelessly and/or via wires. In one embodiment, vehicle 266 is routed (or routes itself) to power grid 272, charging stations 270, or other vehicles 268 in a safe and efficient manner. Using one or more embodiments of the present solution, vehicle 266 can provide energy to one or more of the elements illustrated herein in a variety of advantageous ways, as described and/or illustrated herein. Additionally, vehicle safety and efficiency may be enhanced, and environmental impact may be positively impacted, as described and/or illustrated herein.

The term "energy" may be used to refer to any form of energy received, stored, used, shared, and/or lost by a vehicle. Energy may be referred to in connection with a charging voltage and/or current supply provided to a vehicle from an entity during a charging/use operation. Energy may also be in the form of fossil fuels (e.g., for use in hybrid vehicles), via alternative power sources including, but not limited to, lithium-based batteries, nickel-based batteries, hydrogen fuel cells, atomic/nuclear energy, and fusion-based energy sources, or energy generated on the fly during energy sharing and/or use operations to increase or decrease the energy level of one or more vehicles at a given time.

In one embodiment, charging station 270 manages the amount of energy transferred from vehicle 266 so that vehicle 266 remains sufficiently charged to reach its destination. In one embodiment, a wireless connection is used to wirelessly direct the amount of energy transferred between vehicles 268, where both vehicles may be moving. In one embodiment, an idle vehicle, such as vehicle 266 (which may be autonomous), is instructed to provide a predetermined amount of energy to charging station 270 and return to its original location (e.g., its original location or another destination). In one embodiment, a mobile energy storage unit (not shown) is used to collect excess energy from at least one other vehicle 268 and transfer the stored excess energy to charging station 270. In one embodiment, factors such as distance, time, traffic conditions, road conditions, environmental/weather conditions, vehicle conditions (e.g., weight), occupant schedule while using the vehicle, and schedules of potential occupants waiting for the vehicle are used to determine the amount of energy to transfer to charging station 270. In one embodiment, vehicle 268, charging station 270, and/or power grid 272 may provide energy to vehicle 266.

In one embodiment, the solutions described and illustrated herein can be used to determine load impacts on a vehicle and/or system, provide energy to a vehicle and/or system based on future needs and/or priorities, and provide confidential information between a device including a module and a vehicle that enables a processor in the device to wirelessly communicate with the vehicle regarding the amount of energy stored in the vehicle's battery. In one embodiment, the solutions can also be used to provide charge from a 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 used to manage the amount of energy remaining in a vehicle after a portion of the charge has been transferred to a charging station. In one embodiment, the solutions can also be used to notify the vehicle to provide an amount of energy from a battery on the vehicle, where the amount of energy to transfer is based on the distance from the vehicle to the module receiving the energy.

In one embodiment, the solution may also be utilized to use a mobile energy storage unit to travel to a vehicle with excess energy using the determined route and deposit the stored energy in the grid. In one embodiment, the solution may also be utilized to determine the priority of the vehicle's determination of the need to provide energy to the grid and the priority of the vehicle's current needs, such as the priority of the occupant or next occupant, or the priority of the current or next cargo. In one embodiment, the solution may also be utilized to determine, when the vehicle is idling, to maneuver the vehicle to a predetermined location to discharge excess energy into the energy grid and then decide to return to the previous location. In one embodiment, the solution may also be utilized to determine the amount of energy needed by a vehicle to provide the required energy to another vehicle via an energy transfer from vehicle to vehicle based on one or more conditions, such as weather, traffic, road conditions, vehicle conditions, and the occupants and/or goods of the other vehicle, and to instruct the vehicle to route to the other vehicle to provide the energy. In one embodiment, the solution may also be used to transfer energy from one moving vehicle to another moving vehicle. In one embodiment, the solution may also be used to recover energy by a vehicle based on the energy consumed by the vehicle to reach and provide service at a rendezvous point with another vehicle and the estimated energy consumed to return to the original location. In one embodiment, the solution may also be used to provide a required remaining distance to a charging station, which may determine the amount of energy to recover from the vehicle, where the remaining charge is based on the remaining distance. In one embodiment, the solution may also be used to manage a vehicle being charged by multiple points simultaneously, such as both a charging station via a wired connection and another vehicle via a wireless connection. In one embodiment, the solution may also be used to apply priorities to energy distribution to vehicles, where priority is given to such vehicles that will provide a portion of their stored charge to another entity, such as a power grid, a residence, or the like. Furthermore, the solution of the present invention described and illustrated with respect to FIG. 2H may be used in networks and/or systems, including this network and/or system.

FIG. 2I illustrates the interconnections between different elements 275. The solution of the present invention may be associated with various entities, all communicatively coupled to a network 286, and may be stored in whole or in part on and/or executed by one or more communicating computing devices 278′, 279′, 281′, 282′, 283′, 284′, 276′, 285′, 287′, and 277′. A database 287 is communicatively coupled to the network and allows for data storage and retrieval. In one embodiment, the database is an immutable ledger. One or more of the various entities may be a vehicle 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructure 282, one or more residences 283, a power grid/charging station 284, a microphone 285, and/or another vehicle 277. Other entities and/or devices, such as one or more individual users using smartphone 278, laptop 280, and/or wearable devices, may also interact with the solution of the present invention. Smartphone 278, laptop 280, microphone 285, and other devices may be connected to one or more of connected computing devices 278′, 279′, 281′, 282′, 283′, 284′, 276′, 285′, 287′, and 277′. One or more public buildings 281 may include various agencies. One or more public buildings 281 may utilize computing device 281′. One or more service providers 279 may include dealerships, tow truck services, collision centers, or other repair shops. One or more service providers 279 may utilize computing device 279′. These various computing devices may be directly and/or communicatively coupled to one another via wired networks, wireless networks, blockchain networks, etc. In one embodiment, microphone 285 may be utilized as a virtual assistant. In one embodiment, one or more traffic infrastructures 282 may include one or more traffic signals, one or more sensors including one or more cameras, vehicle speed sensors or traffic sensors, and/or other traffic infrastructure. One or more traffic infrastructures 282 may utilize a computing device 282'.

In one embodiment, vehicles 277/276 may transport people, objects, permanently or temporarily attached equipment, etc. In one embodiment, vehicles 277 may communicate with vehicles 276 via V2V communications via a computer associated with each vehicle 276' and 277' and may be referred to as a vehicle, car, vehicle, automobile, etc. Vehicles 276/277 may be self-propelled wheeled vehicles such as automobiles, sport utility vehicles, trucks, buses, vans, or other motor- or battery- or fuel-cell-powered vehicles. For example, vehicles 276/277 may be electric vehicles, hybrid vehicles, hydrogen fuel cell vehicles, plug-in hybrid vehicles, or any other type of vehicle having a fuel cell stack, motor, and/or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, or boats, and other forms of vehicles capable of transportation. Vehicles 276/277 may be semi-autonomous or autonomous. For example, vehicles 276/277 may be on autopilot and navigate without human input. An autonomous vehicle may have and use one or more sensors and/or navigation units to drive autonomously.

In one embodiment, the solutions described and illustrated herein may be utilized to determine access to a vehicle via blockchain consensus. In one embodiment, the solutions may also be utilized to perform profile verification before allowing a vehicle occupant to use the vehicle. In one embodiment, the solutions may also be utilized to display (visually, in yet another embodiment, verbally, etc.) actions that a user must perform (possibly pre-recorded) on or from the vehicle, and verify that the actions are correct. In one embodiment, the solutions may also be utilized to provide the vehicle with the ability to determine how to bifurcate data based on the risk level associated with the data and the driving environment, delivering a portion of the bifurcate data to the occupant at a lower risk level during a safe driving environment, and then delivering the remaining portion of the bifurcate data to the occupant at a higher risk level after the occupant leaves the vehicle. In one embodiment, the solutions may also be utilized to process vehicle movement across borders (country/state/etc.) using blockchain and/or smart contracts and apply the rules of the new area to the vehicle.

In one embodiment, the solution may also be used to allow a vehicle to continue operating outside of a boundary when the vehicle reaches a consensus based on vehicle operation and vehicle occupant characteristics. In one embodiment, the solution may also be used to analyze the vehicle's available data upload/download rate, file size, and the speed/direction the vehicle is traveling to determine the distance required to complete the data upload/download and assign a safe area boundary for performing the data upload/download. In one embodiment, the solution may also be used to instruct the subject vehicle, as well as other nearby vehicles, to allow the subject vehicle to exit in a safe manner when the system determines that an exit is approaching or if the vehicle does not appear ready to exit the exit (e.g., is traveling in the wrong lane or traveling at a speed inappropriate for the next exit). In one embodiment, the solution may also be used to verify the diagnosis of another vehicle using one or more vehicles while both the one or more vehicles and the other vehicle are in motion.

In one embodiment, the solution may also be used to detect lane usage at a given location and time and instruct the vehicle to notify the occupant or to recommend or not recommend a lane change. In one embodiment, the solution may also be used to eliminate the need to send information via email and for the driver/occupant to respond by emailing or making a payment in person. In one embodiment, the solution may also be used to provide services to the vehicle occupant, where the services provided are subscription-based and authorization is obtained from other vehicles connected to the occupant's profile. In one embodiment, the solution may also be used to record changes in the status of rentals. In one embodiment, the solution may also be used to seek blockchain consensus from other vehicles in proximity to a damaged vehicle. In one embodiment, the solution may also be used to receive media from a vehicle computer that may be related to the accident, such as from an insurance company server. The server may access one or more media files to access damage to the vehicle and store a damage assessment on the blockchain. In one embodiment, the solution can also be utilized to obtain consensus for determining the severity of an event from multiple devices over various periods of time prior to a vehicle-related event.

In one embodiment, the solution may also be used to solve the problem of a lack of video evidence of vehicle-related accidents. The current solution provides details of media inquiries by vehicles involved in the accident from other vehicles that may have been in the vicinity of the accident. In one embodiment, the solution may also be used to record specific portions of the damaged vehicle using vehicles and other devices (e.g., pedestrian cell phones, street light cameras, etc.).

In one embodiment, the solution may also be utilized to warn occupants when a vehicle is moving toward a dangerous area and/or event, enabling the vehicle to notify the occupants or a central controller of potentially dangerous areas on or near the current vehicle route. In one embodiment, the solution may also be utilized to use at least one other vehicle when the vehicle is traveling at high speed to assist in slowing the vehicle in a manner that minimizes impact on traffic. In one embodiment, the solution may also be utilized to identify dangerous driving situations in which media 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 may also be utilized to send a notification to one or more occupants of a vehicle that the vehicle is approaching a traffic control sign on a road, and then receive indications of poor driving from other nearby vehicles if the vehicle crosses the sign. In one embodiment, solutions can also be utilized to partially disable a vehicle by (in certain embodiments) limiting speed, limiting the ability to be near another vehicle, limiting speed to a maximum, and only allowing a given number of miles per time period.

In one embodiment, the solution may also be utilized to overcome the need to rely on software updates to correct vehicle problems when the vehicle is not operating correctly. Monitoring other vehicles along a route results in a server receiving data from multiple other vehicles that may be monitoring the vehicle for unsafe or improper operation. Through analysis, such observations may result in notifications to the vehicle if the data indicates unsafe or improper operation. In one embodiment, the solution may also be utilized to provide notifications between the vehicle and potentially dangerous situations affecting persons outside the vehicle. In one embodiment, the solution may also be utilized to transmit data to a server by devices related to or proximate to a vehicle incident. The server notifies the sender of the data based on the severity of the accident or near-accident. In one embodiment, the solution may also be utilized to provide recommendations for operating the vehicle to either the driver or passengers of the vehicle based on an analysis of the data. In one embodiment, the solution may also be utilized to establish geofences associated with physical structures and determine the ability to pay for the vehicle. In one embodiment, the solution may also be utilized to coordinate the ability to drop off a vehicle at a given location using both the current state at the location and the proposed future state using the navigation destinations of other vehicles. In one embodiment, the solution may also be utilized to coordinate the ability to automatically arrange for a vehicle to be dropped off at a given location, such as with a transportation rental entity.

In one embodiment, the solution can also be used to move the vehicle to a different location based on a user event. More specifically, the system tracks the user's device and modifies the vehicle to move closer to the user upon completion of the original or modified event. In one embodiment, the solution can also be used to enable verification of available locations in an area via existing vehicles in the area. Additionally, an approximate time when a location may become available is determined based on verification from existing vehicles. In one embodiment, the solution can also be used to move the vehicle closer to a parking spot when parking becomes available and the elapsed time since initial parking is shorter than the average time of the event. Furthermore, the vehicle is moved to a final parking spot when the event is completed or according to the location of a device associated with at least one occupant of the vehicle. In one embodiment, the solution can also be used to plan parking ahead of the next busy period. The system can interact with the vehicle to offer some services at lower than the regular rate and/or direct users to alternative parking locations based on vehicle priority to improve pre-arrival parking optimization.

In one embodiment, the solution may also be used to sell fractional ownership of a vehicle or to determine pricing and availability in ride-sharing applications. In one embodiment, the solution may also be used to provide accurate and timely reporting of a merchant's sales activity, far beyond what is currently available. In one embodiment, the solution may also be used to enable a merchant to claim assets via the blockchain. By using the blockchain, consensus is reached before any asset is moved. Furthermore, the process is automated, and payments may be initiated via the blockchain. In one embodiment, the solution may also be used to coordinate agreements between multiple entities (e.g., service centers) where consensus is reached and actions (e.g., diagnostics) are performed. In one embodiment, the solution may also be used to associate digital keys with multiple users. A first user may be the operator of the vehicle, and a second user is responsible for the vehicle. Such keys are authorized by a server where the proximity of the keys is verified to the location of the service provider. In one embodiment, the solution may also be used to determine services required at the destination of the vehicle. One or more service locations that can provide the required service and are within the area on the route to the destination and have the availability to perform the service are searched for. The vehicle navigation is updated with the determined service locations. A smart contract containing the compensation value for the service is identified, and the blockchain transaction is stored in a distributed ledger of transactions.

In one embodiment, the solution may also be utilized to enable a service provider's vehicle to interact with a vehicle occupant's profile to determine services and products that the vehicle occupant may be interested in. Such services and products may be determined by the occupant's history and/or preferences. The vehicle then receives an offer from the service provider's vehicle and, in another embodiment, contacts the vehicle to provide the service/product. In one embodiment, the solution may also be utilized to detect vehicles within a predetermined range and send service offers (e.g., maintenance offers, product offers) to the vehicle. Agreements are established between the system and the vehicle, and the system selects a service provider to provide the agreement. In one embodiment, the solution may also be utilized to assign one or more vehicles as road managers, where the road managers assist in traffic control. The road managers may generate road signs (e.g., lights, displays, sounds) to assist traffic flow. In one embodiment, the solution may also be utilized to alert the vehicle driver via a device, where the device may be a traffic signal or a device near an intersection. An alert is sent when an event occurs, such as the traffic light turning green but the vehicle at the top of the vehicle list not moving.

FIG. 2J is another block diagram illustrating the interconnections between different elements in an example 290. A vehicle 276 is presented and includes ECUs 295, 296 and a head unit 297 (otherwise known as an infotainment system). An electronic control unit (ECU) is a system integrated into automotive electronics that controls one or more of the vehicle's electrical systems or subsystems. ECUs include, but are not limited to, managing the 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 vehicle's Controller Area Network (CAN) bus 294. The ECU may also communicate with a vehicle computer 298 via the CAN bus 294. The vehicle's processor/sensors (e.g., vehicle computer) 298 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 may contain its own security policy. The security policy defines the allowable processes that can be performed in the appropriate context. In one embodiment, the security policy may be provided in part or in whole to the vehicle computer 298.

ECUs 295, 296 and head unit 297 may each include custom security function elements 299 that define authorized processes and the contexts in which such processes are permitted to run. Context-based authorization, which determines whether a process can be executed, allows 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, it can prevent the process from operating. The onboard ECU can use various contexts, such as proximity contexts such as nearby objects, distance to approaching objects, speed, and relative trajectory to other moving objects; operational contexts such as an indication of whether the vehicle is moving or parked, the vehicle's current speed, and transmission status; devices connected to the vehicle via wireless protocols; user-related contexts such as infotainment usage, cruise control, parking assistance, driving assistance; location-based contexts; and/or other contexts, to determine whether a process is operating within its permitted scope.

In one embodiment, the solution described and illustrated herein can be utilized to partially disable a vehicle by (in certain embodiments) limiting speed, limiting the ability to be near another vehicle, limiting speed to a maximum, and only allowing a given number of miles per time period. In one embodiment, the solution can also be utilized to facilitate vehicle ownership exchange using blockchain, where data is sent to a server by either a device related to a vehicle accident or a device near the accident. The server notifies the sender of the data based on the severity of the accident or near-accident. In one embodiment, the solution can also be utilized to assist a vehicle in avoiding an accident, for example, by the server querying other vehicles in the vicinity of the accident if the vehicle is involved in an accident. The server attempts to obtain data from the other vehicles, allowing the server to understand the nature of the accident from multiple vantage points. In one embodiment, the solution can also be utilized to determine that a sound from the vehicle is anomalous and send data related to the sound, as well as potential sound source locations, to a server. The server can then determine possible causes and avoid potentially dangerous situations. In one embodiment, the solution can also be utilized to establish a location boundary through the system when a vehicle is involved in an accident. The boundary is based on noise associated with the accident. Multimedia content of devices within the boundary is captured to help further understand the circumstances of the accident. In one embodiment, the solution can also be utilized to associate a vehicle with an accident and then capture media captured by devices in the vicinity of the accident location. The captured media is saved as media segments. The media segments are sent to another computing device that creates an audio profile of the accident. This audio profile can help further understand the details surrounding the accident.

In one embodiment, the solution may also be utilized to utilize sensors to record audio, video, motion, etc. to record areas where a potential event has occurred, such as when a vehicle comes into or may come into contact with another vehicle (whether moving or parked), and the system captures data from sensors that may be present on the vehicle and/or one or more of the fixed or movable objects. In one embodiment, the solution may also be utilized to use sensor data to identify a new state of the vehicle during a vehicle event and compare that state to a vehicle state profile to determine if the vehicle has been damaged, allowing for the safe and secure capture of critical data from vehicles likely to be involved in an adverse event.

In one embodiment, the solution can also be used to alert a vehicle occupant when the vehicle, via one or more sensors, determines that it is approaching a one-way street or traveling in the wrong direction on a one-way street. The vehicle has sensors/cameras/maps that interact with the system of the current solution. The system knows the geographic location of one-way streets. The system may, for example, audibly notify the occupant, "Approaching a one-way street." In one embodiment, the solution can also be used to enable payments for vehicles. This allows autonomous vehicle owners to monetize the data collected and stored by each vehicle sensor, creating incentives for vehicle owners to share their data and provide additional data to entities. This can improve the performance of future vehicles and provide services to vehicle owners and others.

In one embodiment, the solution may also be utilized to increase or decrease vehicle characteristics according to vehicle behavior over a period of time. In one embodiment, the solution may also be utilized to assign fractional ownership to a vehicle. Sensor data associated with one or more vehicles and devices proximate to the vehicle is used to determine the state of the vehicle. Fractional ownership of the vehicle is determined based on the state and provides new responsibility for the vehicle. In one embodiment, the solution may also be utilized to provide data to a replacement/modification component, where the data attempts to disrupt authorized functionality of the replacement/modification component and, in response to non-disruption of the authorized functionality, allows the component to use authorized functionality of the replacement/modification component.

In one embodiment, the solution can also be used to provide an individual with the ability to ensure that a passenger is present in the vehicle and that the passenger reaches a specific destination. Additionally, the system ensures that the driver (in the case of a non-autonomous vehicle) and/or other passengers are authorized to interact with the passenger. Also, pickup, drop-off, and location information is provided. All of the above is immutably stored on the blockchain. In one embodiment, the solution can also be used to determine driver characteristics through analysis of factors such as driving style, and take action if the driver is not driving in a normal manner, e.g., how the driver has driven before in certain conditions, such as during the day, at night, in rain, or snow. Additionally, vehicle attributes are considered. Attributes include weather, whether headlights are on, whether navigation is in use, whether a HUD is in use, the volume of media being played, etc. In one embodiment, the solution can also be used to notify passengers in the vehicle of a dangerous situation if items in the vehicle indicate that the passenger may not be aware of the situation.

In one embodiment, the solution can also be used to attach a calibration device to fixed equipment on the vehicle, where various sensors on the vehicle can automatically self-calibrate based on what should be detected by the calibration device compared to what is actually detected. In one embodiment, the solution can also be used to use blockchain to request consensus from multiple service centers when a vehicle requiring service sends malfunction information, enabling remote diagnostic capabilities. Here, consensus from other service centers is required as to what the severity threshold for the data is. Once consensus is received, the service center may send and store the security level of the malfunction on the blockchain. In one embodiment, the solution can also be used to determine the difference between sensor data external to the vehicle and sensor data on the vehicle itself. The vehicle requests software from a server to correct the problem. In one embodiment, the solution can also be used to enable message exchange for vehicles near or within an area when an event (e.g., a collision) occurs.

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

Processor 296A may include an arithmetic logic unit, microprocessor, general purpose controller, and/or similar processor array that performs calculations and provides electronic display signals to display unit 299A. Processor 296A processes data signals and may include a variety of computing architectures, including complex instruction set computer (CISC) architecture, reduced instruction set computer (RISC) architecture, or architectures implementing a combination of instruction sets. Vehicle 276 may include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not shown) communicatively coupled to each other may also be used with the solutions of the present invention.

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

Memory 297A of vehicle 276 may store one or more of the following types of data: navigation route data 295A and autonomous feature data 294A. In some embodiments, memory 297A stores data that may be necessary for navigation application 295A to provide functionality.

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

ECU 293A controls the operation of many of the systems of vehicle 276, including ADAS system 294A. In response to commands received from navigation system 295A, ECU 293A may disable any unsafe and/or unselected autonomous features during a journey controlled by ADAS system 294A. In this manner, navigation system 295A controls whether ADAS system 294A is enabled or enabled, and as a result, ADAS system 294A may be enabled for a given navigation route.

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

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

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

In one embodiment, the solution described and illustrated herein may be utilized to manage emergency situations and vehicle characteristics when a vehicle is determined to be entering an area without network access. In one embodiment, the solution may also be utilized to manage and provide vehicle characteristics (e.g., audio, video, navigation, etc.) without a network connection. In one embodiment, the solution may also be utilized to determine when a profile of a person in proximity to the vehicle matches profile attributes of a profile of at least one occupant within the vehicle. A notification is sent from the vehicle to establish communication.

In one embodiment, the solution may also be used to analyze the availability of occupants of each vehicle available for voice communication based on the vehicle's remaining time and the context of the communication being conducted. In one embodiment, the solution may also be used by vehicles along a road to determine two levels of threat for road obstacles and receive gestures that may indicate that an obstacle continues to not rise above a threshold warning. In one embodiment, the solution may also be used to delete sensitive data from a vehicle if the vehicle is damaged and rendered unusable.

In one embodiment, the solution may also be utilized to verify that customer data targeted for deletion has actually been deleted from all necessary locations within a GDPR-compliant enterprise. In one embodiment, the solution may also be utilized to provide decisions from one vehicle to another vehicle in exchange for data related to safety, important notifications, etc., to enhance the autonomy capabilities of a lower-level autonomous vehicle. In one embodiment, the solution may also be utilized to provide the vehicle with the ability to receive data based on a first biometric associated with the occupant. The vehicle then decrypts the encrypted data based on verification of a second biometric, where the second biometric is continuum with the first biometric. The vehicle provides unencrypted data to the occupant when only the occupant can receive it, and deletes the sensitive portion of the unencrypted data when the sensitive portion is provided and the non-sensitive portion after a time period associated with the biometric has elapsed. In one embodiment, the solution may also be utilized to provide the vehicle with the ability to verify an individual based on weight and grip force applied to the vehicle's handle. In one embodiment, the solution can also be utilized to provide existing, but currently unenabled, features to automobiles that present characteristics to the automobile's occupants that reflect the characteristics of the occupants.

In one embodiment, the solution may also be utilized to enable the vehicle to reflect changes in the vehicle's interior, in particular the vehicle's interior, as well as the vehicle's exterior, and in one embodiment, to assist at least one occupant. In another embodiment, replicating a vehicle occupant's work and/or home environment is disclosed. If the system determines that the user is in "work mode" or "home mode," the system may attempt to "recreate" the user's work/home environment while the user is within the vehicle. All data related to the vehicle's interior and exterior, as well as various occupants using the vehicle, is stored on a blockchain and executed via smart contracts. In one embodiment, the solution may also be utilized to detect occupant gestures and assist in communication with nearby vehicles that may maneuver the vehicle accordingly. In one embodiment, the solution may also be utilized to provide the vehicle with the ability to detect intended gestures using a gesture definition data store. In one embodiment, the solution may also be utilized to provide the vehicle with the ability to perform various actions based on the user's gait and gestures. In one embodiment, the solution can also be utilized to ensure that a vehicle driver currently engaged in various operations (e.g., driving while navigating and talking) does not exceed a dangerous number of operations before being allowed to gesture.

In one embodiment, the solution may also be utilized to assign a status to each vehicle occupant and verify gestures from the occupant based on the occupant's status. In one embodiment, the solution may also be utilized to collect details of sounds associated with a collision (such as where, in which direction, ascending or descending, from which device, data related to the device such as type, manufacturer, owner, number of sounds occurring simultaneously, time of day the sounds were emitted, etc.) and provide them to a system where analysis of the data helps determine details about the collision. In one embodiment, the solution may also be utilized to provide a determination that vehicle operation is unsafe. The vehicle includes multiple components that interoperate to control the vehicle, each component associated with a separate component key. An encryption key is sent to the vehicle to degrade vehicle functionality. The vehicle disables one or more of the component keys in response to receiving the encryption key. Disabling one or more component keys will result in one or more of the following: restricting the vehicle from traveling more than a given speed; restricting the vehicle from coming closer to another vehicle than a certain distance; and restricting the vehicle from traveling more than a threshold distance.

In one embodiment, the solution can also be used to provide instructions from one specific vehicle (trying to vacate a location) to another specific vehicle (trying to occupy a location), using blockchain for authentication and coordination. In one embodiment, the solution can also be used to determine partial ownership of a vehicle, such as when multiple people own a vehicle and usage of the vehicle, which can vary over time, is used by the system to update partial ownership. Other embodiments would include applications involving minimal ownership of a vehicle based on vehicle availability and vehicle driver determination, rather than vehicle usage.

In one embodiment, the solution can also be used to allow users in a vehicle to become members of closed groups of people, such as family or friends. For example, if a user may want to share their membership, the associated transaction can be stored in a blockchain or traditional database. When a signed document is requested by a user other than the original signer, the blockchain node (i.e., the vehicle) can verify that the person requesting the service is an authorized person who shares a profile with the signer. In one embodiment, the solution can also be used to allow a person to use a supplemental vehicle to reach their intended destination. Functional relationship values (e.g., values indicating various parameters and their importance in determining the type of alternative vehicle to use) are used to determine the supplemental vehicle. In one embodiment, the solution can also be used to allow occupants involved in an accident to access other vehicles to continue to their original destination.

In one embodiment, the solution may also be used to propagate software/firmware uploads to a first subset of vehicles. This first set of vehicles checks for the update, and if the check is successful, the update is propagated to additional sets of vehicles. In one embodiment, the solution may also be used to propagate software/firmware updates from a master vehicle to vehicles. Here, the update is propagated through a network of vehicles from the first subset, then a larger subset, and so on. A portion of the update may be sent first, and then the remaining portion may be sent from the same vehicle or another vehicle. In one embodiment, the solution may also be used to provide vehicle computer updates to the vehicle and vehicle operator/occupant devices. The update may be authorized by all drivers and/or all occupants. The software update is provided to the vehicle and the device. The user does not need to do anything; the function occurs automatically upon proximity to the vehicle. A notification is sent to the device indicating the software update is complete. In one embodiment, the solution may also be utilized to verify that an OTA software update was performed by a qualified technician and generate a status by one or more vehicle components relating to the origin of a verification code, the procedure for receiving the software update over the air, the information contained in the software update, and the results of the verification.

In one embodiment, the solution may also be utilized to provide the ability for a second component to analyze software updates in a first component, then verify a first portion of critical updates and a second portion of non-critical updates, assign the verified first portion to one process within the vehicle, implement the verified first portion in one process for a period of time, and, responsive to a positive result based on the period of time, implement the verified first portion in another process after the period of time. In one embodiment, the solution may also be utilized to provide a selection of services to the vehicle occupant, where the services are based on a profile of the vehicle occupant and a shared profile shared with the occupant's profile. In one embodiment, the solution may also be utilized to store user profile data on a blockchain and intelligently present offers and recommendations to the user based on the user's automatically collected purchasing history and preferences obtained from the user profile on the blockchain.

To adequately secure a vehicle, the vehicle must be protected from unauthorized physical access as well as unauthorized remote access (e.g., cyber threats). In one embodiment, to prevent unauthorized physical access, the vehicle is equipped with a secure access system, such as keyless entry. Meanwhile, in one embodiment, security protocols are added to the vehicle's computers and computer networks to facilitate secure remote communications to and from the vehicle.

Electronic control units (ECUs) are nodes within a vehicle that control tasks ranging from operating the windshield wipers to the anti-lock braking system. ECUs are often connected to each other through the vehicle's central network, sometimes called a Controller Area Network (CAN). Cutting-edge features such as autonomous driving rely heavily on the implementation of new, complex ECUs, including advanced driver assistance systems (ADAS), sensors, and more. While these new technologies help improve vehicle safety and the driving experience, they also increase the number of external communication units within the vehicle, making it more vulnerable to attack. Below are some examples of securing vehicles from both physical and communication-line intrusions:

Figure 2L illustrates a keyless entry system 290B for preventing unauthorized physical access to a vehicle 291B, according to an exemplary embodiment. Referring to Figure 2L, in one embodiment, a key fob 292B transmits commands to the vehicle 291B using radio frequency signals. In this example, the key fob 292B includes a transmitter 2921B with an antenna capable of transmitting short-range radio signals. The vehicle 291B includes a receiver 2911B with an antenna capable of receiving the short-range radio signals transmitted from the transmitter 2921B. The key fob 292B and the vehicle 291B also include CPUs 2922B and 2913B, respectively, that control their respective devices. Here, this refers to memory (or memory accessible to the CPUs) of the CPUs 2922B and 2913B. In one embodiment, the key fob 292B and the vehicle 291B each include a power source 2924B and 2915B for powering their respective devices.

When a user presses button 293B on key fob 292B (or otherwise activates the fob, etc.), CPU 2922B activates within key fob 292B and transmits a data stream to transmitter 2921B, which is output via an antenna. The data stream may be a 64- to 128-bit signal that includes one or more of a preamble, a command code, and a rolling code. The signal may be transmitted at a rate between 2 KHz and 20 KHz, although embodiments are not limited to this rate. In response, receiver 2911B of vehicle 291B captures the signal from transmitter 2921B, demodulates the signal, and transmits the data stream to CPU 2913B, which decodes the signal and transmits a command (e.g., lock doors, unlock doors, etc.) to command module 2912B.

If key fob 292B and vehicle 291B use a fixed code between them, a replay attack can be performed. In this case, if an attacker can capture/intercept the fixed code during short-range communication, the attacker can replay this code and break into vehicle 291B. For improved security, key fob 292B and vehicle 291B may use a rolling code that changes with each use. Here, key fob 292B and vehicle 291B are synchronized with an initial seed 2923B (e.g., a random number, a pseudo-random number, etc.). This is called pairing. Key fob 292B and vehicle 291B also contain a shared algorithm for changing initial seed 2914B each time button 293B is pressed. The next key press will take the result of the previous key press as input and convert it to the next number in the sequence. In some cases, vehicle 291B may store multiple next codes (e.g., 255 next codes) in the event that a key press on key fob 292B is not detected by vehicle 291B. Thus, multiple key presses on key fob 292B that vehicle 291B does not recognize will not prevent the vehicle from becoming unsynchronized.

In addition to rolling codes, key fob 292B and vehicle 291B may employ other methods to make attacks more difficult. For example, different frequencies may be used to transmit the rolling codes. As another example, two-way communication between transmitter 2921B and receiver 2911B may be used to establish a secure session. As another example, the codes may have a limited expiration or timeout. Furthermore, the inventive solution described and illustrated with respect to FIG. 2L may be utilized in this and other networks and/or systems, including those described and illustrated herein.

FIG. 2M illustrates a controller area network (CAN) 290C within a vehicle, according to an exemplary embodiment. Referring to FIG. 2M, CAN 290C includes a CAN bus 297C having high and low terminals and multiple electronic control units (ECUs) 291C, 292C, 293C, etc., connected to CAN bus 297C via wired connections. CAN bus 297C is designed to allow microcontrollers and devices to communicate with each other within an application without a host computer. CAN bus 297C implements a message-based protocol (i.e., the ISO 11898 standard) that allows ECUs 291C-293C to send commands to each other at the route level. Meanwhile, ECUs 291C-293C represent controllers that control electrical systems or subsystems within the vehicle. Examples of electrical systems include power steering, anti-lock braking, air conditioning, tire pressure monitoring, cruise control, and many other features.

In this example, ECU 291C includes a transceiver 2911C and a microcontroller 2912C. The transceiver may be used to send and receive messages to and from CAN bus 297C. For example, transceiver 2911C may convert data from microcontroller 2912C into a format for CAN bus 297C and may also convert data from CAN bus 297C into a format for microcontroller 2912C. However, in one embodiment, microcontroller 2912C interprets messages and determines which messages to send using ECU software installed on the microcontroller.

Various security protocols may be implemented to protect CAN 290C from cyber threats. For example, subnetworks (e.g., subnetworks A and B) may be used to divide CAN 290C into smaller sub-CANs, limiting an attacker's ability to remotely access the vehicle. In the example of FIG. 2M, ECUs 291C and 292C may be part of the same subnetwork, while ECU 293C is part of a separate subnetwork. Additionally, a firewall 294C (or gateway, etc.) may be added to prevent messages from crossing subnetworks and traversing CAN bus 297C. If an attacker gains access to one subnetwork, the attacker does not gain access to the entire network. To further secure the subnetworks, in one embodiment, the most critical ECUs are not placed in the same subnetwork.

Although not shown in Figure 2M, other examples of security controls within the CAN include an Intrusion Detection System (IDS) that can be added to each sub-network and can read all passing data to detect malicious messages. If a malicious message is detected, the IDS can notify the vehicle user. Other possible security protocols include encryption/security keys that can be used to hide messages. As another example, in one embodiment, an authentication protocol is implemented that allows a message to authenticate itself.

In addition to protecting a vehicle's internal network, the vehicle may also be protected when communicating with external networks, such as the Internet. One advantage of connecting the vehicle to data sources, such as the Internet, is that information from the vehicle can be transmitted over the network to a remote location for analysis. Examples of vehicle information include GPS, on-board diagnostics, tire pressure, and the like. Such communication systems are often referred to as telematics, as they involve a combination of telecommunications and informatics. Furthermore, the solution of the present invention described and illustrated with respect to FIG. 2M may be utilized in this and other networks and/or systems, including those described and illustrated herein.

FIG. 2N illustrates a secure end-to-end vehicle communication channel according to an exemplary embodiment. Referring to FIG. 2N, telematics network 290D includes vehicle 291D and host server 295D located at a remote location (e.g., a web server, cloud platform, database, etc.) and connected to vehicle 291D via a network such as the Internet. In this example, device 296D associated with host server 295D may be located within a network within vehicle 291D. Additionally, although not shown, device 296D may be connected to other elements of vehicle 291D, such as a CAN bus, an on-board diagnostics (ODBII) port, a GPS system, a SIM card, a modem, etc. Device 296D may collect data from any of these systems and transfer the data to server 295D via the network.

The secure management of data begins with vehicle 291D. In some embodiments, device 296D may collect information before, during, and after travel. Data may include GPS data, travel data, occupant information, diagnostic data, fuel data, speed data, and the like. However, device 296D may only transmit collected information back to host server 295D in response to vehicle ignition and completion of travel. Furthermore, communications may be initiated only by device 296D, and not by host server 295D. Thus, in one embodiment, device 296D will not accept communications initiated by external sources.

To facilitate communication, device 296D may establish a secure private network between device 296D and host server 295D. Here, device 296D may include a tamper-resistant SIM card that provides secure access to carrier network 294D via radio tower 292D. When device 296D prepares to transmit data to host server 295D, it may establish a one-way secure connection with host server 295D. Carrier network 294D may communicate with host server 295D using one or more security protocols. As a non-limiting example, carrier network 294D may communicate with host server 295D through a VPN tunnel that allows access through host server 295D's firewall 293D. As another example, carrier network 294D may use data encryption (e.g., AES encryption) when transmitting data to host server 295D. In some cases, the system may use multiple security measures, such as both VPN and encryption, to further protect data.

In addition to communicating with external servers, vehicles may also communicate with each other. In particular, vehicle-to-vehicle (V2V) communication systems enable vehicles to communicate with each other and with roadside infrastructure (e.g., traffic lights, signs, cameras, parking meters, etc.) via wireless networks. The wireless networks may include one or more of a Wi-Fi network, a cellular network, a dedicated short-range communication (DSRC) network, etc. Vehicles may use V2V communications to provide other vehicles with information regarding their speed, acceleration, braking, and direction, to name a few. This allows vehicles to gain insight into conditions before such conditions become visible, significantly reducing collisions. Furthermore, the inventive solution described and illustrated with respect to FIG. 2N may be utilized in this and other networks and/or systems, including those described and illustrated herein.

Figure 2O illustrates an example 290E of vehicles 293E and 292E using security certificates to conduct secured V2V communications, according to an exemplary embodiment. Referring to Figure 2O, vehicles 293E and 292E may communicate with each other through V2V communications over a short-range network, a cellular network, or the like. Vehicles 293E and 292E may sign messages using their respective public key certificates before sending the messages. For example, vehicle 293E may sign V2V messages using public key certificate 294E. Similarly, vehicle 292E may sign V2V messages using public key certificate 295E. In one embodiment, public key certificates 294E and 295E are associated with vehicles 293E and 292E, respectively.

When transport means receive communications from each other, they may verify the signatures, such as with certificate authority 291E. For example, transport means 292E may verify with certificate authority 291E that public key certificate 294E used by transport means 293E to sign the V2V communication is authentic. If transport means 292E successfully verifies public key certificate 294E, the transport means knows that the data is from a legitimate source. Similarly, transport means 293E may verify with certificate authority 291E that public key certificate 295E used by transport means 292E to sign the V2V communication is authentic. Furthermore, the inventive solutions described and illustrated with respect to FIG. 2O may be utilized in networks and/or systems, including those described and illustrated herein.

FIG. 3A illustrates a flowchart 300 according to an exemplary embodiment. Referring to FIG. 3A, a processor may perform one or more of: acquiring data related to vehicle performance 302; determining a performance level of the vehicle based on the acquired data 304; dynamically modifying the performance level based on current use of the vehicle 306; and determining a next use of the vehicle based on the dynamically modified performance level 308.

FIG. 3B shows another flowchart 320 according to an exemplary embodiment. Referring to FIG. 3B, the processor may perform one or more of: dynamically modifying the performance level based on services performed on the vehicle, where the services performed include one or more of replacing and upgrading one or more parts on the vehicle 322; notifying one or more actions that can be performed to increase the performance level of the vehicle, where the one or more actions increase the value of the vehicle 324; using an assessment of the condition of the vehicle, the operational behavior of the vehicle, and the maintenance costs of the vehicle as criteria for the performance level during use of the vehicle 326; and the subsequent use including one or more of enrolling the vehicle in a leasing program, enrolling the vehicle in a ride-sharing program, and selling the vehicle 328.

Figure 3C illustrates yet another flowchart 340 according to an example embodiment. Referring to Figure 3C, the processor may perform one or more of: receiving validation of a performance level change, where the validation includes a blockchain consensus between a peer group of vehicles and a server 342; and executing a smart contract to record the validation in the blockchain based on the blockchain consensus 344.

FIG. 3D illustrates a flowchart 360 according to an exemplary embodiment. Referring to FIG. 3D, the processor may perform one or more of: receiving characteristics associated with the vehicle within a period of time, the characteristics relating to the vehicle's condition, the vehicle's operational behavior, and the vehicle's maintenance costs 362; providing one or more actions for the vehicle to perform to increase the level of the characteristics 364; and determining the next use of the vehicle after the period of time in response to the increasing level of the characteristics 366.

FIG. 3E illustrates a flowchart 380 according to an exemplary embodiment. Referring to FIG. 3E, the processor may perform one or more of the following: selecting a transportation vehicle in advance based on a provision and tolerance threshold associated with the transportation vehicle 382; the one or more actions including changes to reduce transportation vehicle usage, changes to transportation vehicle operation methods, and transportation vehicle maintenance 384; monitoring the characteristics as the transportation vehicle is operated and providing one of the characteristics to the transportation vehicle at a minimum level 386; monitoring the characteristics as the transportation vehicle is operated and providing one of the characteristics to the transportation vehicle at a minimum level 387; receiving a request from the transportation vehicle to increase the level of the characteristics and providing one or more actions to perform based on the transportation vehicle's current usage 388; and monitoring the characteristics as the transportation vehicle is operated and providing one of the characteristics to the transportation vehicle at a minimum level 389.

Figure 4 illustrates a machine learning vehicle network diagram 400 in accordance with an illustrative embodiment. Network 400 includes vehicle nodes 402 that interact with a machine learning subsystem 406. The vehicle nodes include one or more sensors 404.

The machine learning subsystem 406 includes a learning model 408. The learning model 408 is a mathematical artifact created by a machine learning training system 410 that generates predictions by finding patterns in one or more training datasets. In some embodiments, the machine learning subsystem 406 resides on the vehicle node 402. In other embodiments, the machine learning subsystem 406 resides external to the vehicle node 402.

The vehicle node 402 sends data from one or more sensors 404 to a machine learning subsystem 406. The machine learning subsystem 406 provides the data from the one or more sensors 404 to a learning model 408, which returns one or more predictions. The machine learning subsystem 406 sends one or more instructions to the vehicle node 402 based on the predictions from the learning model 408.

In additional embodiments, vehicle node 402 may transmit data from one or more sensors 404 to machine learning training system 410. In yet another embodiment, machine learning subsystem 406 may transmit data from sensors 404 to machine learning subsystem 410. One or more of the applications, features, steps, solutions, etc. described and/or illustrated herein may utilize machine learning network 400 as described herein.

FIG. 5A illustrates 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 vehicle/vehicle 525 is engaged in a transaction (e.g., vehicle service, dealer transaction, delivery/pickup, transportation service, etc.), the vehicle may receive assets 510 and/or release/transfer assets 512 pursuant to the transaction. A vehicle processor 526 resides on the vehicle 525, and communication exists between the vehicle processor 526, database 530, vehicle processor 526, and transaction module 520. Transaction module 520 may record information such as assets, parties involved, credits, service descriptions, dates, times, locations, outcomes, notifications, unexpected events, etc. Such transactions within transaction module 520 may be replicated to database 530. The database 530 may be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and may be on-board the vehicle, off-board the vehicle, directly accessible to the vehicle and/or accessible over a network, or accessible to the vehicle.

5B illustrates an exemplary vehicle configuration 550 for managing database transactions performed among various vehicles, according to an exemplary embodiment. A vehicle 525 may engage another vehicle 508 to perform various actions, such as sharing, transferring, or taking a service call, when the vehicle reaches a state where it needs to share service with other vehicles. For example, the vehicle 508 may be due for a battery charge and/or may have a tire issue, or may be on its way to pick up a package for delivery. A transport vehicle processor 528 resides within the vehicle 508, and communication exists between the transport vehicle processor 528, the database 554, and the transaction module 552. The vehicle 508 may notify another vehicle 525 that is in its network and operates with its blockchain member services. A transport vehicle processor 526 resides within the vehicle 525, and communication exists between the transport vehicle processor 526, the database 530, the transport vehicle processor 526, and the transaction module 520. Vehicle 525 may then receive information via wireless communication request and perform package pickup from vehicle 508 and/or a server (not shown). The transaction is logged in transaction modules 552 and 520 of both vehicles. Credits are transferred from vehicle 508 to vehicle 525, and a record of the transferred service is logged in database 530/554, assuming the blockchains are different or logged in the same blockchain used by all members. Database 554 may be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, or a distributed ledger, and may be on-board the vehicle, off-board the vehicle, directly accessible, and/or accessible via a network.

Figure 6A illustrates a blockchain architecture configuration 600 according to an example embodiment. Referring to Figure 6A, the blockchain architecture 600 may include a particular blockchain element, e.g., a group of blockchain member nodes 602-606 as part of a blockchain group 610. In an example embodiment, a permissioned blockchain is not accessible to all participants; only members who are authorized to access the blockchain data are accessible. Blockchain nodes participate in various activities, such as adding blockchain entries and the validation process (consensus). One or more of the blockchain nodes may approve entries based on approval policies or provide ordering services to all blockchain nodes. Blockchain nodes may initiate blockchain actions (e.g., authentication) and attempt to write to the blockchain's immutable ledger, which is stored on the blockchain. A copy of that ledger may also be stored in the underlying physical infrastructure.

A blockchain transaction 620 is stored in computer memory once it is received and approved by a consensus model dictated by the member nodes. The approved transaction 626 is stored in the blockchain's current block and delegated to the blockchain via a delegation procedure that involves performing a hash of the transaction's data content in the current block and referencing the previous hash in the previous block. Within the blockchain, one or more smart contracts 630 may exist that define the terms of agreement and behavior of the transaction, such as registered recipients, vehicle characteristics, requirements, permissions, sensor thresholds, etc., contained in smart contract executable application code 632. This code may be configured to identify whether the requesting entity is registered to receive vehicle services, whether it is eligible for a given profile status/what the characteristics of the service being requested are, and whether to monitor the entity's behavior in subsequent events. For example, if a service event occurs and a user is in the vehicle, monitoring of sensor data may be triggered and a particular parameter, such as the vehicle's charge level, may be identified as being above or below a particular threshold for a particular period of time, resulting in a change in the current situation that may necessitate sending an alert to a manager (i.e., vehicle owner, vehicle operator, server, etc.) so that service can be identified and stored for reference. The collected vehicle sensor data may be based on the type of sensor data used to collect information about the vehicle's status. Other sensor data may also form the basis of vehicle event data 634, such as where traveled, average speed, maximum speed, acceleration rate, whether there were any collisions, whether the expected route was taken, where the next destination is, whether safety measures are in place, whether the vehicle has sufficient charge/fuel, etc. Any such information may then form the basis of smart contract conditions 630 stored on the blockchain. For example, sensor thresholds stored in the smart contract may be used as criteria for whether, when, and where the detected service is required.

Figure 6B illustrates a shared ledger configuration according to an example embodiment. Referring to Figure 6B, example blockchain logic 640 includes a blockchain application interface 642 as an API or plug-in application associated with a computing device and execution platform for a particular transaction. The blockchain configuration 640 may include one or more applications coupled to an application programming interface (API) to access and execute stored program/application code (e.g., smart contract executable code, smart contracts, etc.), which can be created with customized configurations desired by participants, maintain their own state, control their own assets, and receive external information. This can be deployed as an entry and installed on all blockchain nodes via addition to the distributed ledger.

Smart contract application code 644 provides the foundation for blockchain transactions by establishing application code. When the application code is executed, the terms of the transaction come into effect. When the smart contract 630 is executed, a specific approved transaction 626 is generated and then transferred to the blockchain platform 652. The platform includes security/authorization 658, a computing device that executes transaction management 656, and a storage portion 654 as memory that stores transactions and smart contracts on the blockchain.

A blockchain platform may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that can be used to receive and store new entries and provide access to auditors seeking access to data entries. The blockchain may expose interfaces that process program code and provide access to the virtual execution environments necessary to use the physical infrastructure. Cryptographic trust services may be used to verify entries, such as asset exchange entries, and keep the information private.

The blockchain architecture configurations of FIGS. 6A and 6B may process and execute program/application code via one or more interfaces exposed by the blockchain platform and services provided by the blockchain platform. As a non-limiting example, smart contracts may be created to perform reminders, updates, and/or other notifications of changes, updates, etc. The smart contracts themselves may be used to specify authorization and access requirements and rules associated with ledger usage. For example, information may include new entries that may be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. Results may include a decision to reject or approve the new entry based on criteria defined in the smart contract and/or peer consensus. Physical infrastructure may be utilized to retrieve any of the data or information described herein.

Smart contracts may be authored in smart contract executable code via high-level applications and programming languages and then written to blocks on a blockchain. Smart contracts may include executable code that is registered, stored, and/or replicated on a blockchain (e.g., a decentralized network of blockchain peers). An entry is the execution of smart contract code and may occur in response to conditions associated with the smart contract being satisfied. Execution of a smart contract may cause trusted changes to the state of a digital blockchain ledger. Blockchain ledger changes caused by smart contract execution may be automatically replicated across a decentralized network of blockchain peers via one or more consensus protocols.

Smart contracts may write data to the blockchain in the form of key-value pairs. Additionally, smart contract code can read values stored on the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. This code may be used to create temporary data structures on a virtual machine or other computing platform. Data written to the blockchain can be public and/or encrypted and kept private. Temporary data used/generated by smart contracts is kept in memory by the provided execution environment and deleted when the next data needed for the blockchain is identified.

The smart contract executable code may include a code interpretation of the smart contract along with additional features. As described herein, the smart contract executable code may be program code deployed on a computational network that runs together and is validated by a chain validator during a consensus process. The smart contract executable code receives the hash and retrieves from the blockchain a hash associated with a data template created 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 authorization key to the requested service. The smart contract executable code may be written to blockchain data associated with cryptographic details.

Figure 6C illustrates a blockchain configuration for storing blockchain transaction data, according to an exemplary embodiment. Referring to Figure 6C, exemplary configuration 660 provides a vehicle 662, a user device 664, and a server 666 that shares information with a distributed ledger (i.e., blockchain) 668. The server may represent a service provider entity that queries vehicle service providers and shares user profile rating information when a known, established user profile seeks to rent a vehicle with an established rating profile. Server 666 may receive and process data related to the vehicle's service requirements. When a service event occurs, such as vehicle sensor data indicating a need for fuel/charging, maintenance service, etc., smart contracts may be used to invoke rules, thresholds, sensor information collections, etc. that may be used to invoke a vehicle service event. Blockchain transaction data 670 is stored for each transaction, such as an access event, subsequent updates to the vehicle's service status, event updates, etc. The transaction may include the parties involved, requirements (e.g., age 18, service eligible candidate, valid driver's license, etc.), compensation level, distance traveled during the event, registered recipients authorized to access the event and host vehicle service, rights/permissions, sensor data collected during the vehicle event operation to log details of the upcoming service event and identify vehicle condition status, and thresholds used to determine if the service event is complete or if the vehicle condition status has changed.

Figure 6D illustrates a blockchain block 680 and the contents of block structures 682A-682n that can be added to a distributed ledger, according to an example embodiment. With reference to Figure 6D, a client (not shown) may submit entries to a blockchain node to perform activities on the blockchain. By way of example, a client may be an application acting on behalf of a requester, such as a device, individual, or entity, that proposes a blockchain entry. Multiple blockchain peers (e.g., blockchain nodes) may maintain a copy of the blockchain network state and the distributed ledger. Various types of blockchain nodes/peers may be present in a blockchain network, including endorsing peers that simulate and approve entries proposed by clients, and delegating peers that verify the approvals, validate entries, and delegate entries to the distributed ledger. In this example, a blockchain node may play the role of an endorser node, a committer node, or both.

The system of the present invention includes a blockchain that stores immutable, ordered records in blocks and a state database (current world state) that maintains the current state of the blockchain. There may be one distributed ledger per channel, and each peer maintains its own copy of the distributed ledger for each channel in which it is a member. The blockchain of the present invention is an entry log structured as hash-linked blocks, with each block containing a sequence of N entries. Blocks may include various components, as shown in Figure 6D. Block links may be generated by appending a hash of the previous block's header to the current block's block header. In this way, all entries on the blockchain are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of the links, the latest block in the blockchain represents all previous entries. The blockchain of the present invention may be stored in a peer file system (local storage or connected storage) that supports append-only blockchain workloads.

The current state of the blockchain and distributed ledger may be stored in a state database, where the current state data represents the latest values of all keys contained so far in the blockchain's on-chain entry log. Invocations of smart contract executable code execute entries against the current state in the state database. To make such smart contract executable code interactions highly efficient, the latest values of all keys are stored in the state database. The state database may contain an indexed view into the blockchain's entry log, so that it can be regenerated off-chain at any time. The state database may be automatically restored at peer startup (or generated on demand) before entries are accepted.

An approval node receives entries from clients and approves the entries based on the simulated results. The approval node holds a smart contract that simulates the entry proposal. When the approval node approves an entry, it creates an entry approval. The entry approval is a signed response from the approval node to the client application indicating approval of the simulated entry. The manner in which an entry is approved depends on the approval policy, which may be specified in the smart contract executable code. An example approval policy is "a majority of approving peers must approve the entry." Different channels may have different approval policies. The approved entry is forwarded by the client application to the ordering service.

The ordering service accepts approved entries, orders blocks, and distributes the blocks to delegating peers. For example, the ordering service may initiate a new block when a threshold number of entries is reached, a timer times out, or another condition occurs. In this example, a blockchain node is a delegating peer that receives data block 682A for storage in the blockchain. The ordering service may consist of a cluster of orderers. The ordering service does not process entries, smart contracts, or maintain a shared ledger. Rather, the ordering service accepts approved entries and specifies orders that delegate such entries to the distributed ledger. The architecture of a blockchain network may be designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) are pluggable components.

Entries are written to the distributed ledger in a consistent order. The ordering of entries is established to take effect when updates to the state database are delegated to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin) where ordering occurs through cryptographic puzzle solving or lookup, in this example, the parties to the distributed ledger may choose the ordering mechanism that best suits their network.

Referring to FIG. 6D , a block 682A (also referred to as a data block) stored in a blockchain and/or distributed ledger may include multiple data segments, such as block headers 684A-684n, transaction-specific data 686A-686n, and block metadata 688A-688n. It should be understood that the various illustrated 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 illustrative embodiments. In some cases, both the block header 684A and the block metadata 688A may be smaller than the transaction-specific data 686A that stores entry data. However, this is not a requirement. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) in block data 690A-690n. Block 682A may also include a link to a previous block (e.g., on the blockchain) in block header 684A. In particular, the block header 684A may include a hash of the header of the previous block. The block header 684A may also include a unique block number, a hash of the block data 690A of the current block 682A, etc. The block numbers of the blocks 682A may be unique or may be assigned in an increasing/sequential order starting from zero. The first block of a blockchain may be called the genesis block, which contains information about the blockchain, its members, the data stored in the block, etc.

Block data 690A may store entry information for each entry recorded in the block. For example, the entry data may include one or more of the following: entry type, version, timestamp, distributed ledger channel ID, entry ID, epoch, payload visibility, smart contract executable code path (deploy tx), smart contract executable code name, smart contract executable code version, inputs (smart contract executable code and functions), client (creator) ID such as public key and certificate, client signature, endorser ID, endorser signature, proposal hash, smart contract executable code events, response status, namespace, read set (e.g., list of keys and versions read by the entry), write set (e.g., list of keys and values), start key, end key, list of keys, Merkle tree query summary, etc. Entry data may be stored for each of the N entries.

In some embodiments, block data 690A may also store transaction-specific data 686A that adds additional information to the hash-linked chain of blocks in a blockchain. To this end, data 686A may be stored in an immutable log of blocks on a distributed ledger. Some of the advantages of storing such data 686A are reflected in the various embodiments disclosed and illustrated herein. Block metadata 688A may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature at the time of block creation, a reference to the last constituent block, an entry filter that identifies valid and invalid entries in the block, and the last offset of the ordering service that ordered the block. The signature, last constituent block, and orderer metadata may be added by the ordering service. Alternatively, the block committer (e.g., a blockchain node) may add valid/invalid information based on approval policies, validation of read/write sets, etc. The entry filter may include a byte array of a size equal to the number of entries in block data 610A and a validation code that identifies whether the entry was valid or invalid.

The other blocks 682B-682n in the blockchain also have headers, files, and values. However, unlike the first block 682A, each of the other blocks' headers 684A-684n includes the hash value of the immediately preceding block. The hash value of the immediately preceding block may be just the hash of the previous block's header, 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 block-by-block trace can be performed, as indicated by arrow 692, from the Nth block back to the origin block (and associated original file) to establish an auditable and immutable chain of custody.

The above-described embodiments may be implemented in hardware, a computer program executed by a processor, firmware, or a combination thereof. The computer program may be embodied on a computer-readable medium, such as a storage medium. For example, the computer program may reside in random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application-specific integrated circuit ("ASIC"). Alternatively, the processor and the storage medium may exist as separate components. For example, FIG. 7 shows an exemplary computer system architecture 700. This architecture may represent or be integrated with any of the components described above, etc.

Figure 7 is not intended to suggest any limitations regarding the scope of use or functionality of the application embodiments described herein. In any event, the computing node 700 may implement and/or perform any of the functionality described above in this specification.

Computing node 700 includes computer system/server 702, which is operable in numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with computer system/server 702 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

Computer system/server 702 may be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system/server 702 may also 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.

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

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 a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus.

Computer system/server 702 typically includes a variety of computer system-readable media. Such media are any available media accessible by computer system/server 702, including both volatile and nonvolatile media, removable and non-removable media. System memory 706, in one embodiment, implements the flowcharts of other figures. System memory 706 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 708 and/or cache memory 710. Computer system/server 702 may also include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, memory 706 may be provided to read from and write to non-removable, non-volatile magnetic media (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 and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media, may be provided. In such cases, each may be connected to the bus by one or more data media interfaces. As further shown and described below, memory 706 may include at least one program product having a set (e.g., at least one) of program modules configured to implement the functionality of various embodiments of the application.

A program/utility having a set of program modules (at least one) may be stored in memory 706, for example and without limitation, in an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may comprise an implementation of a networked environment. The program modules generally implement the functionality and/or methodology of various embodiments of the applications described herein.

As will be appreciated by those skilled in the art, aspects of the present application may be embodied as a system, method, or computer program product. Thus, 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, all of which may be 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 medium(s) having computer-readable program code embodied therein.

The computer system/server 702 may also communicate with one or more external devices via I/O devices 712 (e.g., I/O adapters), which may include one or more devices that allow a user to interact with the computer system/server 702, such as a keyboard, pointing device, display, voice recognition module, etc., and/or any device (e.g., network card, modem, etc.) that allows the computer system/server 702 to communicate with one or more other computing devices. Such communications may be implemented via I/O interfaces of the devices 712. Furthermore, the computer system/server 702 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet), via a network adapter. As shown, the devices 712 communicate with the other components of the computer system/server 702 via a bus. It should be understood that other hardware and/or software components, not shown, may be used with the computer system/server 702. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data recording storage systems, etc.

While at least one exemplary embodiment of the system, method, and non-transitory computer-readable medium has been illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that the application is not limited to the disclosed embodiments, but is susceptible to numerous rearrangements, modifications, and substitutions as set forth and defined in the following claims. For example, the capabilities of the various illustrated systems may be performed by one or more of the modules or components described herein, or may be implemented in a distributed architecture, including pairs of transmitters, receivers, or both. For example, all or a portion of the functionality performed by individual modules may be performed by one or more of such modules. Furthermore, the functionality described herein may be performed at various times in connection with various events internal or external to the modules or components. Additionally, information transmitted between the various modules may be 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 multiple protocols. Additionally, messages transmitted or received by any of the modules may be transmitted or received directly and/or via one or more of the other modules.

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

Note that some of the system features described herein are presented as modules to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integrated (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Alternatively, 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, or the like.

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

In fact, a module of executable code may be a single instruction or many instructions, and may even be distributed across several different code segments, different programs, and several memory devices. Similarly, operational data may be identified and illustrated herein in modules and may be embodied in any suitable form and organized within any suitable type of data structure. Operational data may be collected as a single data set, distributed in different locations, including different storage devices, or may simply exist, at least in part, as electronic signals on a system or network.

It will be readily understood that the components of the present application, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the detailed description of the embodiments is not intended to limit the scope of the present application as claimed, but rather is merely representative of selected embodiments of the present application.

Those skilled in the art will readily appreciate that the above may be implemented in a different order of steps and/or with hardware elements configured differently than those disclosed. Therefore, while the present application has been described in terms of such preferred embodiments, certain modifications, variations, and alternative constructions will be apparent to those skilled in the art.

While preferred embodiments of the present application have been described, it should be understood that the described embodiments are by way of example only, and that the scope of the present application is defined solely by the appended claims, taking into account the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).
The invention disclosed in this specification includes the following aspects.
[Aspect 1]
acquiring, by a vehicle, data relating to performance of said vehicle;
determining, by the vehicle, a performance level of the vehicle based on the acquired data;
dynamically modifying, by the vehicle, the performance level based on current use of the vehicle;
determining, by the vehicle, a next use of the vehicle based on the dynamically modified performance level;
A method comprising:
[Aspect 2]
2. The method of claim 1, comprising dynamically modifying the performance level based on services performed on the vehicle, the services performed comprising one or more of a replacement and an upgrade of one or more parts of the vehicle.
[Aspect 3]
2. The method of claim 1, comprising: communicating, by the vehicle, one or more actions that can be taken to increase the performance level of the vehicle, the one or more actions increasing a value of the vehicle.
Aspect 4
2. The method of claim 1, wherein the performance level is based on an evaluation of the condition of the vehicle while the vehicle is in use, the operational behavior of the vehicle, and the cost of maintaining the vehicle.
Aspect 5
2. The method of claim 1, wherein the next use includes one or more of: enrolling the vehicle in a leasing program, enrolling the vehicle in a ride-sharing program, and selling the vehicle.
Aspect 6
2. The method of claim 1, comprising receiving validation of the change in performance level, the validation comprising a blockchain consensus between a peer group of the vehicle and a server.
Aspect 7
7. The method of claim 6, comprising executing a smart contract to record the verification on a blockchain based on the blockchain consensus.
Aspect 8
1. A vehicle comprising a processor,
The processor:
obtaining data relating to the performance of said vehicle;
determining a performance level of the vehicle based on the acquired data;
dynamically modifying the performance level based on current usage of the vehicle;
determining a next use of the vehicle based on the dynamically modified performance level;
1. A means of transport configured to:
Aspect 9
9. The vehicle of claim 8, comprising dynamically modifying the performance level based on services performed on the vehicle, the services performed comprising one or more of a replacement and an upgrade of one or more parts of the vehicle.
Aspect 10
9. The vehicle of claim 8, further comprising: communicating one or more actions that can be taken to increase the performance level of the vehicle, the one or more actions increasing a value of the vehicle.
Aspect 11
9. The vehicle of claim 8, wherein the performance level is based on an evaluation of the condition of the vehicle during use of the vehicle, the operational behavior of the vehicle, and the maintenance costs of the vehicle.
Aspect 12
9. The vehicle of claim 8, wherein the next use includes one or more of: enrolling the vehicle in a leasing program, enrolling the vehicle in a ride-sharing program, and selling the vehicle.
Aspect 13
9. The vehicle of claim 8, wherein the vehicle receives validation of the change in performance level, the validation comprising a blockchain consensus between a peer group consisting of the vehicle and a server.
Aspect 14
14. The means of transportation of claim 13, comprising execution of a smart contract to record the verification on a blockchain based on the blockchain consensus.
Aspect 15
A non-transitory computer-readable medium containing instructions that, when read by a processor, cause the processor to:
acquiring, by a vehicle, data relating to performance of said vehicle;
determining, by the vehicle, a performance level of the vehicle based on the acquired data;
dynamically modifying, by the vehicle, the performance level based on current use of the vehicle;
determining, by the vehicle, a next use of the vehicle based on the dynamically modified performance level.
Non-transitory computer-readable medium.
Aspect 16
16. The non-transitory computer-readable storage medium of aspect 15, comprising dynamically modifying the performance level based on services performed on the vehicle, the services performed comprising one or more of a replacement and an upgrade of one or more parts on the vehicle.
Aspect 17
16. The non-transitory computer-readable storage medium of aspect 15, wherein the vehicle communicates one or more actions that can be taken to increase the performance level of the vehicle, the one or more actions increasing a value of the vehicle.
Aspect 18
16. The non-transitory computer-readable storage medium of aspect 15, wherein the next use includes one or more of enrolling the vehicle in a leasing program, enrolling the vehicle in a ride-sharing program, and selling the vehicle.
Aspect 19
16. The non-transitory computer-readable storage medium of aspect 15, comprising receiving validation of the change in performance level, the validation comprising a blockchain consensus between a peer group consisting of the vehicle and a server.
Aspect 20
20. The non-transitory computer-readable storage medium of aspect 19, comprising implementing a smart contract to record the verification on a blockchain based on the blockchain consensus.

Claims (13)

acquiring, by a vehicle, data relating to performance of said vehicle;
determining, by the vehicle, a performance level of the vehicle based on the acquired data, wherein determining the performance level of the vehicle includes determining an aggressive event score based on a ratio of a number of aggressive events detected based on driving behavior data to a distance driven by an operator of the vehicle;
dynamically modifying, by the vehicle, the performance level based on current use of the vehicle;
determining, by the vehicle, a next use of the vehicle based on the dynamically modified performance level;
improving the driving behavior of an operator of the vehicle by performing one or more of the following based on the violent event score: restricting the vehicle from traveling more than a given speed; restricting the vehicle from coming closer to another vehicle than a certain distance; or restricting the vehicle from traveling more than a threshold distance;
Including,
The method , wherein the performance level is based on an evaluation of the condition of the vehicle while the vehicle is in use, the operational behavior of the vehicle, and the maintenance costs of the vehicle . The method of claim 1, comprising dynamically modifying the performance level based on services performed on the vehicle, the services performed including one or more of replacing and upgrading one or more parts of the vehicle. The method of claim 1, further comprising: communicating, by the vehicle, one or more actions that can be taken to increase the performance level of the vehicle, the one or more actions increasing a value of the vehicle. The method of claim 1, wherein the subsequent use includes one or more of: enrolling the vehicle in a leasing program, enrolling the vehicle in a ride-sharing program, and selling the vehicle. The method of claim 1, comprising receiving validation of the change in performance level, the validation comprising a blockchain consensus between a peer group consisting of the vehicle and a server. 6. The method of claim 5 , further comprising executing a smart contract to record the verification on a blockchain based on the blockchain consensus. 1. A vehicle comprising a processor,
The processor:
obtaining data relating to the performance of said vehicle;
determining a performance level of the vehicle based on the acquired data, wherein determining the performance level of the vehicle includes determining an aggressive event score based on a ratio of a number of aggressive events detected based on driving behavior data to a distance driven by an operator of the vehicle;
dynamically modifying the performance level based on current usage of the vehicle;
determining a next use of the vehicle based on the dynamically modified performance level;
improving the driving behavior of an operator of the vehicle by performing one or more of the following based on the violent event score: restricting the vehicle from traveling more than a given speed; restricting the vehicle from coming closer to another vehicle than a certain distance; or restricting the vehicle from traveling more than a threshold distance;
It is configured as follows :
The vehicle , wherein the performance level is based on an evaluation of the condition of the vehicle during use of the vehicle, the operational behavior of the vehicle, and the maintenance costs of the vehicle . 10. The vehicle of claim 7, comprising dynamically modifying the performance level based on services performed on the vehicle, the services performed including one or more of a replacement and an upgrade of one or more parts of the vehicle . 10. The vehicle of claim 7, comprising: communicating one or more actions that can be taken to increase the performance level of the vehicle, the one or more actions increasing a value of the vehicle. 8. The vehicle of claim 7 , wherein the next use includes one or more of: enrolling the vehicle in a leasing program, enrolling the vehicle in a ride-sharing program, and selling the vehicle. 10. The vehicle of claim 7 , wherein receiving validation of the change in performance level comprises a blockchain consensus between a peer group of the vehicle and a server. 12. The vehicle of claim 11 , comprising executing a smart contract to record the verification on a blockchain based on the blockchain consensus. A non-transitory computer-readable medium containing instructions that, when read by a processor, cause the processor to:
acquiring, by a vehicle, data relating to performance of said vehicle;
determining, by the vehicle, a performance level of the vehicle based on the acquired data, wherein determining the performance level of the vehicle includes determining an aggressive event score based on a ratio of a number of aggressive events detected based on driving behavior data to a distance driven by an operator of the vehicle;
dynamically modifying, by the vehicle, the performance level based on current use of the vehicle;
determining, by the vehicle, a next use of the vehicle based on the dynamically modified performance level;
improving the driving behavior of an operator of the vehicle by performing one or more of the following based on the violent event score: restricting the vehicle from traveling more than a given speed; restricting the vehicle from coming closer to another vehicle than a certain distance; or restricting the vehicle from traveling more than a threshold distance;
and
The non-transitory computer readable medium , wherein the performance level is based on an evaluation of the condition of the vehicle during use of the vehicle, the operational behavior of the vehicle, and the maintenance costs of the vehicle .