Routing of electric vehicles to backup charging stations

Abstract

Example operations include one or more of receiving a charging request from a vehicle, determining a charging location used by other vehicles having the same preference based on one or more preferences associated with the vehicle, and routing the vehicle to the charging location based on the determination.

Description

Background Art

[0001] Vehicles or transportation vehicles, such as cars, motorcycles, trucks, airplanes, trains, etc., generally provide transportation needs for passengers and / or cargo in various ways. Functions associated with the transportation vehicle can be recognized and used by various computing devices, such as smartphones or computers, located on and / or outside the transportation vehicle. Summary of the Invention

[0002] One example embodiment provides a method comprising one or more of receiving a charging request from a vehicle, determining a charging location used by other vehicles having the same preferences based on one or more preferences associated with the vehicle, and routing the vehicle to the charging location based on the determination.

[0003] Yet another example embodiment provides a system comprising a memory communicatively coupled to a processor, wherein the processor performs one or more of: receiving a charging request from a vehicle, determining a charging location used by other vehicles having the same preferences based on one or more preferences associated with the vehicle, and routing the vehicle to the charging location based on the processor determining the charging location.

[0004] Yet another example embodiment provides a computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to perform one or more of: receiving a charging request from a vehicle, determining, based on one or more preferences associated with the vehicle, a charging location used by other vehicles having the same preferences, and routing the vehicle to the charging location based on the determination. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1A An example diagram illustrating routing of an electric vehicle to an alternative charging station is illustrated, according to an example embodiment.

[0006] Figure 1B Another example diagram illustrating routing of an electric vehicle to an alternative charging station is illustrated, according to an example embodiment.

[0007] Figure 2A According to an illustrative embodiment, a transportation network diagram is illustrated.

[0008] Figure 2B According to an illustrative embodiment, yet another transportation network diagram is illustrated.

[0009] Figure 2C According to an illustrative embodiment, yet another transportation network diagram is illustrated.

[0010] Figure 2D According to an illustrative embodiment, another transportation network diagram is illustrated.

[0011] Figure 2E According to an illustrative embodiment, another transportation network diagram is illustrated.

[0012] Figure 2F According to an example embodiment, a diagram depicting the electrification of one or more components is illustrated.

[0013] Figure 2G A diagram depicting the interconnection between different elements is illustrated, according to an example embodiment.

[0014] Figure 2H Yet another diagram depicting the interconnection between different elements is illustrated, according to an example embodiment.

[0015] Figure 2I Yet another diagram depicting the interconnection between elements is illustrated, according to an example embodiment.

[0016] Figure 2J Another diagram depicting a keyless entry system is illustrated, according to an example embodiment.

[0017] Figure 2K According to an example embodiment, another diagram depicting a CAN within a vehicle is illustrated.

[0018] Figure 2L According to an example embodiment, another diagram depicting an end-to-end communication channel is illustrated.

[0019] Figure 2M According to an example embodiment, another diagram depicting an example of a vehicle using security credentials for secure V2V communications is illustrated.

[0020] Figure 2N Another diagram depicting an example of a vehicle interacting with a secure processor and a wireless device is illustrated, according to an example embodiment.

[0021] Figure 3A According to an example embodiment, a flow chart is illustrated.

[0022] Figure 3B Yet another flow chart is illustrated according to an example embodiment.

[0023] Figure 3C Yet another flow chart is illustrated, according to an example embodiment.

[0024] Figure 4 According to an example embodiment, a machine learning transportation network graph is illustrated.

[0025] Figure 5A According to an example embodiment, an example vehicle configuration for managing database transactions associated with a vehicle is illustrated.

[0026] Figure 5B According to an example embodiment, another example vehicle configuration for managing database transactions between various vehicles is illustrated.

[0027] Figure 6A According to an example embodiment, a blockchain architecture configuration is illustrated.

[0028] Figure 6B According to an example embodiment, another blockchain configuration is illustrated.

[0029] Figure 6C According to an example embodiment, a blockchain configuration for storing blockchain transaction data is illustrated.

[0030] Figure 6D According to an example embodiment, example data blocks are illustrated.

[0031] Figure 7 An example system is illustrated to support one or more example embodiments. DETAILED DESCRIPTION

[0032] It will be readily understood that the components of the present invention, as generally described and illustrated in the figures herein, may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of at least one embodiment of the method, apparatus, computer-readable storage medium, and system, as represented in the accompanying drawings, is not intended to limit the scope of the claimed application, but rather represents only selected embodiments. The multiple embodiments depicted herein are not intended to limit the scope of the solution. The computer-readable storage medium may be a non-transitory computer-readable medium or a non-transitory computer-readable storage medium.

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

[0034] The features, structures or characteristics of the present invention described in this specification may be combined in any appropriate manner in one or more embodiments. For example, the use of the phrases "example embodiment", "some embodiments" or other similar language throughout this specification refers to the fact that a particular feature, structure or characteristic described with respect to that embodiment may be included in at least one example. Therefore, the appearance of the phrases "example embodiment", "in some embodiments", "in other embodiments" or other similar language throughout this specification does not necessarily refer to the same set of embodiments, and the described features, structures or characteristics may be combined in any appropriate manner in one or more embodiments. In the diagrams, any connection between elements may allow unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional arrow. In the current solution, the vehicle or conveyance may include one or more of a car, a truck, a pedestrian zone 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 place to another.

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

[0036] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide at least one of: a vehicle (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 status data received in the form of communication messages, such as wireless data network communications and / or wired communication messages, can be processed to identify vehicle / vehicle status status and provide feedback regarding the status and / or changes of the vehicle. In one example, a user profile can be applied to a specific vehicle / vehicle to authorize a current vehicle event, a service stop at a service station, authorize subsequent vehicle rental services, and enable inter-vehicle communication.

[0037] Within a communications infrastructure, a decentralized database is a distributed storage system consisting of multiple nodes communicating with each other. A blockchain is an example of a decentralized database. It comprises an append-only, immutable data structure (i.e., a distributed ledger) that maintains records between mutually untrusting parties. These mutually untrusting parties are referred to herein as peers, nodes, or peers. Each peer maintains a copy of the database records, and no peer can modify them without consensus among the decentralized peers. For example, peers can execute a consensus protocol to verify blockchain entries, group them into blocks, and construct a hash chain from the blocks. This process forms a ledger by ordering the entries as needed for consistency. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains can involve cryptocurrencies and use consensus based on various protocols, such as proof-of-work (PoW). In contrast, a permissioned blockchain database can secure interactions between a group of entities that share a common goal but do not or cannot fully trust each other, such as businesses exchanging funds, goods, or information. This solution can operate in permissioned and / or permissionless blockchain settings.

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

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

[0040] The ledger is an ordered, tamper-proof record of all state transitions of a blockchain. State transitions can originate from smart contract executable code calls (i.e., entries) submitted by participating parties (e.g., client nodes, orderer nodes, endorser nodes, peer nodes, etc.). An entry can result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also called a chain) that stores immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain. Each channel typically has one ledger. Each peer node maintains a copy of the ledger for each channel of which it is a member.

[0041] A chain is a log of entries made up of hash-linked blocks, with each block containing a series of N entries, where N is equal to or greater than 1. The block header includes the hash of the block's entries, as well as the hash of the previous block's header. This allows all entries on the ledger to be sequentially arranged and cryptographically linked together. Consequently, tampering with the ledger data is impossible without breaking the hash links. The hash of the most recently added blockchain block represents every entry that came before it on the chain, ensuring that all peers are in a consistent and trusted state. The chain can be stored on the peer file system (i.e., locally, on attached storage, in the cloud, etc.), effectively supporting append-only nature for blockchain workloads.

[0042] The current state of the immutable ledger represents the latest values for all keys contained in the chain's entry log. Because the current state represents the latest key values known to a channel, it is sometimes referred to as the world state. Smart contract executable code calls execute entries against the current state data of the ledger. To make interactions between these smart contract executables efficient, the latest values for keys can be stored in a state database. The state database can simply be an indexed view of the chain's entry log, allowing it to be regenerated from the chain at any time. The state database can be automatically restored (or generated on demand) at peer startup and before an entry is accepted.

[0043] Blockchain differs from traditional databases in that it is not a centralized repository, but rather a decentralized, immutable, and secure storage system where nodes must share any changes to the stored records. Properties inherent in and contributing to blockchain include, but are not limited to, an immutable ledger, smart contracts, security, privacy, decentralization, consensus, endorsements, and accessibility.

[0044] Example embodiments provide services to a specific vehicle and / or user profile applicable to that vehicle. For example, a user may be the owner of a vehicle or the operator of a vehicle owned by another party. Vehicles may require service at regular intervals, and service requests may require authorization before being allowed to receive service. In addition, a service center may provide services to vehicles in a nearby area based on the vehicle's current route plan and the relative level of service demand (e.g., immediate, severe, moderate, minor, etc.). Vehicle demand may be monitored via one or more vehicle and / or road sensors or cameras, which report sensed data to a central controller computer device in and / or remote from the vehicle. This data is forwarded to a management server for review and action. Sensors may be located in one or more of the following locations: inside the vehicle, outside the vehicle, on a fixed object separate from the vehicle, and on other vehicles in close proximity to the vehicle. Sensors may also be associated with the vehicle's speed, braking, acceleration, fuel level, service request, gear shifting, steering, etc. Sensors as described herein may also be devices, such as wireless devices in and / or near the vehicle. Additionally, sensor information can be used to identify whether the vehicle is operating safely and whether occupants encounter any unexpected vehicle conditions, such as upon entry and / or during use of the vehicle. Vehicle information collected before, during, and / or after vehicle operation can be identified and stored in transactions on a shared / distributed ledger, which can be generated and submitted to an immutable ledger determined by a permissioned consortium, thereby in a "decentralized" manner, such as via a blockchain member group.

[0045] Each stakeholder (i.e., owner, user, company, institution, etc.) may wish to limit the exposure of private information, so the blockchain and its immutable nature can be used to manage permissions for each specific user's vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when service is required, identify crash and / or degradation events, identify safety-related events, identify the parties involved in the event, and provide distribution to registered entities seeking access to such vehicle event data. Furthermore, outcomes can be identified, and the necessary information can be shared among registered companies and / or individuals based on consensus laws associated with the blockchain. This approach is not feasible with traditional centralized databases.

[0046] Various drive systems of this solution can utilize software, sensor arrays, and machine learning capabilities, light detection and ranging (Lidar) projectors, radar, ultrasonic sensors, etc. to create terrain and road maps that vehicles can use for navigation and other purposes. In some embodiments, instead of Lidar, GPS, maps, cameras, sensors, etc. can also be used in autonomous vehicles.

[0047] In certain embodiments, the present solution includes authorizing a vehicle for a service via an automatic and rapid authentication scheme. For example, driving to a charging station or fuel pump can be performed by a vehicle operator or autonomous vehicle, and authorization to receive charging or fuel can be performed without any delay as long as the service and / or charging station receives authorization. The vehicle can provide a communication signal that provides an identification of the vehicle having a profile of current activity linked to an account authorized to receive the service, which can be corrected later by compensation. Additional measures can be used to provide further authentication, such as other identifiers that can be wirelessly sent from the user's device to the service center to replace or supplement the first authorization process between the vehicle and the service center with additional authorization processes.

[0048] Shared and received data can be stored in a database, which is located in a single database (e.g., a database server) and typically maintains data in a single location. This location is typically 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 generally be accessed from multiple different locations. Due to its single location, a centralized database is easier to manage, maintain, and control, especially with regard to security. Within a centralized database, data redundancy is minimized, as the single location for all data also means there is only one master record for a given set of data. Blockchain can be used to store data and transactions related to transportation vehicles.

[0049] Any actions described herein can be performed by one or more processors (e.g., microprocessors, sensors, electronic control units (ECUs), host units, etc.) with or without memory, which can be located on and / or off-board a vehicle (e.g., servers, computers, mobile devices / wireless devices, etc.). The one or more processors can communicate with other memories and / or other processors located on other vehicles or off-board other vehicles to utilize data sent by and / or sent to the vehicle. The one or more processors and the other processors can send data, receive data, and utilize the data to perform one or more actions described or depicted herein.

[0050] Figure 1A According to an example embodiment, an example diagram illustrating routing of an electric vehicle to an alternative charging station is illustrated. System 100 may include one or more vehicles 104, 108, a server 120, and a physical processor 130. Vehicles 104, 108 may include cars, trucks, recreational vehicles, construction vehicles, motorcycles, mopeds, electric bicycles, trains, airplanes, and the like. In one embodiment, any of vehicles 104, 108 herein are at least partially powered by electrical energy (i.e., a hybrid electric vehicle (PHEV) or an electric vehicle (EV), etc.).

[0051] The server 120 may include one or more processors and storage devices for storing applications and data. In one embodiment, the server 120 may be associated with a vehicle manufacturer, a town or municipality, a government entity, a business or group of businesses, an organization, or the like. In one embodiment, the server 120 may be located in a network or cloud, may be part of the vehicle 104 or other vehicles 108, and / or may be located in or connected to one or more vehicle charging stations. In one embodiment, the server 120 may represent any number of computing devices that can determine results and share data and the determined results. The server 120 may communicate with one or more vehicles 104, 108 to obtain various information related to vehicle features and related software that are installed, enabled, or not enabled, as described herein.

[0052] The physical processor 130 may include one or more processors and storage devices for storing applications and data. In one embodiment, the physical processor 130 may be associated with the vehicle 104 or other vehicle 108, or associated with a device associated with one or more vehicle owners, vehicle drivers, vehicle occupants, homeowners, business owners, government entities, and the like. The physical processor 130 may be a device integrated with the vehicle 104 or other vehicle 108, and / or the physical processor 130 may be used in and removed from the vehicle 104, such as a mobile device. The physical processor 130 may be associated with various forms of vehicle displays, smartphones, smartwatches, tablets, wearable computers, laptops, and the like. In one embodiment, the device associated with the physical processor 130 may include a device application that is either natively present on the device or downloaded / installed from a website that can manage the installation and activation of software related to the vehicle 104 or vehicle 108 features.

[0053] In one embodiment, system 100 can manage recommendations for charging stations associated with vehicle 104 or other vehicles 108. For example, vehicle 104 or other vehicles 108 can send and receive various information to and from server 120 that can help make charging location recommendations. In one embodiment, the information sent can include one or more parameters, referred to as preferences. Each user associated with vehicle 104 and / or other vehicles 108 can prioritize preferences differently based on what is most important to them. Preferences can include at least one or more of: proximity (i.e., driving time or distance to a charging location), amenities (features associated with or near a charging location, such as clean restrooms, fast food restaurants, shopping, etc.), cost of charging vehicle 104 or other vehicles 108 (i.e., energy cost based on energy source type and / or time of day), availability (i.e., current queue length, number of charging stations at the location, etc.), and charging speed (e.g., Level 2 or Level 3 charging capability versus Level 1 charging capability). In one embodiment, server 120 can assign a fixed number to each preference. For example, the server 120 may assign proximity=1, amenity=2, cost of charging the vehicle 104 or other vehicles 108=3, availability=4, and charging speed=5.

[0054] In one embodiment, when a processor associated with vehicle 104 determines that the current charge level of vehicle 104 is equal to or below a level of, for example, 10%, vehicle 104 may send a charge request 112 to server 120. Server 120 receives charge request 112 and may obtain current preferences 124 of vehicle 104.

[0055] In one embodiment, the server 120 may send a preference request 116 to a physical processor 130 associated with the vehicle 104 or a user / entity associated with the vehicle 104, such as a driver or owner. In one embodiment, the preference request 116 may include specific required preferences, such as proximity = 1, amenities = 2, cost = 3 for charging the vehicle 104 or other vehicles 108, availability = 4, and charging speed = 5. Other preferences that may be used may include the manufacturer of the charging device (i.e., compatibility with the vehicle 104 or other vehicles 108) and whether the charger is wired or wireless.

[0056] In another embodiment, the entity processor 130 may include a software application that is already aware of specific preferences and allows the entity associated with the entity processor 130 to prioritize the preferences according to the entity's current expectations. After the entity prioritizes the preferences, the entity processor 130 may send the prioritized preferences to the server 120 as the current preferences 124. For example, assuming standard preferences such as proximity = 1, amenities = 2, cost of charging the vehicle 104 or other vehicles 108 = 3, availability = 4, and charging speed = 5, the entity processor 130 may return 1 = 2, 2 = 1, 3 = 5, 4 = 4, and 5 = 3 to reflect that amenities are most important (i.e., 2 = 1), followed by proximity (i.e., 1 = 2), which may occur in situations where the entity is in a hurry to make a purchase but may not be as concerned about the cost of charging. In one embodiment, the entity processor 130 may include the prioritized preferences in an entity profile, which is stored in a storage device accessible to the entity processor 130 and / or transmitted to the server 120 or vehicle processor 160.

[0057] In one embodiment, the server 120 may occasionally receive other vehicle preferences 128 from other vehicles 108 based on content preferred and prioritized by entities associated with the other vehicles 108. In one embodiment, the current preferences 124 and / or other vehicle preferences 128 may include location information, such as GPS coordinates, that can be used to identify the current location of the vehicle 104 and / or the other vehicles 108. Based on the received location information, the server 120 may determine the travel time or distance between the vehicle 104 and / or one or more other vehicles 108. In one embodiment, the server 120 may determine other vehicles 108 that are in close proximity to the vehicle 104 by comparing the travel time or distance between the vehicle 104 and the other vehicles 108 with proximity parameters stored in a storage device accessible to the server 120. For example, the server 120 may determine that the other vehicle 108A is currently 10 miles away from the vehicle 104, the other vehicle 108B is currently 2 miles away from the vehicle 104, and the other vehicle 108C is currently 22 miles away from the vehicle 104. If the proximity parameter is 12 miles, server 120 may determine that other vehicles 108A and 108B are close to vehicle 104 , but other vehicle 108C is not close to vehicle 104 .

[0058] In one embodiment, the server 120 can determine charging locations used by other vehicles 108 having the same preferences based on one or more preferences associated with the vehicle 104. In one embodiment, the same preferences may mean identical preferences, such as the current preferences 124 and the other vehicle preferences 128 being identical (e.g., 1=5, 2=3, 3=1, 4=2, and 5=4). In another embodiment, it may mean similar preferences, such as at least 3 of the 5 preferences being identical, but the other 2 being different (e.g., 1=5, 2=3, 3=2, 4=1, and 5=4). In other embodiments, the same preferences may mean varying degrees of similarity, such as the same priority, order, and / or weight of the preferences.

[0059] In another embodiment, the same preference may mean a match between sub-preferences. For example, amenities may include available restrooms, food availability, and tire pressure check / inflation as sub-preferences for charging locations. The entity may assign sub-priorities of 1 = tire pressure check / inflation, 2 = available restrooms, and 3 = food availability. The same preference may include a match in one or more sub-preferences, such as an entity associated with vehicle 104 and an entity associated with another vehicle 108 may assign restroom availability as the highest priority.

[0060] In response to determining that the other vehicle 108 has the same preference as vehicle 104, server 120 may identify the location of the other vehicle 108. In one embodiment, server 120 may send a location request to the other vehicle 108, and the other vehicle 108 may respond with one or more of its current GPS coordinates, its current destination, or the route the other vehicle 108 is taking to the destination. Server 120 may also query the other vehicle 108 for charging locations used by the other vehicle 108. For example, server 120 may send a request to the other vehicle 108 for the nearest charging location. The request may include the time at which the charging location is used and the distance and / or time from the current location of the other vehicle 108. The other vehicle 108 may respond with the charging location, time, and / or distance, etc. In one embodiment, server 120 may route vehicle 104 to a charging location based on time, distance, and / or proximity to vehicle 104. For example, vehicle 104 may travel along a route that passes within a distance threshold (e.g., 5 miles) of a charging station used by the other vehicle 108. In one embodiment, as long as the vehicle 104 is within proximity (however defined) of the other vehicle 108 , the server 120 routes the vehicle 104 to the charging location of the other vehicle 108 .

[0061] Figure 1B According to an example embodiment, an example diagram of routing an electric vehicle to an alternative charging station is illustrated. The system 150 may include one or more vehicle processors 160, a server 120, and an entity processor 130. The server 120 and the entity processor 130 have been previously described with reference to Figure 1A 108. The vehicle 104 and the other vehicles 108 may include a vehicle processor 160 that communicates with the server 120 and the entity processor 130. The vehicle processor 160 may be associated with the vehicle 104 and / or the other vehicles 108 and may include a navigation processor, a communication processor, a head unit processor, an ECU processor, a sensor processor, etc. The vehicle processor 160, the server 120, and the entity processor 130 may communicate via wired and / or wireless communication media. For example, when the vehicle 104 and / or the other vehicles 108 are receiving a charge at a charging location, the vehicle 104 may be coupled to the charging station via a suitable charging cable, and the charging station may be communicatively coupled to the server 120 via a wireless connection, such as a WI-FI or Bluetooth connection. The charging cable may include (one or more) electrical paths for transferring charge and one or more wired communication paths (e.g., USB, Ethernet, etc.) to provide two-way communication to and from the vehicle processor 160. As another example, vehicle 104 and / or other vehicles 108 may not be coupled to a charging station, such as while traveling, and may communicate wirelessly with server 120 , such as via WI-FI, Bluetooth, other wireless communication interfaces, etc.

[0062] In one embodiment, the vehicle processor 160 may determine that the vehicle 104 requires charging (154). For example, the vehicle processor 160 may receive a notification from the battery and charging processor of the vehicle 104 that charging is required. The battery and charging processor may continuously or periodically measure the battery and charge levels of the vehicle and compare them to thresholds stored in an accessible storage device. If the battery charge is below a threshold (e.g., 10%), the battery and charging processor may notify the vehicle processor 160 that the vehicle requires charging. In response, the vehicle processor 160 may send a charge request notification 112 to the server 120.

[0063] In another embodiment, the entity processor 130 may determine that the vehicle 104 requires charging. For example, the vehicle processor 160 may receive a notification from the charging processor of the vehicle 104 that the current charge level is below a threshold. The vehicle processor 160 may send a request to the entity processor 130 of the entity device to charge the vehicle. In one embodiment, the entity processor 130 may display the request and / or audibly present the request to an entity associated with the entity device and the entity processor 130. The request may include the current charge level in the vehicle 104 and / or the available remaining driving range. The entity may provide a response to the request to initiate the search for charging locations. In one embodiment, the response may be sent back to the vehicle processor 160, which generates the charging request 112 to the server 120. In another embodiment, the response may be sent to the server 120 as the charging request 112.

[0064] In response to receiving a charge request 112. The server 120 may transmit a preference request notification 116 to the entity processor 130. The entity processor 130 receives the notification 116 and presents the preferences (162) on a display of the entity device (i.e., a head unit of the vehicle 104, a smart phone, a smart watch, etc.) and / or audibly to the entity associated with the entity processor 130. The presentation may request the entity to prioritize the preferences (166). For example, priority "1" = the most important preference for the entity, "2" = the second most important preference, and so on. The entity may prioritize the preferences (166) based on the request and ultimately determine the selection of the priorities. The entity processor 130 may send a notification 124 to the server 120 including the current preferences associated with the entity.

[0065] In one embodiment, the server 120 may determine shared preferences (170) with one or more other vehicles 108, as described herein. In one embodiment, the shared preferences may include priorities that are similar to or match one or more other vehicle preferences 128 received from the other vehicles 108. For example, the vehicle 104 and the other vehicles 108 may share a highest priority shared preference, such as charging speed or charger availability.

[0066] As about Figure 1A As described above, the server 120 may identify other vehicles 108 (174) that have preferences in common with the current preferences 124 associated with the vehicle 104. The other vehicles 108 may be in the same or similar location / area as the vehicle 104. In one embodiment, a plurality of other vehicles 108 (174) may be identified. The server 120 may identify charging locations used by other vehicles that have preferences in common with the vehicle 104 (178). In one embodiment, the current preferences 124 and other vehicle preferences 128 may include location data as described herein that allows the server 120 to determine the current location, destination, and / or route of the vehicle 104 and other vehicles 108.

[0067] In one embodiment, the server 120 may determine a plurality of other vehicles 108 (170) that share common preferences with the vehicle 104. Since the vehicle 104 may only be traveling to a single charging location, the server 120 may identify a single other vehicle 108 or a group of other vehicles 108 that share a common charging location. In one embodiment, the server 120 may narrow the scope of the identified charging locations (178) by other means. For example, the server 120 may identify a charging location based on another vehicle 108 having more priority matches than the other vehicles 108, another vehicle 108 having more common high-priority preference matches than the other vehicles 108, or another vehicle 108 being closer to the vehicle 104 in terms of proximity, destination, or route than the other vehicles 108.

[0068] In one embodiment, once a charging location (178) for vehicle 104 is identified, server 120 may send charging location 132 to vehicle processor 160, and vehicle processor 160 may route vehicle 104 to the charging location (182). For example, vehicle processor 160 may transmit charging location 132 to a head unit or navigation processor of vehicle 104, which may route vehicle 104 to the identified charging location 132 by setting the vehicle's destination to charging location 132.

[0069] In one embodiment, the vehicle processor 160 may determine that the battery charge of the vehicle 104 is below a threshold and include one or more preferences and the battery charge in the charging request 112. The battery charge may determine the operating range of the vehicle 104 and which charging locations the vehicle 104 can reliably reach.

[0070] In one embodiment, when the vehicle processor 160 determines that charging is required (154), the vehicle processor 160 may determine the charge level of the vehicle 104, as described herein. The charge request 112 may include the vehicle's current charge level and / or the vehicle's operating range compared to the current location. Even if the prioritized preferences happen to match one or more other vehicles 108, the server 120 may use the vehicle's 104 current charge level and / or current operating range to allow or disqualify one or more charging locations. For example, if the vehicle 104 cannot reach the identified charging location, it would be meaningless to route the vehicle to the charging location (182) according to the prioritized preferences.

[0071] In one embodiment, routing may be based on vehicle 104 and other vehicles 108 being in proximity to one another. Proximity may mean being within a distance or driving time of one another. In one embodiment, the proximity between vehicle 104 and other vehicles 108 may indicate that vehicle 104 may have sufficient remaining charge to reach the identified charging station (178). In one embodiment, proximity may not mean that vehicle 104 and other vehicles 108 are currently within a certain distance of one another. Instead, it may mean that at least a portion of the routes of both vehicles 104, 108 and / or the destinations of both vehicles 104, 108 are within a certain distance and / or driving time of the identified charging location (178).

[0072] In one embodiment, routing the vehicle 104 to the charging location can be based on determining a route from the current location of the vehicle 104 to the charging location and transmitting the route to the vehicle 104. In one embodiment, the vehicle processor 160 can transmit one or more of the current route and / or current destination to the server 120, either alone or as part of the charge request 112. The server 120 can determine a route and destination associated with the identified charging station (178) and compare the determined route and destination with the route and destination received from the vehicle processor 160. In one embodiment, the server 120 can route the vehicle 104 to the charging location that has the smallest difference (i.e., distance and / or time) between the route / destination received by the vehicle 104 and the route / destination to the identified charging location. In another embodiment, the server 120 can route the vehicle 104 to a charging location that has been used by many other vehicles 108 in the recent period. For example, the server 120 can determine that 18 other vehicles were routed to a charging location the previous day. If the number ( 18 ) is greater than a threshold value (eg, 10 ) stored in an accessible storage device, the server 120 may route the vehicle to a charging location ( 182 ) for 18 other vehicles 108 .

[0073] In one embodiment, the server 120 may compare one or more preferences associated with the vehicle 104 with one or more historical preferences associated with the vehicle 104, partially modify the one or more preferences according to the one or more historical preferences, and select a charging location from the one or more charging locations based on the modified one or more preferences. The server 120 may receive the current preferences 124 multiple times during the life of the vehicle 104, such as each time the vehicle processor 160 determines that charging is needed (154). The server 120 may store the received current preferences 124 in an accessible storage device and, in one embodiment, average the received current preferences 124 or find an average or other statistical combination of the received current preferences 124. In one embodiment, the server 120 may maintain the received current preferences 124 or statistical combination for only a period of time. Entities may change preference priorities over time, and old prioritized preferences may not be as important. For example, an entity may now prioritize convenience (e.g., wait time) over the cost of electricity a year ago.

[0074] In one embodiment, the server 120 may modify the current preferences 124 according to the historical preferences. The modification may mean changing the priority of one or more preferences to the priority in the historical preferences. For example, the current preferences 124 may indicate proximity as priority = 1, while the historical preferences may indicate proximity as priority = 5. In one embodiment, the server 120 may average the proximity priorities to priority = 3. In another example, the server 120 may lower the proximity priority of the current preferences 124 to priority = 2. In this way, the server 120 migrates the current preferences 124 toward the historical preferences. In one embodiment, modifying one or more preferences may include modifying the priority of one or more other preferences in the current preferences 124 so that no two preferences have the same priority. Finally, the server 120 may select a charging location based on the modified preferences and send the charging location 132 to the vehicle processor 160. Finally, the server 120 may select a charging location based on the modified preferences and send the charging location 132 to the vehicle processor 160.

[0075] In one embodiment, the server 120 may determine an area with high charging demand near the vehicle and change preferences based on the characteristics of the area. In one embodiment, the characteristics of the area may include parameters that are similar (i.e., cost, power transmission speed) or different (i.e., crime, congestion) to one or more preferences. For example, in a busy area, an entity may not want to wait for a long time for a charging location, or find a charging location that is well lit or has some form of local security measures (such as security patrols, behind a chain link fence, etc.). In one embodiment, the server 120 may add one or more parameters to one or more preferences and search through these parameters to find more suitable content in the area. In one embodiment, the server 120 may first search for charging locations that meet the characteristics of the area (e.g., low crime rate, sparse population, etc.). The server 120 may apply the prioritized one or more preferences to charging locations that meet the characteristics of the area. In one embodiment, the server 120 may first search the prioritized one or more preferences and then search for charging locations that meet the characteristics of the area.

[0076] In one embodiment, the server 120 may determine that the vehicle 104 was routed to a different charging location than the identified charging location (178), determine a change in the charging preferences of the vehicle 104 based on the different charging location, and store the changed charging preferences of the vehicle 104 to an accessible storage device. In one embodiment, when the vehicle 104 arrives at the charging location or during charging, the vehicle processor 160 may transmit the identification and location of the charging location used by the vehicle 104 to the server 120. The server 120 may receive the identification and location of the used charging station and add it to the history of charging locations used by the vehicle 104. The server 120 may also determine that the vehicle 104 used a different charging location than the recommended charging location 132.

[0077] In one embodiment, the system continuously monitors charging preferences and behavior that changes historical preferences. Not going to a recommended charging location may change historical preferences, for example, if the driver is routed to a non-recommended charging location with the fastest charging time in the area, a shorter charging time may be emphasized more. The new charging location may also reflect the change in charging preference priority. The server 120 may assign the charging preferences to the new charging location and store the changed vehicle charging preferences in a storage device. In one embodiment, the server 120 may modify the historical preferences of the vehicle 104 by adding the new charging location to the historical preferences or including the new charging location in statistical calculations such as averages or means.

[0078] The flowchart depicted in this article, such as Figure 1A 、 Figure 1B 、 Figure 2C 、 Figure 2D 、 Figure 2E 、 Figure 3A 、 Figure 3B and Figure 3C Each example is a separate example, but may be the same or different embodiments. Any operation in one flowchart may be adopted and shared with other flowcharts. No example operation is intended to limit any embodiment or the subject matter of the corresponding claims.

[0079] It is important to note that all flowcharts and corresponding processes are from Figure 1A 、 Figure 1B 、 Figure 2C 、 Figure 2D 、 Figure 2E 、 Figure 3A 、 Figure 3B and Figure 3C , they may be part of the same process, or they may share sub-processes with each other, allowing the figures to be combined into a single preferred embodiment that does not require any one specific operation, but performs some operations from one example process and one or more additional processes. All example processes are related to the same physical system and can be used separately or interchangeably.

[0080] Figure 2A According to example embodiment, illustrate vehicle network diagram 200.This network comprises the element that comprises vehicle 202 and vehicle 202 ', and vehicle 202 comprises processor 204, and vehicle 202 ' comprises processor 204 '.Vehicle 202,202 ' communicates with each other via processor 204,204 ', and comprises transceiver, transmitter, receiver, storage device, sensor and other elements that can provide communication (not shown).Communication between vehicle 202 and 202 ' can directly take place, takes place via dedicated and / or public network (not shown), or takes place via other vehicles and comprises one or more elements in processor, memory and software.Although be depicted as single vehicle and processor, multiple vehicles and processor can be present.Describe and / or describe one or more applications, feature, step, solution etc. herein and can be utilized and / or provide by element of the present invention.

[0081] Figure 2BAccording to example embodiment, another vehicle network diagram 210 is illustrated.This network comprises the element that comprises vehicle 202 and vehicle 202 ', and vehicle 202 comprises processor 204, and vehicle 202 ' comprises processor 204 '.Vehicle 202,202 ' is via processor 204,204 ', and comprises transceiver, transmitter, receiver, storage device, sensor and other elements (not shown) that other elements of communication can be provided to communicate with each other.Communication between vehicle 202 and 202 ' can directly take place, takes place via dedicated and / or public network (not shown), or takes place via other vehicles and comprises one or more elements in processor, memory and software.Processor 204,204 ' can also communicate with one or more elements 230, comprises sensor 212, wired device 214, wireless device 216, database 218, mobile phone 220, vehicle 222, computer 224, I / O device 226 and voice application 228. The processors 204, 204' may also be in communication with elements including one or more of a processor, memory, and software.

[0082] Although depicted as a single vehicle, processor, and element, multiple vehicles, processors, and elements may exist. Information or communication may occur to and / or from any of processors 204, 204', and element 230. For example, mobile phone 220 may provide information to processor 204, which may initiate vehicle 202 to take actions, which may further provide information or additional information to processor 204', which may initiate vehicle 202' to take actions, which may further provide information or additional information to mobile phone 220, vehicle 222, and / or computer 224. One or more applications, features, steps, solutions, etc. described and / or depicted herein may be utilized and / or provided by elements of the present invention.

[0083] Figure 2C According to an example embodiment, another vehicle network diagram 240 is illustrated. The network includes elements including a vehicle 202, a processor 204, and a non-transitory computer readable medium 242C. The processor 204 is communicatively coupled to the computer readable medium 242C and ( Figure 2B ) element 230. Vehicle 202 can be a vehicle, a server, or any device with a processor and memory.

[0084] The processor 204 performs one or more of: receiving a charging request from a vehicle (244C), determining a charging location used by other vehicles having the same preferences based on one or more preferences associated with the vehicle (246C), and routing the vehicle to the charging location based on the determination (248C).

[0085] Figure 2D According to an example embodiment, another vehicle network diagram 250 is illustrated. The network includes elements including a vehicle 202, a processor 204, and a non-transitory computer readable medium 242D. The processor 204 is communicatively coupled to the computer readable medium 242D and ( Figure 2B ) element 230. Vehicle 202 can be a vehicle, a server, or any device with a processor and memory.

[0086] The processor 204 performs one or more of the following: determining that a battery charge of the vehicle is below a threshold and including one or more preferences and the battery charge in a request (244D), routing based on the proximity of the vehicle and other vehicles to each other (245D), determining a route from the current location of the vehicle to a charging location and transmitting the route to the vehicle (246D), comparing one or more preferences associated with the vehicle to one or more historical preferences associated with the vehicle, modifying the one or more preferences in part according to the one or more historical preferences, and selecting a charging location from one or more charging locations based on the modified one or more preferences (247D), determining an area with high charging demand in proximity to the vehicle and changing preferences based on characteristics of the area (248D), and determining that the vehicle is routed to a charging location different from the charging location, determining a change in the vehicle charging preferences based on the different charging location and storing the changed vehicle charging preferences (249D).

[0087] Figure 2E According to an exemplary embodiment, yet another transportation network diagram 260 is illustrated. Figure 2E , network diagram 260 includes a vehicle 202 connected to other vehicles 202′ and an update server node 203 via a blockchain network 206. Vehicles 202 and 202′ may represent vehicles / vehicles. Blockchain network 206 may have a ledger 208 for storing software update verification data and a verification source 207 for future use (e.g., for auditing).

[0088] Although only one transport 202 is described in detail in this example, multiple such nodes can be connected to the blockchain 206. It should be understood that the transport 202 may include additional components, and some of the components described herein may be removed and / or modified without departing from the scope of this application. The transport 202 may have 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 other hardware device. Although a single processor 204 is depicted, it should be understood that the transport 202 may include multiple processors, multiple cores, etc. without departing from the scope of this application. The transport 202 may be a transport, a server, or any device with a processor and memory.

[0089] Processor 204 performs one or more of the following: receiving confirmation of an event from one or more elements described or depicted herein, wherein the confirmation includes a blockchain consensus between peers represented by any of the elements (244E), and executing a smart contract based on the blockchain consensus to record the confirmation on the blockchain (246E). Consensus is formed between any element 230 and / or any element described or depicted herein, including one or more of a transport, a server, a wireless device, etc. In another example, transport 202 can be any element 230 and / or any element described or depicted herein, including one or more of a server, a wireless device, etc.

[0090] The processor and / or computer-readable medium 242E may reside entirely or partially within or external to the vehicle. The steps or features stored in the computer-readable medium 242E may be performed entirely or partially by any processor and / or element in any order. In addition, one or more steps or features may be added, omitted, combined, performed later, etc.

[0091] Figure 2FThe diagram illustrates a diagram 265 depicting the electrification of one or more components. In one example, a vehicle 266 can provide power stored in its battery to one or more components, including other vehicle(s) 268, charging station(s) 270, and power grid(s) 272. Power grid(s) 272 are coupled to one or more charging stations 270, which can be coupled to one or more vehicles 268. This configuration allows for the distribution of electricity / power received from the vehicle 266. The vehicle 266 can also interact with the other vehicle(s) 268, such as via vehicle-to-vehicle (V2V) technology, cellular communications, WiFi, etc. The vehicle 266 can also interact with the other vehicles 268, charging station(s) 270, and / or power grid(s) 272 wirelessly and / or wiredly. In one example, the vehicle 266 is routed to (or routes itself to) power grid(s) 272, charging station(s) 270, or other vehicle(s) 268 in a safe and efficient manner. Using one or more embodiments of the present solution, the vehicle 266 can provide energy to one or more components described herein in various advantageous ways as described and / or depicted herein. Furthermore, the safety and efficiency of the vehicle can be improved, and the environment can be positively impacted as described and / or depicted herein.

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

[0093] In one example, charging station 270 manages the amount of energy transferred from vehicle 266 so that sufficient charge remains in vehicle 266 to reach its destination. In one example, a wireless connection is used to wirelessly direct the transfer of energy between vehicles 268, which may all be in motion. In one embodiment, wireless charging can be performed using a stationary charger and a vehicle's battery aligned with each other (e.g., a charging pad in a garage or parking space). In one example, an idle vehicle, such as vehicle 266 (which may be an autonomous vehicle), is directed to provide a certain amount of energy to charging station 270 and return to its original location (e.g., its original location or a different destination). In one example, 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 example, the amount of energy to be transferred to charging station 270 is determined by factors such as distance, time, traffic conditions, road conditions, environmental / weather conditions, vehicle condition (weight, etc.), the schedule of the occupant(s) using the vehicle, and the schedule of the potential occupant(s) waiting for the vehicle. In one example, vehicle(s) 268 , charging station(s) 270 , and / or power grid(s) 272 can provide energy to vehicle 266 .

[0094] In one embodiment, a location (not shown) such as a building or residence is communicatively coupled to one or more of a power grid 272, a vehicle 266, and / or a charging station(s) 270. Based on external conditions such as weather, the rate of electrical current flowing to one or more of the location, the vehicle 266, or the other vehicle(s) 268 is modified. For example, when the outside temperature is extremely high or low, increasing the likelihood of a power outage, the current flowing to the connected vehicles 266 / 268 is slowed to help minimize the likelihood of a power outage.

[0095] In one example, the solutions described and depicted herein may be used to determine the load impact on a vehicle and / or system, provide energy to the vehicle and / or system based on future demand and / or priority, and provide intelligence between a device containing a module and a vehicle, allowing a processor of the device to wirelessly communicate with the vehicle regarding the amount of energy stored in a battery on the vehicle. In one example, these solutions may also be used to provide charge from a vehicle to a location based on factors such as the temperature at the location, the cost of energy, and the power level at the location. In one example, these solutions may also be used to manage the amount of energy remaining in a vehicle after a portion of the charge is transferred to a charging station. In one example, these solutions may also be used to notify a vehicle to provide a certain amount of energy from a battery on the vehicle, where the amount of energy to be transferred is based on the distance of the vehicle to the module receiving the energy.

[0096] In one example, these solutions can also be used to use a mobile energy storage unit that uses a determined path to travel to a vehicle with excess energy and deposit the stored energy into the grid. In one example, these solutions can also be used to prioritize the need for a vehicle to provide energy to the grid, as well as the priority of the vehicle's current needs, such as the priority of passengers, or upcoming passengers, or current cargo, or upcoming cargo. In one example, these solutions can also be used to determine when a vehicle is idle and decides to maneuver to a certain location, release excess energy to the energy grid, and then return to its previous location. In one example, these solutions can also be used to determine the amount of energy required by a vehicle based on one or more conditions, such as weather, traffic, road conditions, vehicle conditions, and passengers and / or cargo in other vehicles, to provide the required energy to another vehicle via vehicle-to-vehicle energy transfer, and instruct the vehicle to route to the other vehicle and provide energy. In one example, these solutions can also be used to transfer energy from one moving vehicle to another moving vehicle. In one example, these solutions may also be used to obtain energy from a vehicle based on the energy consumed by the vehicle to reach a meeting location with another vehicle, provide the service, and the estimated energy consumed to return to the original location. In one example, these solutions may also be used to provide the remaining distance required to reach a charging station, and the charging station determines the energy to be obtained from the vehicle, where the remaining charge is based on the remaining distance. In one example, these solutions may also be used to manage vehicles that are being charged simultaneously by more than one point (such as both a charging station via a wired connection and another vehicle via a wireless connection). In one example, these solutions may also be used to apply priorities to the allocation of energy to vehicles, where priority is given to those vehicles that provide a portion of their stored charge to other entities such as an electricity grid, a residence, or the like.

[0097] In one embodiment, vehicles 266 and 268 can be used as bidirectional vehicles. Bidirectional vehicles are those that can act as mobile microgrids that can assist in supplying power to the grid 272 and / or reducing power consumption when the grid is stressed. Bidirectional vehicles incorporate bidirectional charging, and in addition to receiving a charge to the vehicle, the vehicle can also take energy from the vehicle and "push" energy back to the grid 272, also known as "V2G". In bidirectional charging, electricity flows in both directions; to the vehicle and from the vehicle. When the vehicle is charged, alternating current (AC) from the grid 272 is converted to direct current (DC). This can be done by the vehicle's own converter or one or more of the converters on the charger 270. Energy stored in the vehicle's batteries can be sent back to the grid in the opposite direction. The energy is converted from DC to AC by a converter that is typically located in the charger 270 (also known as a bidirectional charger). In addition, as discussed with respect to Figure 2F The solution described and depicted may be used in this network and / or system and other networks and / or systems.

[0098] Figure 2G2 is a diagram illustrating the interconnections between various elements 275. The present solution may be stored, in whole or in part, on and / or executed by one or more computing devices 278', 279', 281', 282', 283', 284', 276', 285', 287', and 277' associated with various entities, all of which are communicatively coupled to and in communication with a network 286. A database 287 is communicatively coupled to the network and allows for the storage and retrieval of data. In one example, 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 other vehicles 277. Other entities and / or devices, such as one or more private users using smartphones 278, laptops 280, augmented reality (AR) devices, virtual reality (VR) devices, and / or any wearable devices, may also interact with the present solution. Smartphone 278, laptop 280, microphone 285, and other devices can 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 can include various institutions. One or more public buildings 281 can utilize computing device 281'. One or more service providers 279 can include dealerships, towing services, collision centers, or other repair shops. One or more service providers 279 can utilize computing device 279'. These various computing devices can be directly and / or communicatively coupled to one another, such as via a wired network, a wireless network, a blockchain network, etc. In one example, microphone 285 can function as a virtual assistant. In one example, one or more traffic infrastructure 282 can include one or more traffic lights, one or more sensors including one or more cameras, vehicle speed sensors or traffic sensors, and / or other traffic infrastructure. One or more traffic infrastructure 282 can utilize computing device 282'.

[0099] In one embodiment, whenever charge is given to or received from a charging station and / or the grid, the entities that allow this to occur are one or more of the vehicle, the charging station, a server, and a network communicatively coupled to the vehicle, the charging station, and the grid.

[0100] In one example, transport vehicles 277 / 276 can transport people, objects, permanent or temporarily fixed devices, etc. In one example, transport vehicle 277 can communicate with transport vehicle 276 via V2V communication through a computer associated with each transport vehicle 276' and 277', and can be referred to as a transport vehicle, car, vehicle, motor vehicle, etc. Transport vehicles 276 / 277 can be self-propelled wheeled vehicles, such as cars, sports utility vehicles, trucks, buses, vans, or other motor-driven or battery-driven or fuel cell-driven transport vehicles. For example, transport vehicles 276 / 277 can be electric vehicles, hybrid vehicles, hydrogen fuel cell vehicles, plug-in hybrid vehicles, or any other type of vehicle with a fuel cell stack, motor and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, ships, and any other form of vehicle capable of transportation. Transport vehicles 276 / 277 can be semi-autonomous or autonomous. For example, transport vehicles 276 / 277 can automatically operate and navigate without human input. An autonomous vehicle may have and use one or more sensors and / or navigation units to autonomously drive itself.

[0101] In one example, the solutions described and depicted herein can be used to determine access to a vehicle via a consensus of a blockchain. In one example, these solutions can also be used to perform profile verification before allowing an occupant to use the vehicle. In one example, these solutions can also be used to enable the vehicle to indicate (visually, but in another example, verbally, etc.) the action that the user needs to perform on or from the vehicle (the action can be pre-recorded) and verify that it is the correct action. In one example, these solutions can also be used to provide a capability for the vehicle to determine how to fork the data based on the risk level associated with the data and the driving environment, and distribute a portion of the forked data with a lower risk level in a safe driving environment to the occupant, and then distribute the remaining portion of the forked data with a higher risk level to the occupant after the occupant leaves the vehicle. In one example, these solutions can also be used to handle the transfer of vehicles across borders (such as countries / states / etc.) using blockchains and / or smart contracts, and apply the rules of the new region to the vehicle.

[0102] In one example, these solutions can also be used to allow a vehicle to continue operating outside a boundary when a consensus is reached between the vehicle's operation and the characteristics of the vehicle's occupants. In one example, these solutions can also be used to analyze the vehicle's available data upload / download speed, the size of the file, and the vehicle's travel speed / direction to determine the distance required to complete the data upload / download and specify a safe area boundary for the data upload / download to be performed. In one example, these solutions can also be used to perform normally dangerous maneuvers in a safe manner, such as when the system determines that an exit is imminent and when the vehicle does not appear to be ready to exit (e.g., in an incorrect lane or traveling at a speed that is not conducive to performing an upcoming exit), and instruct the subject vehicle and other adjacent vehicles to allow the subject vehicle to exit in a safe manner. In one example, these solutions can also be used to verify the diagnosis of one or more vehicles and other vehicles using the one or more vehicles when the other vehicles are in motion.

[0103] In one example, these solutions can also be used to detect lane usage at a certain time of day at a certain location to notify vehicle occupants or direct the vehicle to recommend or not recommend lane changes. In one example, these solutions can also be used to eliminate the need to send information via email and the need for drivers / occupants to respond by email or in person. In one example, these solutions can also be used to provide services to vehicle occupants, where the services provided are subscription-based and permissions are obtained from other vehicles connected to the occupant's profile. In one example, these solutions can also be used to record changes in the condition of a leased object. In one example, these solutions can also be used to seek blockchain consensus from other vehicles in close proximity to a damaged vehicle. In one example, these solutions can also be used to receive media from a vehicle computer that may be related to an accident from a server, such as an insurance entity's server. The server accesses one or more media files to determine damage to the vehicle and stores the damage assessment on the blockchain. In one example, these solutions can also be used to obtain consensus from multiple devices at different times prior to an event related to the vehicle to determine the severity of the event.

[0104] In one example, these solutions can also be used to address the issue of a lack of video evidence for vehicle-related accidents. The current solution specifies that the vehicle involved in the accident should query accident-related media from other vehicles that may be near the accident. In one example, these solutions can also be used to record specific parts of a damaged vehicle using the vehicle and other devices (e.g., pedestrians' cell phones, streetlight cameras, etc.).

[0105] In one example, these solutions can also be used to warn occupants of a vehicle when it is approaching a hazardous area and / or event, thereby allowing the vehicle to notify occupants or a central controller of potential hazardous areas on or near the vehicle's current route. In one example, these solutions can also be used to detect when a vehicle is traveling at high speed and use at least one other vehicle to help reduce the vehicle's speed in a manner that minimizes traffic disruption. In one example, these solutions can also be used to identify hazardous driving situations, wherein the vehicle involved in the hazardous driving situation captures media. A geofence is established based on the distance of the hazardous driving situation, and additional media is captured by at least one other vehicle within the established geofence. In one example, these solutions can also be used to notify one or more occupants of a vehicle that the vehicle is approaching a traffic control sign on a road, and then receive instructions for poor driving from other nearby vehicles if the vehicle crosses the sign. In one example, these solutions can also be used to render a portion of a vehicle inoperable by (in some embodiments) limiting speed, limiting the ability to approach other vehicles, limiting speed to a maximum, and only allowing a given number of miles per time period.

[0106] In one example, these solutions can also be used to overcome the need to rely on software updates to correct problems with a vehicle when it is not operating properly. By observing other vehicles on a route, a server can receive data from potentially multiple other vehicles that have observed unsafe or incorrect operation of the vehicle. Upon analysis, these observations can result in notifications being issued to the vehicle when the data indicates unsafe or incorrect operation. In one example, these solutions can also be used to communicate between a vehicle and potentially dangerous situations involving people outside the vehicle. In one example, these solutions can also be used to send data to a server via a device associated with an accident involving the vehicle, or a device located in the vicinity of the accident. Based on the severity of the accident or near-accident, the server notifies the sender of the data. In one example, these solutions can also be used to provide vehicle drivers or passengers with recommendations for operating the vehicle based on data analysis. In one example, these solutions can also be used to establish geofences associated with physical structures and determine payment responsibilities for the vehicle. In one example, these solutions can also be used to coordinate the ability to return a vehicle at a location using both the current state at that location and a future state proposed by using navigation destinations from other vehicles. In one example, these solutions can also be used to coordinate the ability to automatically schedule vehicle returns at locations such as transportation rental entities.

[0107] In one example, these solutions can also be used to move a vehicle to a different location based on a user's event. More specifically, the system tracks the user's device and modifies the vehicle to be moved closer to the user at the end of the original or modified event. In one example, these solutions can also be used to verify available spaces within an area using existing vehicles in the area. The approximate time a space is likely to become vacant is also determined based on verification from existing vehicles. In one example, these solutions can also be used to move a vehicle to a closer parking space when a parking space becomes available and the time elapsed since the initial parking is less than the average event time. Furthermore, the vehicle can be moved to a final parking space upon completion of an event or based on the location of a device associated with at least one occupant of the vehicle. In one example, these solutions can also be used to plan parking ahead of an incoming crowd. The system interacts with vehicles to offer some services at a lower price than full fare and / or directs vehicles to alternative parking locations based on their priority, thereby improving parking optimization prior to arrival.

[0108] In one example, these solutions can also be used to sell fractional ownership of a vehicle or to determine pricing and availability for ride-sharing applications. In one example, these solutions can also be used to provide accurate and timely dealer sales activity reports that go far beyond what is currently available. In one example, these solutions can also be used to allow dealers to request assets via blockchain. By using blockchain, consensus is achieved before any asset is moved. Furthermore, the process is automated, and payments can be initiated via the blockchain. In one example, these solutions can also be used to arrange agreements with multiple entities (such as service centers), where consensus is achieved and actions (such as diagnostics) are performed. In one example, these solutions can also be used to associate digital keys with multiple users. The first user can be the vehicle operator, and the second user can be the responsible party for the vehicle. These keys are authorized by a server, where the proximity of the keys is verified against the location of the service provider. In one example, these solutions can also be used to determine the services required at the vehicle's destination. One or more service locations that can provide the required services are located, both within the area along the route to the destination and available to perform the services. The vehicle's navigation is updated using the determined service locations. A smart contract containing the compensation value for the services is identified, and the blockchain transaction is stored in a distributed ledger of transactions.

[0109] In one example, these solutions can also be used to connect service provider vehicles with the profiles of vehicle occupants to determine services and goods that may be of interest to the vehicle's occupants. These services and goods are determined by the occupants' history and / or preferences. The vehicle then receives a quote from the service provider vehicle and, in another example, meets up with the vehicle to provide the services / goods. In one example, these solutions can also be used to detect vehicles within range and send service quotes (such as maintenance quotes, product quotes, etc.) to the vehicle. An agreement is reached between the system and the vehicle, and the system selects a service provider to provide the agreement. In one example, these solutions can also be used to designate one or more vehicles as road managers, where the road managers assist in controlling traffic. Road managers can generate road indicators (such as lights, displays, and sounds) to assist in traffic flow. In one example, these solutions can also be used to alert vehicle drivers via devices, such as traffic lights or near intersections. Alerts are sent when an event occurs, such as when a green light turns green and the vehicle at the front of a line of vehicles does not move.

[0110] Figure 2H 2 is another block diagram illustrating the interconnection between various components in an example 290. A vehicle 276 is shown, including ECUs 295 and 296 and a head unit (also known as an infotainment system) 297. An electrical control unit (ECU) is an embedded system in automotive electronics that controls one or more electrical systems or subsystems in the vehicle. ECUs may include, but are not limited to, those responsible for managing the vehicle's engine, braking system, transmission system, door locks, instrument panel, airbag system, infotainment system, electronic differential, and active suspension. ECUs are connected to the vehicle's controller area network (CAN) bus 294. The ECUs can also communicate with a vehicle computer 298 via the CAN bus 294. The vehicle's processor / sensor (e.g., a vehicle computer) 298 can communicate with external components, such as a server 293, via a network 292 (e.g., the Internet). Each ECU 295, 296 and head unit 297 can contain its own security policy. The security policy defines the permissible processes that can be executed within the appropriate context. In one example, the security policy may be provided in part or in whole in the vehicle computer 298 .

[0111] ECUs 295, 296, and head unit 297 can each include a custom security feature 299 that defines authorized processes and the contexts within which these processes are allowed to run. Context-based authorization, used to determine the validity of whether a process can be executed, allows ECUs to maintain secure operation and prevent unauthorized access from components such as the vehicle's controller area network (CAN bus). When an ECU encounters an unauthorized process, it can prevent the process from running. A vehicle ECU can use various contexts to determine whether a process is running within its permitted boundaries, such as proximity contexts such as nearby objects, distance to approaching objects, speed, and trajectory relative 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; user-related contexts such as devices connected to the vehicle via wireless protocols, usage of the infotainment system, cruise control, parking assistance, and driver assistance; location-based contexts; and / or other contexts.

[0112] In one example, the solutions described and depicted herein can be used to render a portion of a vehicle inoperable by (in certain embodiments) limiting speed, restricting the ability to approach other vehicles, limiting speed to a maximum, and allowing only a certain number of miles per time period. In one example, these solutions can also be used to facilitate the exchange of vehicle ownership using blockchain, where data is sent from devices associated with an incident involving the vehicle, or devices in the vicinity of the incident, to a server. Based on the severity of the incident or near-incident, the server notifies the sender of the data. In one example, these solutions can also be used to help a vehicle avoid an accident by querying servers for other vehicles in the vicinity of the incident, such as when the vehicle is involved in an accident. The server attempts to obtain data from other vehicles, allowing the server to understand the nature of the accident from multiple vantage points. In one example, these solutions can also be used to determine that a sound emanating from the vehicle is atypical and send data related to the sound and the possible source location to the server, where the server can determine the possible cause and avoid a potentially dangerous situation. In one example, these solutions can also be used to establish a location boundary via the system when a vehicle is involved in an accident. The boundary is based on the decibel level associated with the accident. Multimedia content from devices within the boundary is obtained to help further understand the circumstances of the accident. In one example, these solutions can also be used to associate a vehicle with an accident, then capture media captured by a device near the accident location. The captured media is saved as media clips. The media clips are sent to another computing device, which constructs an audio profile of the accident. This audio profile will help to understand more details closely related to the accident.

[0113] In one example, these solutions can also be used to record audio, video, motion, etc. using sensors to record areas where potential incidents are occurring, such as if a vehicle is in contact or could potentially come into contact with other vehicles (while moving or parked). The system can then capture data from sensors that may be located on one or more vehicles and / or on fixed or moving objects. In one example, these solutions can also be used to identify a new condition of a vehicle during a vehicle incident using sensor data and compare that condition to a vehicle condition profile to determine if the vehicle is compromised, thereby enabling the safe and reliable capture of critical data from a vehicle about to be involved in an adverse incident.

[0114] In one example, these solutions can also be used to warn the occupants of a vehicle when the vehicle determines, via one or more sensors, that it is approaching or traveling along a one-way street in the wrong direction. 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. For example, the system can audibly notify the occupants that they are "approaching a one-way street." In one example, these solutions can also be used to allow vehicles to be compensated, thereby allowing owners of autonomous vehicles to monetize the data collected and stored by their vehicle sensors, thereby incentivizing owners to share their data and providing entities with additional data that can be used to improve the performance of future vehicles, provide services to owners, etc.

[0115] In one example, these solutions can also be used to increase or decrease vehicle features based on the vehicle's behavior over a period of time. In one example, these solutions can also be used to assign partial ownership to a vehicle. Sensor data associated with one or more vehicles and equipment proximate to the vehicle is used to determine a condition of the vehicle. Based on the condition, partial ownership of the vehicle is determined, and new vehicle responsibility is assigned. In one example, these solutions can also be used to provide data to a replacement / modification component, wherein the data attempts to subvert an authorized function of the replacement / modification component, and in response to non-subversion of the authorized function, allow the component to use the authorized function of the replacement / modification component.

[0116] In one example, these solutions can also be used to provide individuals with the ability to ensure that a passenger is boarding a vehicle and that the passenger arrives at a specific destination. Furthermore, the system ensures that the driver (in the case of a non-autonomous vehicle) and / or other passengers have permission to interact with the passenger. Boarding, disembarking, and location are also noted. All of this is immutably stored on the blockchain. In one example, these solutions can also be used to determine driver characteristics by analyzing driving style and other factors, so that action can be taken if the driver does not drive in a normal manner (such as the driver's previous driving style in specific conditions, such as daytime, nighttime, rain, snow, etc.). Vehicle attributes are also taken into account. These attributes include weather conditions, whether the headlights are on, whether navigation is being used, whether the head-up display is in use, the volume of the media being played, etc. In one example, these solutions can also be used to notify vehicle occupants of dangerous situations if items within the vehicle indicate that the occupants may be unaware of the situation.

[0117] In one example, these solutions can also be used to mount a calibration device on a bracket fixed to the vehicle, where various sensors on the vehicle can automatically adjust themselves based on what the calibration device should detect compared to what it actually detects. In one example, these solutions can also be used to use blockchain to require multiple service centers to reach a consensus when a vehicle requiring service sends fault information, thereby enabling remote diagnostics. This requires the other service centers to reach a consensus on the severity threshold of the data. Once consensus is reached, the service center can send the fail-safe level to the blockchain for storage. In one example, these solutions can also be used to determine discrepancies between sensor data external to the vehicle and the vehicle's own sensor data. The vehicle can then request software from a server to correct the problem. In one example, these solutions can also be used to allow messaging between nearby or nearby vehicles in the event of an incident (e.g., a collision).

[0118] See also Figure 2I , illustrates an operating environment 290A for a connected vehicle according to some embodiments. As shown, the vehicle 276 includes a controller area network (CAN) bus 291A that connects the components 292A-299A of the vehicle. Other components can be connected to the CAN bus, which is not shown here. The components shown connected to the CAN bus include a sensor group 292A, an electronic control unit 293A, an autonomous feature or advanced driver assistance system (ADAS) 294A, and a navigation system 295A. In some embodiments, the vehicle 276 includes a processor 296A, a memory 297A, a communication unit 298A, and an electronic display 299A.

[0119] The processor 296A includes an arithmetic logic unit, a microprocessor, a general purpose controller, and / or a similar processor array to perform calculations and provide electronic display signals to the display unit 299A. The processor 296A processes data signals and can include various computing architectures, including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture that implements a combination of instruction sets. The vehicle 276 may include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not shown) that are communicatively coupled to each other may be used with the present solution.

[0120] Memory 297A is the non-temporary memory of the instruction or data that storage can be accessed and performed by processor 296A.Instruction and / or data can comprise the code of execution technology described herein.Memory 297A can be dynamic random access memory (DRAM) device, static random access memory (SRAM) device, flash memory or other storage device.In certain embodiments, memory 297A can also include non-volatile memory or similar permanent storage device and medium, it can include hard disk drive, floppy disk drive, CD-ROM device, DVD-ROM device, DVD-RAM device, DVD-RW device, flash memory device or some other large-capacity storage device for permanent storage information.A part for memory 297A can be retained as buffer or virtual random access memory (virtual RAM).Without departing from current solution, transportation means 276 can include one or more memory 297A.

[0121] The memory 297A of the 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, the memory 297A stores data that may be required for the navigation application 295A to provide functionality.

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

[0123] ECU 293A controls the operation of many systems of vehicle 276, including ADAS system 294A. ECU 293A can, in response to instructions received from navigation system 295A, deactivate any unsafe and / or unselected autonomous features for the duration of a trip controlled by ADAS system 294A. Thus, navigation system 295A can control whether ADAS systems 294A are activated or enabled so that they can be activated for a given navigation route.

[0124] Sensor group 292A may include any sensor in vehicle 276 that generates sensor data. For example, sensor group 292A may include short-range sensors and long-range sensors. In some embodiments, sensor group 292A of vehicle 276 may include one or more of the following vehicle sensors: a camera, a lidar sensor, an ultrasonic sensor, a vehicle 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 air flow sensor, an engine coolant temperature sensor, a throttle position sensor, a crankshaft position sensor, a valve timing device, an air-fuel ratio meter, a blind spot meter, a curb detector, a defect 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, mapping capabilities, and any other type of vehicle sensor. Navigation system 295A may store sensor data in memory 297A.

[0125] Communication unit 298A sends and receives data to and from network 292 or other communication channels. In some embodiments, communication unit 298A may include a DSRC transceiver, a DSRC receiver, and other hardware or software required to make vehicle 276 a DSRC-equipped device.

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

[0127] In one example, the solutions described and depicted herein can be used to manage emergency situations and vehicle features when it is determined that the vehicle is about to enter an area without network access. In one example, these solutions can also be used to manage and provide features (such as audio, video, navigation, etc.) in the vehicle without a network connection. In one example, these solutions can also be used to determine when the profile of a person near the vehicle matches the profile attributes of at least one occupant in the vehicle. A notification is sent from the vehicle to establish communication.

[0128] In one example, these solutions can also be used to analyze the availability of occupants in a corresponding vehicle for voice communication based on the amount of time remaining in the vehicle and the context of the communication to be conducted. In one example, these solutions can also be used to determine a two-level threat of road congestion and receive a gesture that may indicate an alert that the congestion has not risen above a threshold, so that the vehicle can continue along the road. In one example, these solutions can also be used to delete sensitive data from a vehicle when the vehicle has been damaged, rendering it unusable.

[0129] In one example, these solutions can also be used to verify that customer data to be eliminated has indeed been eliminated from all required locations within an enterprise to demonstrate GDPR compliance. In one example, these solutions can also be used to provide compensation from one vehicle to another in exchange for data related to safety, important notifications, etc., thereby enhancing the autonomy of lower-level autonomous vehicles. In one example, these solutions can also be used to provide a vehicle with the ability to receive data based on a first biometric associated with an occupant. The vehicle then decrypts the encrypted data based on verification of a second biometric, where the second biometric is a continuation of the first biometric. When only the occupant can receive unencrypted data, the vehicle provides the unencrypted data to the occupant, deleting the sensitive portion of the unencrypted data as it is provided and deleting the non-sensitive portion after a period of time associated with the biometric has elapsed. In one example, these solutions can also be used to provide a vehicle with the ability to authenticate an individual based on weight and grip pressure applied to the vehicle's steering wheel. In one example, these solutions can also be used to provide a vehicle with a feature that exists but is not currently enabled, thereby presenting a feature reflecting the occupant's characteristics to the vehicle occupant.

[0130] In one example, these solutions may also be used to allow a vehicle, specifically its interior and exterior, to be modified to reflect and assist at least one occupant. In another example, recreating an occupant's work and / or home environment is disclosed. If the system determines that a user is in "work mode" or "home mode," the system may attempt to "recreate" the user's work / home environment while the user is in the vehicle. All data related to the vehicle's interior and exterior, as well as the individual occupants using the vehicle, is stored on a blockchain and executed via smart contracts. In one example, these solutions may also be used to detect occupant gestures to facilitate communication with nearby vehicles, which can maneuver accordingly. In one example, these solutions may also be used to provide vehicles with the ability to detect intended gestures using a gesture definition data repository. In one example, these solutions may also be used to provide vehicles with the ability to take various actions based on gait and user gestures. In one example, these solutions may also be used to ensure that a vehicle driver currently performing various maneuvers (e.g., talking while driving with navigation enabled, etc.) does not exceed an unsafe number of maneuvers before being allowed to perform a gesture.

[0131] In one example, these solutions can also be used to assign a status to each occupant in a vehicle and verify the occupant's gestures based on the occupant's status. In one example, these solutions can also be used to collect sound details related to the collision (at what location, in what direction, rising or falling, from what device, data related to the device, such as type, manufacturer, owner, and the number of sounds at the same time and the time when the sound was emitted, etc.) and provide them to the system, in which analysis of the data helps to determine the details about the collision. In one example, these solutions can also be used to determine whether the vehicle is operating unsafely. The vehicle includes multiple components that operate together to control the vehicle, and each component is associated with a separate component key. An encryption key is sent to the vehicle to reduce the vehicle's functionality. In response to receiving the encryption key, the vehicle disables one or more component keys. Disabling one or more component keys results in one or more of the following: limiting the vehicle's movement speed to no more than a given speed, limiting the vehicle to no more than a certain distance closer to other vehicles, and limiting the vehicle's travel distance to no more than a threshold distance.

[0132] In one example, these solutions can also be used to provide instructions from a specific vehicle (about to vacate a certain location) to another specific vehicle (looking to occupy a certain location), with blockchain being used to perform authentication and coordination. In one example, these solutions can also be used to determine partial ownership of a vehicle. For example, where multiple people own a single vehicle, and the system uses the use of the vehicle, which may change over time, to update partial ownership. Other embodiments will be included in this application, including minimum ownership of a vehicle based not on vehicle use, but on vehicle availability, identification of the vehicle's driver, and other factors.

[0133] In one example, these solutions can also be used to allow a user in a transportation vehicle to share his / her subscription with a group of close people such as family members or friends. For example, a user may want to share a membership, and if so, the associated transactions will be stored on the blockchain or in a traditional database. When a user who is not the primary subscriber requests subscribed materials, the blockchain node (i.e., the transportation vehicle) can verify that the person requesting the service is an authorized person with whom the subscriber has shared the profile. In one example, these solutions can also be used to allow a person to utilize (one or more) auxiliary transportation vehicles to reach the intended destination. When determining the auxiliary transportation vehicle, functional relationship values are used (e.g., values indicating various parameters and their importance in determining what type of alternative transportation vehicle to utilize). In one example, these solutions can also be used to allow occupants in an accident to continue to their original destination using other transportation vehicles.

[0134] In one example, these solutions can also be used to propagate software / firmware uploads to a first subset of vehicles. The first group of vehicles tests the update, and when the test is successful, the update is propagated to another group of vehicles. In one example, these solutions can also be used to propagate a software / firmware update from a master vehicle to vehicles, where the update propagates from the first subset via the vehicle network, then from a larger subset, and so on. A portion of the update can be sent first, followed by the remainder from the same vehicle or another vehicle. In one example, these solutions can also be used to provide updates to vehicle computers to devices belonging to vehicles and vehicle operators / occupants. The update can be authorized by all drivers and / or all occupants. The software update is provided to the vehicle and device(s). The user does not need to do anything; simply approach the vehicle and the function occurs automatically. A notification is sent to the device(s) indicating that the software update has been completed. In one example, these solutions can also be used to verify that the OTA software update was performed by a qualified technician, and to generate status by one or more vehicle components related to the originator of the verification code, the process used to wirelessly receive the software update, the information contained in the software update, and the results of the verification.

[0135] In one example, these solutions can also be used to provide the ability for a second component to parse a software update located in a first component. A first portion of a critical update and a second portion of a non-critical update can then be verified, the verified first portion can be assigned to a process in the vehicle, the verified first portion can be run using the one process for a period of time, and in response to a positive result based on the period of time, the verified first portion can be run using another process after the period of time. In one example, these solutions can also be used to provide a selection of services to occupants of the vehicle, wherein the services are based on the profile of the occupant of the vehicle and a shared profile shared with the occupant's profile. In one example, these solutions can also be used to store user profile data in a blockchain and intelligently present special offers and recommendations to the user based on the user's automatically collected purchase history and preferences obtained from the user profile on the blockchain.

[0136] In order for a vehicle to be adequately protected, it must be protected from both unauthorized physical access and unauthorized remote access (e.g., cyber threats). To prevent unauthorized physical access, in one example, the vehicle is equipped with a secure access system, such as keyless entry. Alternatively, in one example, security protocols are added to the vehicle's computers and computer networks to facilitate secure remote communications to and from the vehicle.

[0137] Electronic Control Units (ECUs) are nodes within a vehicle that control tasks such as activating windshield wipers to anti-lock brakes. ECUs are typically connected to each other via the vehicle's central network, which can be referred to as a Controller Area Network (CAN). State-of-the-art features such as autonomous driving rely heavily on implementing new, complex ECUs, such as 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 them more vulnerable to attack. The following are some examples of protecting vehicles from physical and remote intrusion.

[0138] Figure 2J According to an exemplary embodiment, a keyless entry system 290B is illustrated for preventing unauthorized physical access to a vehicle 291B. Figure 2J In one example, the remote control key 292B uses a radio frequency signal to send a command to the vehicle 291B. In this example, the remote control key 292B includes a transmitter 2921B having an antenna capable of transmitting short-range wireless signals. The vehicle 291B includes a receiver 2911B having an antenna capable of receiving short-range wireless signals sent from the transmitter 2921B. The remote control key 292B and the vehicle 291B also include CPUs 2922B and 2913B, respectively, for controlling the corresponding devices. Here, the CPUs 2922B and 2913B have memories (or memories accessible to the CPUs). In one example, the remote control key 292B and the vehicle 291B include power supplies 2924B and 2915B, respectively, for powering the corresponding devices.

[0139] When the user presses the button 293B on the remote control key 292B (or otherwise activates the remote control key, etc.), the CPU 2922B wakes up in the remote control key 292B and sends a data stream to the transmitter 2921B, which is output via the antenna. In other embodiments, the user's intention is confirmed on the remote control key 292B via other means, such as via a microphone that receives audio, a camera that captures images and / or video, or other sensors commonly used in the art to detect the user's intention, including receiving gestures, actions, eye movements, etc. The data stream can be a signal of 64 bits to 128 bits in length, which includes one or more of a preamble, a command code, and a rolling code. The signal can be sent at a rate between 2 kHz and 20 kHz, but the embodiment is not limited to this. In response, receiver 2911B of vehicle 291B captures the signal from transmitter 2921B, demodulates the signal, and sends a data stream to CPU 2913B, which decodes the signal and sends a command (e.g., lock door, open door, etc.) to command module 2912B.

[0140] If the fob 292B and vehicle 291B use a fixed code between them, a replay attack is possible. In this case, if an attacker can capture / sniff the fixed code during short-range communication, the attacker can replay this code to gain access to vehicle 291B. To increase security, the fob and vehicle 291B can use a rolling code that changes after each use. Here, the fob 292B and vehicle 291B synchronize with an initial seed 2923B (e.g., a random number, pseudo-random number, etc.). This is called pairing. The fob 292B and vehicle 291B also include a shared algorithm for modifying the initial seed 2914B each time a button 293B is pressed. The subsequent key press will use the result of the previous key press as input and transform it into the next number in the sequence. In some cases, the vehicle 291B can store multiple next codes (e.g., 255 next codes) in case the vehicle 291B fails to detect a key press on the fob 292B. Therefore, multiple key presses on the fob 292B that are not heard by the vehicle 291B do not prevent the vehicle from becoming out of sync.

[0141] In addition to rolling codes, the 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 the transmitter 2921B and the receiver 2911B may be used to establish a secure session. As another example, the codes may have a finite expiration time or timeout. Additionally, as discussed with respect to Figure 2J The present solution described and depicted may be used in this network and / or system and other networks and / or systems, including those described and depicted herein.

[0142] Figure 2K According to an exemplary embodiment, a controller area network (CAN) 290C within a vehicle is illustrated. Figure 2K , CAN 290C includes a CAN bus 297C having a high-level terminal and a low-level terminal, and a plurality of electronic control units (ECUs) 291C, 292C, 293C, etc. connected to the CAN bus 297C via a wired connection. The CAN bus 297C is designed to allow microcontrollers and devices to communicate with each other in applications without a host computer. The 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 root level. At the same time, ECUs 291C-293C represent controllers for controlling electrical systems or subsystems within a vehicle. Examples of electrical systems include power steering, anti-lock brakes, air conditioning, tire pressure monitoring, cruise control, and many other features.

[0143] In this example, ECU 291C includes a transceiver 2911C and a microcontroller 2912C. The transceiver can be used to send and receive messages to and from a CAN bus 297C. For example, transceiver 2911C can convert data from microcontroller 2912C into a format for CAN bus 297C, and can also convert data from CAN bus 297C into a format for microcontroller 2912C. In another example, microcontroller 2912C interprets messages and, using the ECU software installed therein, determines what messages to send.

[0144] To protect the CAN 290C from network threats, various security protocols can be implemented. For example, sub-networks (e.g., sub-networks A and B, etc.) can be used to divide the CAN 290C into smaller sub-CANs, thereby limiting the ability of an attacker to remotely access the transport. Figure 2K In the example, ECUs 291C and 292C can be part of the same subnet, while ECU 293C is part of a separate subnet. Furthermore, a firewall 294C (or gateway, etc.) can be added to prevent messages from traversing the CAN bus 297C across subnets. If an attacker gains access to one subnet, they will not be able to access the entire network. In one example, to make the subnets more secure, the most critical ECUs are not placed on the same subnet.

[0145] although Figure 2K Although not shown, other examples of security controls within CAN include an intrusion detection system (IDS), which can be added to each subnet and read all data transmissions to detect malicious messages. If a malicious message is detected, the IDS can notify the car 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 enables messages to authenticate themselves.

[0146] In addition to protecting the internal network of a vehicle, the vehicle can also be protected when communicating with external networks such as the Internet. One of the benefits of having a vehicle connection to a data source such as the Internet is that information from the vehicle can be sent to a remote location via the network for analysis. Examples of vehicle information include GPS, onboard diagnostics, tire pressure, etc. These communication systems are often referred to as telematics because they involve the combination of telecommunications and informatics. In addition, as discussed in Figure 2K The present solution described and depicted may be used in this network and / or system and other networks and / or systems, including those described and depicted herein.

[0147] Figure 2LAccording to an example embodiment, a secure end-to-end transport communication channel is illustrated. Figure 2L , telematics network 290D includes a vehicle 291D and a host server 295D located at a remote location (e.g., a network server, a cloud platform, a database, etc.) and connected to the vehicle 291D via a network such as the Internet. In this example, a device 296D associated with host server 295D can be installed within the network within vehicle 291D. In addition, although not shown, device 296D can be connected to other components of vehicle 291D, such as a CAN bus, an on-board diagnostic (ODBII) port, a GPS system, a SIM card, a modem, etc. Device 296D can collect data from any of these systems and transmit the data to server 295D via the network.

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

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

[0150] In addition to communicating with external servers, vehicles can also communicate with each other. In particular, vehicle-to-vehicle (V2V) communication systems enable vehicles to communicate with each other, roadside infrastructure (e.g., traffic lights, signs, cameras, parking meters, etc.) and the like via wireless networks. Wireless networks may include one or more of Wi-Fi networks, cellular networks, dedicated short-range communication (DSRC) networks, and the like. Vehicles can use V2V communication to provide other vehicles with information about the speed, acceleration, braking, and direction of the vehicle, to name a few. Thus, vehicles can be aware of conditions ahead before such conditions become visible, thereby significantly reducing collisions. In addition, as discussed with respect to Figure 2L The present solution described and depicted may be used in this network and / or system and other networks and / or systems, including those described and depicted herein.

[0151] Figure 2M According to an example embodiment, an example 290E of vehicles 293E and 292E using security certificates for secure V2V communication is illustrated. Figure 2M Vehicles 293E and 292E can communicate via V2V communication over a short-range network, a cellular network, or the like. Before sending a message, vehicles 293E and 292E can sign the message using their respective public key certificates. For example, vehicle 293E can sign a V2V message using public key certificate 294E. Similarly, vehicle 292E can sign a V2V message using public key certificate 295E. In one example, public key certificates 294E and 295E are associated with vehicles 293E and 292E, respectively.

[0152] When receiving each other's communication, the transport can verify the signature with the certificate authority 291E or the like. For example, the transport 292E can verify with the certificate authority 291E that the public key certificate 294E used by the transport 293E to sign the V2V communication is authentic. If the transport 292E successfully verifies the public key certificate 294E, the transport knows that the data comes from a legitimate source. Similarly, the transport 293E can verify with the certificate authority 291E that the public key certificate 295E used by the transport 292E to sign the V2V communication is authentic. In addition, as described in relation to Figure 2M The present solution described and depicted may be used in this network and other networks and / or systems, including those described and depicted herein.

[0153] Figure 2N According to an example embodiment, another diagram 290F is illustrated depicting an example of a vehicle interacting with a secure processor and a wireless device. In some embodiments, Figure 2BThe computer 224 shown in FIG. 1 may include a computer 224 as shown in FIG. Figure 2N The security processor 292F shown in the example of the process 290F is shown. In particular, the security processor 292F can perform authorization, authentication, cryptography (e.g., encryption), etc. on data transmissions sent between ECUs and other devices on the vehicle's CAN bus, as well as data messages sent between different vehicles.

[0154] exist Figure 2N In the example of FIG. 2 , the security processor 292F may include an authorization module 293F, an authentication module 294F, and a cryptographic module 295F. The security processor 292F may be implemented within a vehicle's computer and may communicate with other vehicle components, such as an ECU / CAN network 296F, wired and wireless devices 298F, such as wireless network interfaces, input ports, and the like. The security processor 292F may ensure that data frames (e.g., CAN frames, etc.) sent within the vehicle (e.g., via the ECU / CAN network 296F) are secure. Similarly, the security processor 292F may ensure that messages sent between different vehicles and devices attached or connected to the vehicle's computer via wires are also protected.

[0155] For example, the authorization module 293F can store passwords, usernames, PIN codes, biometric scans, etc. for different vehicle users. The authorization module 293F can determine whether a user (or technician) has the right to access certain settings, such as the vehicle's computer. In some embodiments, the authorization module can communicate with a network interface to download any necessary authorization information from an external server. When a user desires to change vehicle settings or modify the technical details of a vehicle via a console or GUI within the vehicle, or via an attached / connected device, the authorization module 293F can require the user to verify themselves in some way before such settings are changed. For example, the authorization module 293F may require a username, password, PIN code, biometric scan, predefined line drawing or gesture, etc. In response, the authorization module 293F can determine whether the user has the necessary permissions (access, etc.) requested.

[0156] The authentication module 294F can be used to authenticate internal communications between ECUs on the vehicle's CAN network. For example, the authentication module 294F can provide information for authenticating communications between ECUs. For example, the authentication module 294F can send a bit signature algorithm to the ECU of the CAN network. The ECU can use the bit signature algorithm to insert authentication bits into the CAN field of the CAN frame. All ECUs on the CAN network typically receive each CAN frame. Whenever one of the ECUs generates a new CAN frame, the bit signature algorithm can dynamically change the position, number, etc. of the authentication bits. The authentication module 294F can also provide a list of ECUs that are exempted and do not need to use authentication bits (a security list). The authentication module 294F can communicate with a remote server to retrieve updates to the bit signature algorithm, etc.

[0157] The encryption module 295F can store asymmetric key pairs that the vehicle can use to communicate with other external user devices and vehicles. For example, the encryption module 295F can provide a private key that the vehicle can use to encrypt / decrypt communications, while the corresponding public key can be provided to other user devices and vehicles to enable other devices to decrypt / encrypt communications. The encryption module 295F can communicate with a remote server to receive new keys, key updates, keys for new vehicles, users, etc., and the like. The encryption module 295F can also send any updates to the local private / public key pair to the remote server.

[0158] Figure 3A According to an example embodiment, a flow chart 300 is illustrated. Figure 3A , flowchart 300 includes one or more of: receiving a charging request from a vehicle ( 302 ), determining, based on one or more preferences associated with the vehicle, a charging location used by other vehicles having the same preferences ( 304 ), and routing the vehicle to the charging location based on the determination ( 306 ).

[0159] Figure 3B According to an example embodiment, yet another flow chart 320 is illustrated. Figure 3B, flowchart 320 includes one or more of the following: determining that a battery charge of a vehicle is below a threshold and including one or more preferences and the battery charge in a request (322), routing based on the proximity of the vehicle and other vehicles to each other (323), determining a route from the current location of the vehicle to a charging location and transmitting the route to the vehicle (324), comparing one or more preferences associated with the vehicle to one or more historical preferences associated with the vehicle, partially modifying the one or more preferences according to the one or more historical preferences, and selecting a charging location from one or more charging locations based on the modified one or more preferences (325), determining an area with high charging demand adjacent to the vehicle and changing preferences based on characteristics of the area (326), and determining that the vehicle is routed to a charging location different from the charging location, determining a change in the vehicle charging preferences based on the different charging location and storing the changed vehicle charging preferences (327).

[0160] Figure 3C According to an example embodiment, yet another flow chart 340 is illustrated. Figure 3C , the flow chart includes receiving confirmation of an event from one or more elements described or depicted herein, wherein the confirmation includes a blockchain consensus between peers represented by any of the elements (342), and executing a smart contract based on the blockchain consensus to record the confirmation on a blockchain (344).

[0161] Figure 4 According to an example embodiment, a machine learning vehicle network diagram 400 is illustrated. The network 400 includes a vehicle 402 interfaced with a machine learning subsystem 406. The vehicle includes one or more sensors 404.

[0162] Machine learning subsystem 406 includes learning model 408, which is a mathematical artifact created by machine learning training system 410, which generates predictions by finding patterns in one or more training data sets. In some embodiments, machine learning subsystem 406 resides in vehicle 402. In other embodiments, machine learning subsystem 406 resides outside vehicle 402.

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

[0164] In yet another embodiment, vehicle 402 can send data from one or more sensors 404 to machine learning training system 410. In another example, machine learning subsystem 406 can send data from sensor 404 to machine learning subsystem 410. One or more applications, features, steps, solutions, etc. described and / or depicted herein can utilize machine learning network 400 as described herein.

[0165] Figure 5A According to an example embodiment, an example vehicle configuration 500 for managing database transactions associated with a vehicle is illustrated. Figure 5A When a particular vehicle / vehicle 525 participates 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 in accordance with the transaction(s). A vehicle processor 526 resides in the vehicle 525, and communication occurs between the vehicle processor 526, a database 530, the vehicle processor 526, and the transaction module 520. The transaction module 520 may record information such as assets, parties, credits, service descriptions, dates, times, locations, results, notifications, and incidents. These transactions in the transaction module 520 may be replicated to the database 530. The database 530 may be a SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, or a distributed ledger, and may be located on or off the vehicle, accessible directly and / or via a network, or accessible by the vehicle.

[0166] Figure 5BAccording to an example embodiment, an example vehicle configuration 550 for managing database transactions between various vehicles is illustrated. When a vehicle reaches a state where it needs to share services with other vehicles, vehicle 525 can contact other vehicles 508 to perform various actions, such as sharing, transferring, or placing a service call. For example, vehicle 508 may need to be charged and / or may have a tire problem, and may be en route to pick up a package for delivery. Vehicle processor 528 resides in vehicle 508, and communication occurs between vehicle processor 528, database 554, and transaction module 552. Vehicle 508 can notify other vehicles 525 in its network and operating on its blockchain membership services. Vehicle processor 526 resides in vehicle 525, and communication occurs between vehicle processor 526, database 530, vehicle processor 526, and transaction module 520. Vehicle 525 can then request information to pick up a package from vehicle 508 and / or from a server (not shown) via wireless communication. The transaction is recorded in transaction modules 552 and 520 of both vehicles. Points are transferred from vehicle 508 to vehicle 525, and the transfer service record is recorded in database 530 / 554, assuming that the blockchains are different from each other, or recorded in the same blockchain used by all members. Database 554 can be one of an SQL database, RDBMS, relational database, non-relational database, blockchain, distributed ledger, and can be on the vehicle, off the vehicle, directly accessible and / or accessible via the network.

[0167] Figure 6A According to an example embodiment, a blockchain architecture configuration 600 is illustrated. Figure 6A , the blockchain architecture 600 may include certain blockchain elements, such as a set 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 parties, but is only accessible to those members who have permission to access the blockchain data. Blockchain nodes participate in many activities, such as blockchain entry addition and verification processing (consensus). One or more of the blockchain nodes can endorse entries based on an endorsement policy and can provide ordering services for all blockchain nodes. Blockchain nodes can initiate blockchain actions (such as authentication) and attempt to write to the blockchain's immutable ledger stored in the blockchain, a copy of which can also be stored on the supporting physical infrastructure.

[0168] When a transaction is accepted and approved by the consensus model specified by the member nodes, the blockchain transaction 620 is stored in the computer's memory. The approved transaction 626 is stored in the current block of the blockchain and submitted to the blockchain through a commit process that includes hashing the data content of the transaction in the current block and referencing the previous hash value of the previous block. Within the blockchain, one or more smart contracts 630 may exist, defining the terms of the transaction protocol and behavior contained in the smart contract executable application code 632, such as registered recipients, vehicle characteristics, requirements, permissions, sensor thresholds, etc. This code can be configured to identify whether the requesting entity is registered to receive vehicle services, which service characteristics they are entitled / required to receive based on their profile status, and whether to monitor their behavior in subsequent events. For example, when a service event occurs and a user is riding in a vehicle, sensor data monitoring may be triggered. A parameter, such as the vehicle's charge level, may be identified as being above or below a certain threshold for a specific period of time. The result may be a change in the current state, which requires an alert to be sent to a management party (i.e., the vehicle owner, vehicle operator, server, etc.), so that the service can be identified and stored for reference. The collected vehicle sensor data can be based on the type of sensor data used to collect information related to the vehicle's state. Sensor data can also form the basis for vehicle event data 634, such as the location(s) to be traveled, average speed, maximum speed, acceleration rate, whether there have been any collisions, whether the intended route was taken, the next destination, whether safety measures are in place, whether the vehicle has sufficient charge / fuel, etc. All of this information can be the basis for smart contract terms 630 that are subsequently stored in the blockchain. For example, sensor thresholds stored in the smart contract can be used as the basis for determining whether a detected service is necessary, and when and where the service should be performed.

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

[0170] Smart contract application code 644 provides the foundation for blockchain transactions by establishing application code that, when executed, validates the terms and conditions of the transaction. When executed, smart contract 630 generates certain approved transactions 626, which are then forwarded to blockchain platform 652. The platform includes security / authorization 658, a computing device 656 that performs transaction management, and a storage component 654 that acts as a memory for storing transactions and smart contracts in the blockchain.

[0171] A blockchain platform can include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and supporting 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 can expose interfaces that provide access to the virtual execution environment required to process program code and interface with the physical infrastructure. Cryptographic trust services can be used to verify entries, such as asset exchange entries, and keep the information private.

[0172] Figure 6A and Figure 6B The blockchain architecture configuration can process and execute program / application code through one or more interfaces exposed by the blockchain platform and the services provided. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or other notifications affected by changes, updates, etc. The smart contracts themselves can be used to identify rules associated with authorization and access requirements, as well as the use of the ledger. For example, information can include a new entry that can be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The results can include a decision to reject or approve the new entry based on criteria defined in the smart contract and / or consensus among peers. Physical infrastructure can be used to retrieve any data or information described herein.

[0173] Smart contracts can be created using high-level applications and programming languages within smart contract executable code and subsequently written to blocks within a blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated via a blockchain (e.g., a distributed network of blockchain peers). An entry is the execution of the smart contract code, which can occur in response to the satisfaction of a condition associated with the smart contract. The execution of a smart contract can trigger trusted changes to the state of the digital blockchain ledger. The changes to the blockchain ledger resulting from the execution of the smart contract can be automatically replicated across the distributed network of blockchain peers via one or more consensus protocols.

[0174] Smart contracts can write data to the blockchain in the form of key-value pairs. Furthermore, smart contract code can read values stored on the blockchain and use them in application operations. Smart contract code can write the outputs of various logical operations to the blockchain. The code can be used to create temporary data structures within a virtual machine or other computing platform. Data written to the blockchain can be public and / or encrypted to maintain privacy. Temporary data used or generated by smart contracts is stored in memory by the provided execution environment and then deleted once the data required by the blockchain is identified.

[0175] The smart contract executable code may include a code interpretation of the smart contract and have additional features. As described herein, the smart contract executable code may be program code deployed on a computing network where it is executed and verified by chain validators in a consensus process. The smart contract executable code receives the hash value and retrieves from the blockchain a hash value associated with a data template created by utilizing a previously stored feature extractor. If the hash value of the hashed identifier matches the hash value created from the stored identifier template data, the smart contract executable code sends the authorization key to the requesting service. The smart contract executable code may be written to blockchain data associated with encryption details.

[0176] Figure 6C According to an example embodiment, a blockchain configuration for storing blockchain transaction data is illustrated. Figure 6C , an example configuration 660 provides a vehicle 662, a user device 664, and a server 666 that share information with a distributed ledger (i.e., blockchain) 668. The server may represent a service provider entity that queries a vehicle service provider to share user profile rating information in the event that a known and established user profile attempts to rent a vehicle with an established rating profile. The server 666 may be receiving and processing data related to service requirements for the vehicle. When a service event occurs, such as vehicle sensor data indicating a need for fuel / charging, maintenance service, etc., a smart contract may be used to invoke rules, thresholds, sensor information collection, etc., which may be used to invoke a vehicle service event. For each transaction, such as an access event, a subsequent update to the vehicle's service status, an event update, etc., blockchain transaction data 670 is saved. Transactions may include parties, requirements (e.g., 18 years of age or older, eligible candidate for service, valid driver's license, etc.), compensation levels, distance traveled during the event, registered recipients allowed access to the event and managed vehicle services, permissions / permissions, sensor data retrieved during vehicle event operations to record details of a service event and identify the vehicle's health status, and thresholds used to determine whether the service event is completed and whether the vehicle's health status has changed.

[0177] Figure 6D According to an example embodiment, a blockchain block 680 that may be added to a distributed ledger is illustrated, along with the contents of block structures 682A-682n. Figure 6D , a client (not shown) can submit entries to a blockchain node to perform activities on the blockchain. For example, a client can be an application acting on behalf of a requester such as a device, person, or entity to propose an entry for the blockchain. Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and a copy of the distributed ledger. There may be different types of blockchain nodes / peers in the blockchain network, including endorsing peers that simulate and endorse entries proposed by clients, and committing peers that verify endorsements, validate entries, and submit entries to the distributed ledger. In this example, a blockchain node can play the role of an endorser node and / or a committer node.

[0178] The system consists of a blockchain that stores immutable ordered records in blocks, and a state database (current world state) that maintains the current state of the blockchain. One distributed ledger can exist for each channel, and each peer maintains its own copy of the distributed ledger for each channel of which they are a member. The blockchain is a log of entries that is a hash-linked series of blocks, where each block contains a sequence of N entries. Blocks can include Figure 6D The various components shown in . Blocks are linked by adding the hash of the previous block's header to the current block's header. 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, due to the linking, the latest block in the blockchain represents every entry that came before it. This blockchain can be stored on a peer-to-peer file system (local or attached storage) that supports append-only blockchain workloads.

[0179] The current state of a blockchain or distributed ledger can be stored in a state database. Here, the current state data represents the latest values of all keys ever contained in the blockchain's chain entry log. Smart contract executable code calls execute entries against the current state in the state database. To make these smart contract executable code interactions extremely efficient, the latest values of all keys are stored in the state database. The state database can include an indexed view of the blockchain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored on peer startup (or generated on demand) before an entry is accepted.

[0180] An endorsing peer receives an entry from the client and endorses it based on the simulation results. The endorsing peer hosts the smart contract that simulates the entry proposal. When an endorsing peer endorses an entry, it creates an entry endorsement, which is a signed response from the endorsing peer to the client application indicating its endorsement of the simulated entry. The method for endorsing an entry depends on an endorsement policy that can be specified within the smart contract executable code. An example of an endorsement policy is "a majority of endorsing peers must endorse the entry." Different channels can have different endorsement policies. The endorsed entry is forwarded by the client application to the ordering service.

[0181] The ordering service accepts endorsed entries, orders them into blocks, and delivers blocks to committing peers. For example, the ordering service can initiate a new block when a threshold of entries has been reached, a timer has expired, or other conditions have occurred. In this example, the blockchain node is the committing peer that has received data block 682A for storage on the blockchain. The ordering service can be composed of a group of orderers. The ordering service does not handle entries, smart contracts, or maintain a shared ledger. Instead, the ordering service can accept endorsed entries and specify the order in which they are submitted to the distributed ledger. The architecture of the blockchain network can be designed so that the specific implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0182] Entries are written to the distributed ledger in a consistent order. This ordering is established to ensure that updates to the state database are valid when they are submitted to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin), where ordering is achieved through solving cryptographic puzzles or mining, in this case, parties to the distributed ledger can choose the ordering mechanism that best suits the network.

[0183] See also Figure 6D, a block 682A (also referred to as a data block) stored on 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 appreciated that the various descriptions of blocks and their contents, such as block 682A and its contents, are for example purposes only and are not intended to limit the scope of the example embodiments. In some cases, both block header 684A and block metadata 688A may be smaller than transaction-specific data 686A, which stores entry data; however, this is not required. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 690A-690n. Block 682A may also include a link to a previous block (e.g., on a blockchain) within block header 684A. In particular, block header 684A may include a hash of the previous block's block header. Block header 684A may also include a unique block number, a hash of block data 690A of the current block 682A, and the like. The block number of block 682A may be unique and assigned in an increasing / sequential order starting from zero. The first block in a blockchain may be referred to as a genesis block, which includes information about the blockchain, its members, the data stored therein, and the like.

[0184] The block data 690A may store entry information for each entry recorded within the block. For example, the entry data may include one or more of the 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) identity such as public key and certificate, client signature, endorser identity, endorser signature, proposal hash, smart contract executable code event, response status, namespace, read set (a list of keys and versions read by the entry, etc.), write set (a list of keys and values, etc.), start key, end key, key list, Merkle tree query digest, etc. The entry data may be stored for each of the N entries.

[0185] In some embodiments, block data 690A may also store transaction-specific data 686A that adds additional information to the hash chain of blocks in the blockchain. Thus, data 686A may be stored in an immutable log of the block on the distributed ledger. Some of the benefits of storing such data 686A are reflected in the various embodiments disclosed and described herein. Block metadata 688A may store multiple fields of metadata (e.g., as byte arrays, etc.). Metadata fields may include a signature at block creation, a reference to the latest configuration block, an entry filter identifying valid and invalid entries within the block, the persistent latest offset of the ordering service that orders the block, and the like. The signature, latest configuration block, and orderer metadata may be added by the ordering service. Furthermore, the block's submitter (e.g., a blockchain node) may add validity / invalidity information based on endorsement policies, verification of read / write sets, and the like. The entry filter may include a byte array equal in size to the number of entries in block data 610A and a verification code identifying whether an entry is valid / invalid.

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

[0187] The above embodiments may be implemented using hardware, a computer program executed by a processor, firmware, or a combination thereof. The computer program may be contained 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.

[0188] An exemplary storage medium may be coupled to a processor such that the processor can read information from and write information to the storage medium. In an alternative embodiment, the storage medium may be an integral part of the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In an alternative embodiment, the processor and the storage medium may exist as discrete components. For example, Figure 7The diagram illustrates an example computer system architecture 700 that may be representative of or integrated into any of the above components, among others.

[0189] Figure 7 It is not intended to imply any limitation on the scope of use or functionality of the embodiments of the present application described herein.In any case, computing node 700 is capable of implementing and / or performing any of the functions set forth above.

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

[0191] 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 specific tasks or implement specific abstract data types. Computer system / server 702 may be practiced 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.

[0192] like Figure 7 , a computer system / server 702 in a cloud computing node 700 is shown in the form of a general-purpose computing device. Components of 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 that couples various system components, including system memory 706, to processor 704.

[0193] A bus refers to one or more of any 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 the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0194] Computer system / server 702 generally includes various computer system-readable media. Such media can be any available media accessible to computer system / server 702, and include volatile and non-volatile media, removable and non-removable media. In one example, system memory 706 implements the flowcharts of the other figures. System memory 706 can include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 708 and / or cache memory 710. Computer system / server 702 can also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, memory 706 can be provided for reading and writing non-removable, non-volatile magnetic media (not shown, commonly referred to as a "hard drive"). Although not shown, a disk drive for reading and writing removable, non-volatile disks (e.g., "floppy disks") can be provided, as well as an optical drive for reading or writing removable, non-volatile optical disks, such as CD-ROMs, DVD-ROMs, or other optical media. In such cases, each can be connected to the bus via one or more data media interfaces. As further depicted and described below, the memory 706 may include at least one program product having a set (eg, at least one) of program modules configured to implement the functions of various embodiments of the present application.

[0195] By way of example and not limitation, a program / utility having a set (at least one) of program modules, as well as an operating system, one or more application programs, other program modules, and program data may be stored in memory 706. Each or some combination of the operating system, one or more application programs, other program modules, and program data may include an implementation of a network environment. The program modules typically implement the functions and / or methods of the various embodiments of the present application as described herein.

[0196] It will be appreciated by those skilled in the art that various aspects of the present application may be embodied as a system, method or computer program product. Thus, various aspects of the present application may take the form of a pure hardware embodiment, a pure software embodiment (including firmware, resident software, microcode, etc.) or an embodiment in combination with software and hardware, which may be generally referred to as a "circuit," "module," or "system" in this article. In addition, various aspects of the present application may take the form of a computer program product contained in one or more computer-readable media having a computer-readable program code contained thereon.

[0197] The computer system / server 702 can also communicate via I / O devices 712 (such as I / O adapters) with one or more external devices that may include a keyboard, a pointing device, a display, a voice recognition module, etc., one or more devices that enable a user to interact with the computer system / server 702, and / or any device (such as a network card, a modem, etc.) that enables the computer system / server 702 to communicate with one or more other computing devices. Such communication can be carried out via the I / O interface of the device 712. In addition, the computer system / server 702 can communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (such as the Internet) via a network adapter. As shown, the device 712 communicates with other components of the computer system / server 702 via a bus. It should be understood that although not shown, other hardware and / or software components can be used in conjunction with the computer system / server 702. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archiving storage systems.

[0198] Although exemplary embodiments of at least one of the systems, methods, and non-transitory computer-readable media are shown in the accompanying drawings and described in the detailed description above, it should be understood that the present application is not limited to the disclosed embodiments, but rather allows for numerous rearrangements, modifications, and substitutions as set forth and defined in the following claims. For example, the capabilities of the systems of the various figures can be accomplished by one or more modules or components described herein or in a distributed architecture, and can include transmitters and / or receivers. For example, all or part of the functions performed by a single module can be performed by one or more of these modules. In addition, the functions described herein can be performed at different times in relation to various events inside or outside the module or component. In addition, the information sent between the modules can be sent between the modules via at least one of the following: a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or through multiple protocols. In addition, messages sent or received by any module can be sent or received directly and / or via one or more other modules.

[0199] Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, a server, a console, a personal digital assistant (PDA), a cellular telephone, a tablet computing device, a smartphone, or any other suitable computing device, or a combination of devices. Representing the above functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but is intended to provide an example of many embodiments. In practice, the methods, systems, and apparatus disclosed herein may be implemented in both localized and distributed forms consistent with computing technology.

[0200] It should be noted that some of the system features described in this specification are presented as modules to more particularly emphasize their implementation independence. For example, modules can be implemented as hardware circuits, including custom very large scale integrated circuit (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. Modules can also be implemented using programmable hardware devices, such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, and the like.

[0201] Modules can also be implemented at least in part in software so that they can be executed by various types of processors. For example, an identified executable code unit can include one or more physical or logical blocks of computer instructions, which can be organized into objects, procedures, or functions, for example. However, the executable code of the identified modules need not be physically located together, but can include different instructions stored in different locations, which, when logically connected together, constitute the module and achieve the intended purpose of the module. In addition, the module can be stored on a computer-readable medium, which can be, for example, a hard drive, a flash memory device, a random access memory (RAM), a magnetic tape, or any other such medium for storing data.

[0202] In practice, an executable code module can be one instruction or multiple instructions, and can even be distributed across several different code segments, different programs, and several storage devices. Similarly, operational data can be identified and illustrated within a module herein, can be embodied in any suitable form, and can be organized within any suitable type of data structure. Operational data can be collected as a single data set, or can be distributed across different locations, included on different storage devices, and can exist at least in part solely as electronic signals on a system or network.

[0203] It is easy to understand that the various components of the present application as described and shown in the drawings herein can be arranged and designed in a variety of different configurations. Therefore, the detailed description of the embodiments is not intended to limit the scope of the application claimed, but is only a representative of the selected embodiments of the application.

[0204] Those skilled in the art will readily appreciate that the foregoing may be practiced with multiple steps in different orders, and / or with hardware components having configurations different from those disclosed. Thus, although the present application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative configurations will be apparent.

[0205] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative and that the scope of the present application is limited solely by the appended claims when considering its various equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A method comprising: receiving a charge request from a vehicle; determining, based on one or more preferences associated with the vehicle, a charging location used by other vehicles having the same preferences; as well as The vehicle is routed to the charging location based on the determination.

2. The method of claim 1 , wherein receiving a charge request comprises: determining that a battery charge of the vehicle is below a threshold; as well as The one or more preferences and the battery level are included in the request.

3. The method of claim 1, wherein the routing is based on the vehicle and the other vehicles being in proximity to each other.

4. The method of claim 1 , wherein routing the vehicle to the charging location based on the determination comprises: determining a route from a current location of the vehicle to the charging location; as well as The route is communicated to the vehicle.

5. The method according to claim 1, comprising: comparing one or more preferences associated with the vehicle to one or more historical preferences associated with the vehicle; partially modifying the one or more preferences in accordance with the one or more historical preferences; as well as A charging location from among the one or more charging locations is selected based on the modified one or more preferences.

6. The method according to claim 1, comprising: determining an area proximate to the vehicle having a high charging demand; as well as The preferences are altered based on characteristics of the region.

7. The method according to claim 1, comprising: determining that the vehicle is routed to a charging location different from the charging location; determining a change in vehicle charging preference based on the different charging locations; as well as Stores changed vehicle charging preferences.

8. A system comprising: processor; and a memory coupled to the processor, the memory comprising instructions that, when executed by the processor, are configured to: receiving a charge request from a vehicle; determining, based on one or more preferences associated with the vehicle, a charging location used by other vehicles having the same preferences; as well as The vehicle is routed to the charging location based on the processor determining the charging location.

9. The system of claim 8, wherein the processor receiving the charge request comprises the instructions being configured to: determining that a battery charge of the vehicle is below a threshold; and The one or more preferences and the battery level are included in the request.

10. The system of claim 8, wherein the processor routes the vehicle based on the vehicle and the other vehicle being in proximity to each other.

11. The system of claim 8, wherein the processor routing the vehicle comprises the instructions being configured to: determining a route from the vehicle's current location to the charging location; and The route is communicated to the vehicle.

12. The system of claim 8, wherein the instructions are configured to: comparing one or more preferences associated with the vehicle to one or more historical preferences associated with the vehicle; partially modifying the one or more preferences in accordance with the one or more historical preferences; as well as A charging location from among the one or more charging locations is selected based on the modified one or more preferences.

13. The system of claim 8, wherein the instructions are configured to: determining an area proximate to the vehicle having a high charging demand; and The preferences are altered based on characteristics of the region.

14. The system of claim 8, wherein the instructions are configured to: determining that the vehicle is routed to a charging location different from the charging location; determining a change in vehicle charging preference based on the different charging locations; and Stores changed vehicle charging preferences.

15. A computer-readable storage medium comprising instructions that, when read by a processor, cause the processor to execute: receiving a charge request from a vehicle; determining, based on one or more preferences associated with the vehicle, charging locations used by other vehicles having the same preferences; and The vehicle is routed to the charging location based on the determination.

16. The computer-readable storage medium of claim 15, wherein receiving a charge request comprises: determining that a battery charge of the vehicle is below a threshold; as well as The one or more preferences and the battery level are included in the request.

17. The computer-readable storage medium of claim 15, wherein the routing is based on the vehicle and the other vehicles being in proximity to each other.

18. The computer-readable storage medium of claim 15, wherein routing the vehicle to the charging location comprises the instructions causing the processor to: determining a route from the vehicle's current location to the charging location; and The route is communicated to the vehicle.

19. The computer-readable storage medium of claim 15, wherein the instructions cause the processor to: comparing one or more preferences associated with the vehicle to one or more historical preferences associated with the vehicle; partially modifying the one or more preferences in accordance with the one or more historical preferences; as well as A charging location from among the one or more charging locations is selected based on the modified one or more preferences.

20. The computer-readable storage medium of claim 15, wherein the instructions cause the processor to: determining an area proximate to the vehicle having a high charging demand; and The preferences are altered based on characteristics of the region.

Images