Routing electric vehicles to alternative charging stations

Abstract

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

Description

[Background technology]

[0001] Vehicles or modes of transportation, such as automobiles, motorcycles, trucks, airplanes, trains, etc., typically provide transportation needs for passengers or cargo in a variety of ways. Transportation-related functions may be identified and utilized by a variety of computing devices, such as smartphones and computers located on or off the vehicle. Summary of the Invention [Means for solving the problem]

[0002] One embodiment provides a method that includes one or more of receiving a request for charging from a vehicle; determining, based on one or more preferences associated with the vehicle, charging locations used by other vehicles with the same preferences; and routing the vehicle to the charging locations based on the determination.

[0003] Another embodiment provides a system including a memory communicatively coupled to a processor, the processor performing one or more of receiving a request for charging 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 routing the vehicle to the charging locations based on the charging locations determined by the processor.

[0004] A further exemplary 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 request for charging 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 routing the vehicle to the charging locations based on the determination. [Brief explanation of the drawings]

[0005] [Figure 1A]FIG. 1A illustrates an example diagram of routing an electric vehicle to an alternative charging station, according to an exemplary embodiment.

[0006] [Figure 1B] FIG. 1B shows a further exemplary diagram of routing an electric vehicle to an alternate charging station, according to an exemplary embodiment.

[0007] [Figure 2A] FIG. 2A illustrates a transport network diagram in accordance with an example embodiment.

[0008] [Figure 2B] FIG. 2B illustrates another transport network diagram according to an example embodiment.

[0009] [Figure 2C] FIG. 2C illustrates yet another transport network diagram in accordance with an example embodiment.

[0010] [Figure 2D] FIG. 2D illustrates a further transport network diagram in accordance with an example embodiment.

[0011] [Figure 2E] FIG. 2E illustrates yet another transport network diagram in accordance with an example embodiment.

[0012] [Figure 2F] FIG. 2F is a diagram illustrating energizing one or more elements according to an exemplary embodiment.

[0013] [Figure 2G] FIG. 2G is a diagram illustrating the interconnections between different elements according to an example embodiment.

[0014] [Figure 2H] FIG. 2H is a further diagram illustrating the interconnections between different elements, according to an example embodiment.

[0015] [Figure 2I] FIG. 2I is yet another diagram illustrating interconnections between elements in accordance with an exemplary embodiment.

[0016] [Figure 2J] FIG. 2J is yet another diagram illustrating a keyless entry system, according to an exemplary embodiment.

[0017] [Figure 2K] FIG. 2K is yet another diagram illustrating a CAN in a transport according to an example embodiment.

[0018] [Figure 2L] FIG. 2L is yet another diagram illustrating an end-to-end communication channel in accordance with an example embodiment.

[0019] [Figure 2M] FIG. 2M is yet another diagram illustrating an example of a transport for performing secure V2V communication using security certificates, according to an example embodiment.

[0020] [Figure 2N] FIG. 2N is a further diagram illustrating an example of a transport interacting with a security processor and a wireless device, according to an exemplary embodiment.

[0021] [Figure 3A] FIG. 3A illustrates a flow diagram according to an example embodiment.

[0022] [Figure 3B] FIG. 3B illustrates another flow diagram according to an example embodiment.

[0023] [Figure 3C] FIG. 3C illustrates yet another flow diagram in accordance with an example embodiment.

[0024] [Figure 4] FIG. 4 illustrates a machine learning transport network diagram in accordance with an example embodiment.

[0025] [Figure 5A] FIG. 5A illustrates an exemplary vehicle configuration for managing database transactions associated with a vehicle, according to an exemplary embodiment.

[0026] [Figure 5B] FIG. 5B illustrates an exemplary vehicle configuration for managing database transactions occurring between various vehicles, according to an exemplary embodiment.

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

[0028] [Figure 6B] FIG. 6B illustrates another blockchain configuration, according to an example embodiment.

[0029] [Figure 6C] FIG. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to an example embodiment.

[0030] [Figure 6D] FIG. 6D illustrates an exemplary data block according to an exemplary embodiment.

[0031] [Figure 7] FIG. 7 illustrates an example system that supports one or more of the example embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0032] It will be readily understood that the components of the present invention, as generally described and illustrated in the drawings herein, could be arranged and designed in a wide variety of configurations. Thus, the following detailed description of at least one embodiment of a method, apparatus, computer-readable storage medium, and system, as illustrated in the accompanying drawings, is not intended to limit the scope of the invention as claimed, but is merely representative of selected embodiments. The embodiments illustrated herein are not intended to limit the scope of the invention. The computer-readable storage medium may be a non-transitory computer-readable medium or a non-transitory computer-readable storage medium.

[0033] Communications between a transport and particular entities, such as remote servers, other transports, and local computing devices (e.g., smartphones, personal computers, transport-integrated computers, etc.), may be received, transmitted, and processed by one or more “components,” which may be hardware, firmware, software, or a combination thereof. A component may be part of any of these entities or computing devices, or of some other computing device. In one example, consensus decisions related to blockchain transactions may be performed by one or more computing devices or components associated with the transport (which may be any of the elements described and / or illustrated herein) and one or more components external to or remote from the transport.

[0034] The features, structures, or characteristics of the invention described herein may be combined in any suitable manner in one or more embodiments. For example, the term "exemplary embodiment," "some embodiments," or other similar terms used throughout this specification means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one example. Thus, the terms "exemplary embodiment," "some embodiments," "other embodiments," or other similar terms used throughout this specification do not necessarily refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the figures, connections between elements may enable one-way and / or two-way communication, even if the connections are indicated with one-way or two-way arrows. In current solutions, vehicles or transportation include one or more of: cars, trucks, pedestrian-area battery electric vehicles (BEVs), e-Palettes, fuel cell buses, motorcycles, scooters, bicycles, boats, recreational vehicles, airplanes, and any object that may be used to transport people or goods from one location to another.

[0035] Also, although the embodiments may use the term "message," other types of network data may also be used, such as packets, frames, datagrams, etc. Furthermore, although the exemplary embodiments may show particular types of messages and signaling, they are not limited to the particular types of messages and signaling.

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

[0037] In communications infrastructure, a distributed database is a distributed storage system that includes multiple nodes communicating with each other. A blockchain is an example of a distributed database that includes an append-only immutable data structure (i.e., a distributed ledger) that can maintain records among untrusted parties. The untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record unless consensus is reached among the distributed peers. For example, peers can execute a consensus protocol to validate blockchain storage entries, group the storage entries into blocks, and build a hash chain through the blocks. This process forms a ledger by ordering the storage entries as necessary to ensure consistency. In a public or permissionless blockchain, anyone can participate without having a specific identity. Public blockchains handle cryptocurrencies and can employ consensus methods based on various protocols, such as proof-of-work (PoW). Conversely, permissioned blockchain databases enable secure interactions between groups of entities that share a common goal but may not fully trust each other, such as businesses exchanging funds, goods, or information. The solution works in both permissioned and permissionless blockchain environments.

[0038] Smart contracts are trustworthy decentralized applications that leverage the tamper-proof properties of a shared or distributed ledger (sometimes in the form of a blockchain) and an underlying agreement among member nodes called an endorsement or endorsement policy. Blockchain entries are typically "endorsed" before being committed to the blockchain, and unendorsed entries are ignored. A typical endorsement policy allows the smart contract's executable code to specify who endorses an entry in the form of a set of peer nodes required for endorsement. When a client submits an entry to the peers specified in the endorsement policy, the entry is executed, which validates the entry. After validation, the entries enter an ordering phase, where a consensus protocol produces an ordered sequence of endorsed entries grouped into blocks.

[0039] Nodes are the communicating entities in a blockchain system. A "node" can perform a logical function, meaning multiple nodes of different types can run on the same physical server. Nodes are grouped into trust domains and associated with logical entities that control them in various ways. Nodes include various types, such as client nodes or sending client nodes, which send entry calls to endorsers (e.g., peers) and broadcast entry proposals to an ordering service (e.g., ordering node). Another type of node is a peer node, which can receive entries submitted by clients, commit entries, and maintain copies of the blockchain entry state and ledger. Peers can also play the role of endorser. An ordering service node or orderer is a node that performs communication services for all nodes and implements delivery guarantees, such as broadcasting to each peer node in the system when committing entries or changing the blockchain world state. The world state typically constitutes the initial blockchain entry, including control and setup information.

[0040] A ledger is an ordered, tamper-proof record of all state transitions of a blockchain. A state transition can occur through a smart contract executable code invocation (i.e., an entry) submitted by a participating party (e.g., client node, ordering node, endorser node, peer node, etc.). An entry can result in one or more operands, such as create, update, or delete, committing a set of key-value pairs of assets to the ledger. A ledger contains a blockchain (also called a chain), which stores immutable, ordered records in blocks. A ledger also contains a state database that maintains the current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel it is a member of.

[0041] A chain is an entry log structured as hash-linked blocks, where each block contains a sequence of N entries (N is 1 or greater). The block header contains the hash of the block's entries and the hash of the previous block header. In this way, all entries on the ledger can be sequenced and cryptographically linked. Therefore, ledger data cannot be tampered with without breaking the hash links. Because the hash of the most recently added blockchain block represents all previous entries on the chain, all peer nodes can be guaranteed a consistent and trustworthy state. Chains can be stored on peer node file systems (i.e., locally, on attached storage, in the cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0042] The current state of an immutable ledger represents the most recent values ​​for all keys contained in the chain's entry log. Because the current state represents the most recent key values ​​known to the channel, it is sometimes called the world state. Invocations of smart contract executables perform entries against the ledger's current state data. To make these smart contract executables' interactions efficient, the most recent values ​​of keys may be stored in a state database. Because the state database is merely an indexed view into the chain's entry log, it can be regenerated from the chain at any time. The state database may be automatically restored (or generated on demand) at peer node startup and before entries are accepted.

[0043] Blockchain differs from traditional databases in that it is a distributed, immutable, and secure storage rather than a centralized one. Nodes must share changes to records in storage. Properties unique to blockchain include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility.

[0044] Example embodiments provide services to a specific vehicle and / or a user profile applied to the vehicle. For example, the user may be the owner of the vehicle or the driver of a vehicle owned by another party. Vehicles may require service at regular intervals, and approval of the service need may be required before service is provided. The service center may also provide service to vehicles in a nearby area based on the vehicle's current route plan and the relative level of service requirement (e.g., urgent, severe, moderate, light, etc.). Vehicle needs are monitored by one or more vehicle and / or road sensors or cameras, which report sensory data to a central control computer device within and / or outside the vehicle. This data is forwarded to a management server for review and response. Sensors may be located within the vehicle, on the vehicle's exterior, on fixed objects distant from the vehicle, and on another vehicle in close proximity to the vehicle. Sensors may also be associated with the vehicle's speed, braking, acceleration, fuel level, service needs, gear shifting, steering, etc. The sensors described herein may be devices, such as wireless devices, installed within and / or near the vehicle. Sensor information may also be used to identify whether the vehicle is being operated safely and whether an occupant experiences an unexpected vehicle condition, such as while accessing and / or using the vehicle. Vehicle information collected before, during, and / or after the vehicle is operated may be identified and stored in transactions on a shared / distributed ledger, which may be generated and committed to an immutable ledger determined by a permissioning consortium and thus stored in a "decentralized" manner, such as via blockchain membership groups.

[0045] Each party (owner, user, company, agency, etc.) may want to limit the disclosure of personal information, and therefore can utilize blockchain and its immutability to manage permissions for each user 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 collision and / or deterioration events, identify safety concern events, identify the parties involved in the event, and provide distribution to registered entities seeking access to such vehicle event data. Furthermore, results can be identified and necessary information can be shared among registered companies and / or individuals based on a consensus approach associated with the blockchain. Such an approach could not be implemented with traditional centralized databases.

[0046] The solution's various driving systems may utilize software, sensor arrays, machine learning capabilities, Light Detection and Ranging (LiDAR) projectors, radar, ultrasonic sensors, etc. to create maps of the terrain and roads that the vehicle can use for navigation and other purposes. In some embodiments, the autonomous vehicle may also use GPS, maps, cameras, sensors, etc. instead of LiDAR.

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

[0048] The shared and received data may be stored in a database. A database keeps data in a single database (e.g., a database server), usually in one specific location. This location is often 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 usually be accessed from several different points. Because it is in a single location, a centralized database is easier to manage, maintain, and control, especially from a security perspective. Within a centralized database, storing all data in a single location means that a particular data set has only one primary record, thereby minimizing data redundancy. Blockchain can be used to store transportation-related data and transactions.

[0049] Any of the actions described herein can be performed by one or more processors (e.g., microprocessors, sensors, electronic control units (ECUs), head units), with or without memory. These processors can be performed with or without memory on-board the transport or off-board the transport (e.g., servers, computers, mobile / wireless devices). One or more processors can communicate with other memory and / or other processors on-board or off-board other transports to utilize data transmitted from and / or to the transport. One or more processors and other processors can transmit data, receive data, and utilize this data to perform one or more of the actions described or illustrated herein.

[0050] 1A illustrates an example of routing an electric vehicle to an alternate charging station according to an example embodiment. The system 100 includes one or more vehicles 104, 108, a server 120, and an entity processor 130. The vehicles 104, 108 may include automobiles, trucks, recreational vehicles, construction vehicles, motorcycles, mopeds, electric bicycles, trains, aircraft, etc. In one embodiment, any of the vehicles 104, 108 described herein are at least partially powered by electric energy (i.e., hybrid electric vehicles (PHEVs) or electric vehicles (EVs), etc.).

[0051] Server 120 may include one or more processors and memory devices for storing applications and data. In one embodiment, server 120 may be associated with a vehicle manufacturer, a city, a government agency, a company or group of companies, an organization, etc. In one embodiment, server 120 may be located in a network or cloud, may be part of vehicle 104 or other vehicles 108, and / or may be located in or connected to one or more vehicle charging stations. In one embodiment, server 120 may represent any number of computing devices that may determine results and share data and determined results. Server 120 may communicate with one or more vehicles 104, 108 to obtain various information regarding installed, enabled, or inactive vehicle features and associated software, as discussed herein.

[0052] The entity processor 130 may include one or more processors and memory devices for storing applications and data. In one embodiment, the entity processor 130 may be associated with a device associated with the vehicle 104 or another vehicle 108, or one or more vehicle owners, vehicle drivers, vehicle occupants, homeowners, business owners, government agencies, etc. The entity processor 130 may be a device integrated into the vehicle 104 or another vehicle 108 and / or may be used within and removed from the vehicle 104, such as a mobile device. The entity processor 130 may be associated with various forms of vehicle displays, smartphones, smartwatches, tablets, wearable computers, laptops, etc. In one embodiment, the device associated with the entity processor 130 may include device applications that are either intrinsically resident on the device or downloaded / installed from a website that can manage the installation and activation of software related to the functionality of the vehicle 104 or vehicle 108.

[0053] In one embodiment, the system 100 may manage recommendations for charging stations associated with the vehicle 104 or other vehicles 108. For example, the vehicle 104 and other vehicles 108 may send and receive various information to and from the server 120 to assist in recommending charging locations. In one embodiment, the transmitted information may include one or more parameters called preferences. Each user associated with the vehicle 104 and / or other vehicles 108 may prioritize their preferences differently based on what is most important to them. The priorities may include at least one or more of proximity (i.e., travel time or distance to the charging location), amenities (features associated with or near the charging location, e.g., clean restrooms, fast food restaurants, shopping, etc.), cost of charging the vehicle 104 or other vehicles 108 (i.e., cost of electrical energy based on the type of electrical energy source and / or time of day), availability (i.e., current queue size, number of charging stations at the location, etc.), and charging speed (e.g., level 2 or level 3 charging capability compared to level 1 capability). In one embodiment, the server 120 may assign a fixed numerical value to each priority. For example, the server 120 may assign proximity=1, amenities=2, cost of charging the vehicle 104 or other vehicles 108=3, availability=4, and charging speed=5.

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

[0055] In one embodiment, the server 120 may send a preference request 116 to an entity processor 130 associated with the vehicle 104 or to a user / entity (e.g., driver or owner) associated with the vehicle 104. In one embodiment, the preference request 116 includes specific preferences requested, such as proximity=1, amenities=2, cost of charging the vehicle 104 or other vehicles 108=3, availability=4, and charging speed=5. Other preferences that may be available include the manufacturer of the charging equipment (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 already knows certain preferences and allows an entity associated with the entity processor 130 to prioritize the preferences according to its current needs. After the entity prioritizes its preferences, the entity processor 130 may transmit the prioritized preferences to the server 120 as its current preferences 124. For example, given 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). This may be the case if the entity is in a rush to do some shopping but is not particularly concerned about charging costs. In one embodiment, the entity processor 130 may include prioritized preferences in an entity profile that is stored in a memory device accessible to the entity processor 130 and / or transferred to the server 120 or vehicle processor 160.

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

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

[0059] In another embodiment, the same preference may refer to a match between sub-preferences. For example, amenities may include sub-preferences at a charging location, such as availability of restrooms, availability of food, and checking / replenishing tire pressure. An entity may assign the following priorities to the sub-preferences: 1 = check / replenish tire pressure, 2 = availability of restrooms, 3 = availability of food. The same preference may include a match between one or more sub-preferences, for example, an entity associated with a vehicle 104 and an entity associated with another vehicle 108 may specify availability of restrooms as the highest priority.

[0060] In response to determining that the other vehicle 108 has the same preferences as the vehicle 104, the server 120 may identify the location of the other vehicle 108. In one embodiment, the server 120 sends 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 other vehicle's 108's route to the destination. The server 120 may also query the other vehicle 108 for charging locations it is using. For example, the server 120 sends the other vehicle 108 a request for the most recent charging location. The request includes the time the charging location was used and the distance and / or time from the other vehicle's 108's current location. The other vehicle 108 responds with the charging location, time, and / or distance, etc. In one embodiment, the server 120 directs the vehicle 104 to the charging location based on the time, distance, and / or proximity of the vehicle 104. For example, vehicle 104 may be traveling along a route that passes within a distance threshold (e.g., 5 miles) of a charging station being used by another vehicle 108. In one embodiment, as long as vehicle 104 is within proximity (however defined) of the other vehicle 108, server 120 directs vehicle 104 to the charging location of the other vehicle 108.

[0061] FIG. 1B shows an exemplary diagram of routing an electric vehicle to an alternative charging station, according to an exemplary embodiment. System 150 may include one or more vehicle processors 160, server 120, and entity processor 130. Server 120 and entity processor 130 were previously described with respect to FIG. 1A. Vehicle 104 and other vehicles 108 may include vehicle processor 160 in communication with server 120 and entity processor 130. Vehicle processor 160 is associated with vehicle 104 and / or other vehicles 108 and may include a navigation processor, a communications processor, a head unit processor, an ECU processor, a sensor processor, etc. Vehicle processor 160, server 120, and entity processor 130 may communicate via wired and / or wireless communication media. For example, when vehicle 104 and / or other vehicles 108 are receiving charging at a charging location, vehicle 104 is connected to the charging station via an appropriate charging cable, and the charging station is communicatively connected to server 120 via a wireless connection, such as a Wi-Fi or BLUETOOTH connection. The charging cable may include an electrical path(s) for transferring electrical charge and one or more wired communication paths (e.g., USB, Ethernet, etc.) for providing bidirectional communication with the vehicle processor 160. As another example, the vehicle 104 and / or other vehicles 108 may not be connected to a charging station, such as while traveling, and may communicate wirelessly with the server 120 via Wi-Fi, BLUETOOTH, other wireless communication interfaces, etc.

[0062] In one embodiment, vehicle processor 160 determines (154) that vehicle 104 needs to be charged. For example, vehicle processor 160 receives notification from vehicle 104's battery and charging processor that charging is needed. The battery and charging processor continuously or periodically measures the vehicle's battery and charge level and compares it to a threshold value stored in an accessible memory device. If the battery level falls below the threshold value (e.g., 10%), the battery and charging processor notifies vehicle processor 160 that the vehicle needs to be charged. In response, vehicle processor 160 sends a charging request 112 to server 120.

[0063] In another embodiment, the entity processor 130 can determine that the vehicle 104 needs to be charged. For example, the vehicle processor 160 can receive a notification from the charging processor of the vehicle 104 that the current charge level is below a threshold. The vehicle processor 160 can send a request to the entity processor 130 of the entity device to charge the vehicle. In one embodiment, the entity processor 130 can display 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 and / or remaining driving range of the vehicle 104. The entity can provide a response to the request to initiate a search for a charging location. In one embodiment, the response is sent back to the vehicle processor 160, which generates a charging request 112 to the server 120. In another embodiment, the response can be sent to the server 120 as the charging request 112.

[0064] In response to receiving the charging request 112, the server 120 may forward a request preference notification 116 to the entity processor 130. The entity processor 130 receives the notification 116 and presents the preferences to the entity 162 associated with the entity processor 130 on a display and / or audibly on the entity device (i.e., a head unit of the vehicle 104, a smartphone, a smartwatch, etc.). The presentation may request the entity to prioritize the preferences 166. For example, priority "1" may be the most important preference for the entity, "2" the second most important preference, etc. The entity may prioritize the preferences 166 upon request and confirm the priority selection. 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, server 120 may determine common preferences 170 with one or more other vehicles 108, as described herein. In one embodiment, the common priorities may include priorities that are similar to or match one or more other vehicle priorities 128 received from the other vehicles 108. For example, vehicle 104 and the other vehicles 108 may share a common priority of highest priority, such as charging speed or charger availability.

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

[0067] In one embodiment, server 120 may identify multiple other vehicles 108 that have preferences 170 in common with vehicle 104. Because vehicle 104 can only be directed to a single charging location, server 120 may identify a single other vehicle 108 or a group of other vehicles 108 that have common charging locations. In one embodiment, server 120 may narrow the identified charging locations 178 by other means. For example, server 120 may identify charging locations based on the other vehicles 108 having more priority matches than the other vehicles 108, the other vehicles 108 having more high-priority preference matches in common than the other vehicles 108, or the other vehicles 108 having a closer distance, destination, or route to vehicle 104 than the other vehicles 108.

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

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

[0070] In one embodiment, if vehicle processor 160 determines 154 that charging is needed, vehicle processor 160 may determine the charge level of vehicle 104 as described herein. Charging request 112 includes the vehicle's current charge level and / or the vehicle's distance traveled compared to its current location. Server 120 may use vehicle 104's current charge level and / or current distance traveled to approve or disqualify one or more charging locations, even if the priority matches that of one or more other vehicles 108. For example, it would not make sense to route vehicle 104 to charging location 182 according to priority if vehicle 104 cannot reach the identified charging location.

[0071] In one embodiment, routing may be based on the proximity of vehicle 104 and other vehicles 108 to one another. Proximity means within a certain distance or travel time of one another. In one embodiment, the proximity of vehicle 104 and other vehicles 108 may indicate that vehicle 104 may have sufficient remaining charge to reach a particular charging station 178. In one embodiment, proximity does 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 travel time of a particular charging location 178.

[0072] In one embodiment, routing vehicle 104 to a charging location may be based on determining a route from vehicle 104's current location to the charging location and forwarding the route to vehicle 104. In one embodiment, vehicle processor 160 may forward one or more of the current route and / or current destination to server 120, either separately from or as part of charging request 112. Server 120 may 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 vehicle processor 160. In one embodiment, server 120 may route vehicle 104 to a charging location that minimizes the difference (i.e., distance and / or time) between the vehicle's 104 received route / destination and the identified route / destination to the charging location. In another embodiment, server 120 may direct vehicle 104 to a charging location that has been used by other vehicles 108 within a recent period of time. For example, server 120 may determine that 18 other vehicles were directed to a charging location in the previous day. If that number (18) is greater than a threshold value (e.g., 10) stored in an accessible memory device, the server 120 may direct the vehicle to a charging location 182 that has been used by 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 past preferences associated with the vehicle 104, partially modify the one or more preferences based on the one or more past preferences, and select a charging location from one or more charging locations based on the modified one or more preferences. The server 120 may receive the current preferences 124 multiple times throughout the life of the vehicle 104, each time the vehicle processor 160 determines (154) that charging is necessary. The server 120 may store the received current preferences 124 in an accessible memory device and, in one embodiment, may average the received current preferences 124 or determine a mean or other statistical combination of the received current preferences 124. In one embodiment, the server 120 may only maintain the received current preferences 124 or statistical combination for a limited period of time. Entities may change preference priorities over time, and older priority preferences may not be relevant. For example, a business may prioritize current convenience (e.g., waiting time) over the cost of electric energy a year ago.

[0074] In one embodiment, server 120 may modify current preferences 124 according to the historical preferences. Modifying refers to changing the priority of one or more preferences to match the priority of the historical preferences. For example, current preferences 124 may indicate a proximity priority of 1, while historical preferences may indicate a proximity priority of 5. In one embodiment, server 120 may average the proximity priorities to a priority of 3. In another example, server 120 may lower the proximity priority of current preferences 124 to a priority of 2. In this manner, server 120 transitions current preferences 124 to match the historical preferences. In one embodiment, modifying one or more preferences may include changing the priority of one or more other preferences in current preferences 124 so that the two preferences do not have the same priority. Finally, server 120 may select a charging location based on the modified preferences and transmit the charging location 132 to vehicle processor 160. Finally, server 120 may select a charging location based on the modified preferences and transmit the charging location 132 to vehicle processor 160.

[0075] In one embodiment, server 120 can identify areas near a vehicle with high charging demand and change the priority based on the characteristics of the area. In one embodiment, the area characteristics can include one or more parameters similar to the priorities (e.g., cost, power transfer rate) or different parameters (e.g., crime, congestion). For example, in a congested area, a user may want to avoid long wait times for a charging location, or may want to find a charging location that is well-lit, patrolled by security guards, behind a chain-link fence, or some other form of local security. In one embodiment, server 120 can add one or more parameters to one or more priorities and search for more suitable locations within the area based on the added parameters. In one embodiment, server 120 first searches for charging locations that meet the characteristics of the area (e.g., low crime rate, low population density, etc.). Server 120 can apply the one or more prioritized priorities to charging locations that meet the characteristics of the area. In one embodiment, server 120 first searches for one or more prioritized preferences, and then searches for charging locations that meet the characteristics of the area.

[0076] In one embodiment, server 120 may determine that vehicle 104 was routed to a charging location different from identified charging location 178, determine a change in charging priority for vehicle 104 based on the different charging location, and store the changed vehicle charging priority in an accessible memory device. In one embodiment, vehicle processor 160 may forward to server 120 the IDs and locations of charging locations used by vehicle 104 when vehicle 104 arrives at the charging location or while charging. Server 120 may receive the IDs and locations of charging stations used and add them to the history of charging locations used by vehicle 104. Server 120 may also determine that vehicle 104 used a charging location different from recommended charging location 132.

[0077] In one embodiment, the system constantly monitors charging preferences and actions that change historical preferences. Missing a recommended charging location can change historical preferences. For example, if a driver is directed to a non-recommended charging location with the shortest charging time in the area, the driver may place a higher priority on shortening charging time. A new charging location may also reflect a change in charging preference priorities. The server 120 can assign charging preferences to the new charging location and save the modified vehicle charging preferences to a storage device. In one embodiment, the server 120 can modify the historical preferences of the vehicle 104 by adding the new charging location to the historical preferences or by including the new charging location in statistical calculations, such as averages.

[0078] Each flow diagram shown herein (e.g., FIGS. 1A, 1B, 2C, 2D, 2E, 3A, 3B, 3C) is a separate example, which may represent the same or different embodiments. Operations within one flow diagram may be employed or shared by other flow diagrams. These example operations are not intended to limit the subject matter of any embodiment or corresponding claims.

[0079] It is important to note that all flow diagrams and corresponding processes derived from Figures 1A, 1B, 2C, 2D, 2E, 3A, 3B, and 3C may be part of the same process or may share subprocesses with one another. This allows these diagrams to be combined into a single preferred embodiment that does not require a particular operation and performs a particular operation from one exemplary process and one or more additional processes. All exemplary processes relate to the same physical system and can be used individually or interchangeably.

[0080] FIG. 2A illustrates a transport network diagram 200 according to an exemplary embodiment. The network comprises elements including a transport 202 including a processor 204 and a transport 202′ including a processor 204′. The transports 202, 202′ communicate with each other via the processors 204, 204′, as well as transceivers, transmitters, receivers, storage, sensors, and other elements (not shown) capable of providing communication. Communication between the transports 202 and 202′ can occur directly, via private and / or public networks (not shown), or via other transports and elements including one or more of a processor, memory, and software. While shown as a single transport and processor, multiple transports and processors may be present. One or more of the applications, functions, steps, solutions, etc. described and / or illustrated herein may be utilized and / or provided by these elements.

[0081] FIG. 2B illustrates another transport network diagram 210 according to an example embodiment. The network includes elements including a transport 202 including a processor 204 and a transport 202′ including a processor 204′. The transports 202, 202′ communicate with each other via the processors 204, 204′, as well as transceivers, transmitters, receivers, storage, sensors, and other elements (not shown) capable of providing communication. Communication between the transports 202, 202′ can occur directly, via private and / or public networks (not shown), or via other transports and elements including one or more of a processor, memory, and software. The processors 204, 204′ can further communicate with one or more elements 230 including a sensor 212, a wired device 214, a wireless device 216, a database 218, a mobile phone 220, a transport 222, a computer 224, an I / O device 226, and a voice application 228. The processor 204, 204' may be in communication with further elements including one or more of a processor, memory, and software.

[0082] Although each transport, processor, and element is shown separately, multiple elements may be present. Information or communication occurs between processors 204, 204', and any of elements 230. For example, mobile phone 220 provides information to processor 204, which causes transport 202 to perform an action. It also provides information or additional information to processor 204', which causes transport 202 to perform an action. It also provides information or additional information to mobile phone 220, transport 222, and / or computer 224. One or more of the applications, functions, steps, solutions, etc. described and / or illustrated herein may be utilized and / or provided by elements of the present invention.

[0083] 2C illustrates yet another transport network diagram 240 according to an example embodiment. The network comprises elements including a transport 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 element 230 (shown in FIG. 2B). The transport 202 may be a transport, a server, or any device with a processor and memory.

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

[0085] 2D illustrates a further transport network diagram 250 according to an example embodiment. The network comprises elements including a transport 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 element 230 (shown in FIG. 2B). The transport 202 may be a transport, a server, or any device with a processor and memory.

[0086] Processor 204 performs one or more of the following: determining that the vehicle's battery level is below a threshold and including one or more preferences and the battery level in the request 244D; routing based on the proximity of the vehicle and other vehicles to each other 245D; determining a route from the vehicle's current location to a charging location and forwarding the route to the vehicle 246D; comparing one or more preferences associated with the vehicle with one or more historical preferences associated with the vehicle 247D; partially modifying the one or more preferences according to the one or more historical preferences 248D; selecting a charging location from one or more charging locations based on the modified one or more preferences 247D; identifying an area of ​​high charging demand near the vehicle and modifying preferences based on characteristics of the area 248D;

[0087] 2E illustrates yet another transport network diagram 260 according to an example embodiment. Referring to FIG. 2E, network diagram 260 includes a transport 202 connected to other transports 202′ and an update server node 203 via a blockchain network 206. Transports 202 and 202′ may represent transports / vehicles. Blockchain network 206 may include a ledger 208 that stores software update verification data and a source 207 of verification data for future use (e.g., for audits).

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

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

[0090] The processor and / or computer-readable medium 242E may be located, in whole or in part, inside or outside the transport. The steps or functions stored on the computer-readable medium 242E may be performed, in whole or in part, by any processor and / or element, in any order. Furthermore, one or more steps or functions may be added, omitted, combined, performed later, etc.

[0091] FIG. 2F is a diagram 265 illustrating the electrification of one or more elements. In one example, a vehicle 266 can provide power stored in its batteries to one or more elements, including other vehicles 268, charging stations 270, and a power grid 272. The power grid 272 is connected to one or more charging stations 270, which can be connected 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 vehicles 268 via, for example, vehicle-to-vehicle (V2V) technology, cellular communications, WiFi, etc. The transport 266 can also interact wirelessly and / or wired with the other transports 268, charging stations 270, and / or power grid 272. In one example, the transport 266 is safely and efficiently routed (or routes itself) to the power grid 272, charging stations 270, or other transports 268. Using one or more embodiments of the present solution, the transport 266 can provide energy to one or more elements described herein in various advantageous ways, as described and / or illustrated herein, and can improve the safety and efficiency of the transport and positively impact the environment, as described and / or illustrated 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. Energy may be referred to in conjunction with the voltage and / or current supply provided by an entity to a vehicle during charging / use operations. Energy may be in the form of fossil fuels (e.g., when used in hybrid vehicles) or alternative power sources, including, but not limited to, lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, fusion-based energy sources, and energy generated on-the-fly during energy sharing and / or use operations to increase or decrease the energy levels of one or more vehicles at a particular time.

[0093] In one example, charging station 270 manages the amount of energy transferred from vehicle 266 so that vehicle 266 has enough charge remaining to reach its destination. In one example, a wireless connection is used to wirelessly direct the amount of energy transferred between vehicles 268, even if both vehicles are in motion. In one embodiment, wireless charging may occur via a stationary charger and the vehicle's battery (e.g., a charging mat in a garage or parking space) located in line with one another. In one example, an idle vehicle, such as vehicle 266 (which may be autonomous), provides a certain amount of energy to charging station 270 and is directed to return to its origin (e.g., to its original location or another 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, factors such as distance, time, traffic conditions, road conditions, environmental / weather conditions, the condition of the vehicle (e.g., weight), the schedule of the occupants using the vehicle, and the schedule of the occupants waiting for the vehicle determine the amount of energy to transfer to charging station 270. In one example, vehicle 268, charging station 270, and / or power grid 272 can provide energy to vehicle 266.

[0094] In one embodiment, a location, such as a building, residence, etc. (not shown) is communicatively connected to one or more of an electrical grid 272, a vehicle 266, and / or a charging station 270. The flow of electricity to one or more of the location, vehicle 266, and other vehicles 268 is modified in response to external conditions, such as weather. For example, extremely high or low outside temperatures increase the likelihood of a power outage, so slowing the flow of electricity to the connected vehicles 266 / 268 minimizes the likelihood of a power outage.

[0095] In one example, the solutions described and illustrated herein determine load impacts on a vehicle and / or system, provide energy to the vehicle and / or system based on future needs and / or priorities, and provide intelligence between a device including a module and a vehicle, allowing a processor in the device to wirelessly communicate with the vehicle regarding the amount of energy stored in the vehicle's battery. In one example, these solutions can also be used to provide charging from a vehicle to a location based on factors such as the temperature, energy costs, and power levels of the location. In one example, these solutions can also be used to manage the amount of energy remaining in a vehicle after a portion of the charge has been transferred to a charging station. In one example, these solutions can also be used to notify the vehicle to provide an amount of energy from the vehicle's battery. The amount of energy to transfer is based on the distance from the vehicle to the module receiving the energy.

[0096] In one example, the solution can be used to use a mobile energy storage unit that travels along a predetermined route to a vehicle with excess energy and stores the stored energy on the power grid. In one example, the solution can be used to determine the priority of a vehicle's need to supply energy to the power grid and the vehicle's current needs (e.g., passenger, next passenger, current cargo, next cargo priority, etc.). In one example, the solution can be used to determine when a vehicle is idle and travel to a location where it will release excess energy to the energy grid and then return to its original location. In one example, the solution can be used to determine the amount of energy a vehicle needs to supply other vehicles with energy through vehicle-to-vehicle energy transfers based on one or more conditions, such as weather, traffic conditions, road conditions, vehicle status, and the passengers and / or cargo of the other vehicles, and to instruct the vehicle to route to the other vehicles and provide energy. In one example, the solution can be used to transfer energy from one vehicle to another while in motion. In one example, the solution can be used to recover energy from a vehicle based on the energy consumed by the vehicle to reach a meeting point with another vehicle, the energy consumed to provide service, and the estimated energy consumed to return to its original location. In one example, the solution can be used to provide the remaining distance to a charging station and determine the amount of energy the charging station will recover from the vehicle, where the remaining charge is based on the remaining distance. In one example, the solution can be used to manage a vehicle being charged simultaneously from multiple locations, such as both a charging station via a wired connection and another vehicle via a wireless connection. In one example, the solution can be used to apply priorities to energy delivery to a vehicle, where priority is given to vehicles that provide a portion of their stored charge to other entities, such as the power grid, homes, etc.

[0097] In one embodiment, transports 266 and 268 can be utilized as bidirectional transports. Bidirectional transports can function as mobile microgrids, assisting in the supply of power to grid 272 and / or reducing power consumption when the grid is under stress. Bidirectional transports incorporate bidirectional charging, meaning that the transports can not only receive charge but also extract energy from the transport and “push” that energy to grid 272. This is also referred to as “V2G.” With bidirectional charging, electricity flows in both directions, to and from the transport. When the transport is charged, alternating current (AC) power from grid 272 is converted to direct current (DC). This is performed by one or more converters on the transport itself or by a converter on charger 270. Energy stored in the transport's battery is sent back to the grid in the opposite direction. Energy is converted from DC to AC via a converter (also referred to as a bidirectional charger), typically built into charger 270. Furthermore, the solution described and illustrated in FIG. 2F is applicable not only to the present system but also to other networks and systems.

[0098] FIG. 2G illustrates the interconnections between different elements 275. The solution may be stored and / or executed, in whole or in part, on and / or by one or more computing devices 278′, 279′, 281′, 282′, 283′, 284′, 276′, 285′, 287′, and 277′ associated with various entities. All of these computing devices are communicatively connected to and in communication with a network 286. A database 287 is communicatively connected to the network and enables data storage and retrieval. In one example, the database is an immutable ledger. One or more of the various entities may be a transportation agency 276, one or more service providers 279, one or more public buildings 281, one or more transportation infrastructure 282, one or more residences 283, a power grid / charging station 284, a microphone 285, and / or another transportation agency 277. Other entities and / or devices, such as one or more individual users using a smartphone 278, a laptop 280, an augmented reality (AR) device, a virtual reality (VR) device, and / or any wearable device, may also interoperate with the solution of the present invention. The smartphone 278, the laptop 280, the microphone 285, and other devices may be connected to one or more of the connected computing devices 278′, 279′, 281′, 282′, 283′, 284′, 276′, 285′, 287′, and 277′. The one or more public facilities 281 may include various institutions. The one or more public facilities 281 may utilize computing devices 281′. The one or more service providers 279 may include a dealership, a towing service, a collision center, or other repair shop. The one or more service providers 279 may utilize computing devices 279′. These various computing devices may be directly and / or communicatively connected to each other via a wired network, a wireless network, a blockchain network, etc. The microphone 285 may be utilized as a virtual assistant in one example.In one example, the one or more traffic infrastructures 282 include one or more traffic signals, one or more cameras, one or more sensors such as vehicle speed sensors, traffic volume sensors, and / or other traffic infrastructure. The one or more traffic infrastructures 282 may utilize a computing device 282'.

[0099] In one embodiment, when an electricity price is provided to or received from a charging station and / or a power grid, the enabling entity is one or more of a vehicle, a charging station, a server, and a network communicatively connected to the vehicle, the charging station, and the power grid.

[0100] In one example, vehicles 277 / 276 can transport people, objects, permanently or temporarily fixed equipment, etc. In one example, vehicles 277 can communicate with vehicles 276 via V2V communications via a computer associated with each vehicle 276′ and 277′ and may be referred to as vehicles, cars, vehicles, automobiles, etc. Vehicles 276 / 277 may be self-propelled wheeled vehicles, such as cars, sport utility vehicles, trucks, buses, vans, or other motor-powered, battery-powered, or fuel-cell-powered vehicles. For example, vehicles 276 / 277 may be electric vehicles, hybrid vehicles, hydrogen fuel cell vehicles, plug-in hybrid vehicles, or other types of vehicles equipped with a fuel cell stack, motor, and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, boats, and any other form of vehicle capable of transportation. Vehicles 276 / 277 may be semi-autonomous or autonomous. For example, vehicle 276 / 277 may operate and move autonomously without human interaction. An autonomous vehicle may include and use one or more sensors and / or navigation units to navigate autonomously.

[0101] In one example, the solutions described and illustrated herein can be used to determine access to a transport via blockchain consensus. In one example, these solutions can also be used to perform profile verification before allowing a passenger to use the transport. In one example, these solutions can also be used to prompt (visually, or in another example, verbally, etc.) on or from the transport as to the action the user needs to take (which may be pre-recorded) and verify that it is the correct action. In one example, these solutions can also be used to provide the functionality for the transport to segment data based on a risk level associated with the data and the driving environment, delivering a lower-risk portion of the segmented data to the passenger in a safe driving environment and delivering the remaining (higher-risk) portion of the segmented data to the passenger after the passenger exits the transport. In one example, solutions can also be used to handle vehicle movement across borders (e.g., countries, states, etc.) using blockchain and smart contracts and apply the rules of the new area to the vehicle.

[0102] In one example, the solution can be used to allow a vehicle to continue operating outside of a boundary if the vehicle agrees based on the vehicle's operating conditions and occupant characteristics. In one example, the solution can be used to analyze a vehicle's available data upload / download speed, file size, and vehicle travel speed / direction, determine the distance required to complete the data upload / download, and assign a safety zone boundary for performing the data upload / download. In one example, the solution can be used to safely execute a normally dangerous maneuver and instruct the subject vehicle and other nearby vehicles to safely exit the exit when the system determines an exit is approaching and the vehicle does not appear to be ready for the exit (e.g., traveling in the wrong lane or traveling at a speed inappropriate for passing through to the exit). In one example, the solution can be used to verify the diagnosis of other vehicles using one or more vehicles while both the vehicle and the other vehicles are in motion.

[0103] In one example, the solution can be used to detect lane usage at a location and time and instruct the transportation agency to notify the transportation agency's passengers or recommend a lane change or not. In one example, the solution can be used to eliminate the need for mailed information or for drivers / passengers to respond by mail or by making in-person payments. In one example, the solution can be used to provide services to transportation agency passengers, where the services provided are subscription-based and authorization is obtained from other transportation agencies connected to the passenger's profile. In one example, the solution can be used to record changes in the condition of rented items. In one example, the solution can be used to achieve blockchain consensus from other transportation agencies in proximity to a damaged transportation agency. In one example, the solution can be used to receive media potentially related to an accident from a server, such as an insurance company's server, via the transportation agency's computer. The server accesses one or more media files to determine the damage status of the transportation agency and stores the damage assessment on the blockchain. For example, these solutions can be used to achieve consensus on determining the severity of a transportation-related event based on information obtained from multiple devices over various time periods prior to the event.

[0104] In one example, these solutions can be used to solve the problem of a lack of video evidence in traffic accidents. The solution details procedures for a vehicle involved in an accident to query media related to the accident from other vehicles that may have been in the vicinity of the accident scene. In one example, these solutions can be used to record specific portions of damaged vehicles using vehicles and other devices (e.g., pedestrian cell phones, streetlight cameras, etc.).

[0105] In one example, the solution can be used to alert a vehicle occupant when the vehicle is heading toward a dangerous area and / or event, allowing the vehicle to notify the vehicle occupant or a central controller of potentially dangerous areas on or near the current route. In one example, the solution can be used to detect when a vehicle is traveling at a high speed, and at least one other vehicle is used to assist the vehicle in slowing down in a manner that minimizes traffic impact. In one example, the solution can be used to identify dangerous driving situations in which media is captured by a vehicle involved in the dangerous driving situation. A geofence is established based on the distance of the dangerous driving situation, and additional media is captured by at least one other vehicle within the established geofence. In one example, these solutions can also be used to notify one or more vehicle occupants that the vehicle is approaching a traffic control sign on a roadway. If the vehicle passes the sign, the vehicle receives indications of improper driving from other nearby vehicles. In one example, these solutions may also be utilized to render a vehicle partially inoperable (in certain embodiments) by limiting speed, restricting proximity to other vehicles, limiting top speed, and restricting certain distances allowed to be driven per certain period of time.

[0106] In one example, the solution can be used to overcome the need to rely on software updates to correct vehicle problems when a vehicle is not operating correctly. A server receives data from multiple other vehicles observing unsafe or erroneous operation of the vehicle by observing other vehicles on the route. Analysis of these observations can lead to notification of the vehicle if the data indicates unsafe or erroneous operation. In one example, the solution can also be used to notify between a vehicle and a potentially dangerous situation involving a person outside the vehicle. In one example, the solution can be used to transmit data from devices related to or near a vehicle incident to a server. Based on the severity of the incident or near-miss, the server notifies the sender of the data. In one example, the solution can be used to provide vehicle operation recommendations to a vehicle driver or passenger based on data analysis. In one example, these solutions can also be used to establish geofences associated with physical structures and determine payment liability to the vehicle. In one example, these solutions can also be used to coordinate vehicle drop-off at a location using both the current state of the location and proposed future states using navigation destinations of other vehicles. In a further example, these solutions can also be used to coordinate automated vehicle drop-off at locations, such as for transportation rental companies.

[0107] In one example, the solution can also be used to move a vehicle to a different location based on a user event. More specifically, the system tracks the user's device and relocates the vehicle to a location closer to the user upon the end of the original or revised event. In one example, the solution can also be used to enable verification of available locations within an area through existing vehicles in the area. The approximate time a location may become available is also determined based on verification from existing vehicles. In one example, the solution can also be used to move a vehicle to a closer parking space when an available parking space appears and the elapsed time since initial parking is less than the average event time. Furthermore, the solution can move the vehicle to a final parking space upon the end of an event or depending on the location of a device associated with at least one occupant of the vehicle. In one example, the solution can also be used to plan parking in preparation for upcoming congestion. The system can interact with transportation agencies to offer some services at lower than normal prices or direct transportation agencies to alternative parking locations based on transportation priorities, facilitating pre-arrival optimization of parking situations.

[0108] In one example, the solution can be used to determine pricing and availability for fractional ownership sales of transportation vehicles or ride-sharing applications. In one example, the solution can be used to provide accurate and timely reporting on dealer sales activity, far beyond what is currently available. In one example, the solution can be used to enable dealers to claim assets via the blockchain. Using the blockchain, agreement is reached before the asset is moved. Furthermore, the process can be automated, and payments can be initiated via the blockchain. In one example, the solution can be used to establish contracts with multiple entities (e.g., service centers). The contracts involve agreement and the execution of actions (e.g., diagnostics). In one example, the solution can be used to associate digital keys with multiple users. The first user is the transportation operator, and the second user is responsible for the transportation. These keys are authorized by a server that verifies the location of the service provider and the proximity of the keys. In one example, these solutions can be used to determine the services required at a transportation destination. One or more service locations within the area along the route to the destination and that can provide the service are identified. The transportation navigation is updated based on the identified service locations. A smart contract containing the reward for the service is identified and a blockchain transaction for that transaction is stored on the distributed ledger.

[0109] In one example, the solution can be used to link profiles of a service provider's transport and its occupants to determine services and products that may be of interest to the occupants. These services and products are determined by the occupants' history and / or preferences. The transport then receives offers from the service provider's transport and, in another example, meets with the transport to provide the service / product. In one example, the solution can be used to detect a transport within range and send a service offer (e.g., maintenance offer, product offer) to the transport. A contract is established between the system and the transport, and the system selects a service provider to provide the contract. In one example, the solution can be used to assign one or more transports as road managers. Road managers assist with traffic flow. Road managers can generate road signs (e.g., lights, displays, and sounds) to assist traffic flow. In one example, these solutions can be used to alert drivers to the presence of vehicles via devices installed near traffic lights and intersections. An alert is sent when an event occurs, such as when the vehicle at the top of the vehicle list is not moving when the light turns green.

[0110] FIG. 2H is another block diagram illustrating the interconnections between different elements in an example 290. A vehicle 276 is shown, including ECUs 295, 296, and a head unit (also referred to as an infotainment system) 297. An electronic control unit (ECU) is a system integrated into automotive electronics that controls one or more electrical systems or subsystems within the vehicle. ECUs include, but are not limited to, managing the vehicle's engine, braking system, gearbox system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECUs are connected to the transport's controller area network (CAN) bus 294. The ECUs can also communicate with a transport computer 298 via the CAN bus 294. The transport's processors / sensors (e.g., the transport computer) 298 can communicate with external elements, such as a server 293, via a network 292 (e.g., the Internet). Each ECU 295, 296, and head unit 297 can have its own security policy. The security policy defines the allowable processes that can run in the appropriate context. In one example, some or all of the security policy may be provided to the transport computer 298 .

[0111] ECUs 295, 296, and head unit 297 can each include custom security function elements 299 that define authorized processes and the contexts in which those processes are allowed to run. Context-based authorization, which determines the validity of process execution, allows ECUs to maintain secure operation and prevent unauthorized access from elements such as the transport's controller area network (CAN bus). If an ECU encounters an unauthorized process, it can block the process's operation. Automotive ECUs can use a variety of contexts to determine whether a process is operating within allowed boundaries, including proximity contexts such as nearby objects, the distance to approaching objects, speed, and trajectory relative to other moving objects; user-related contexts such as an indication of whether the transport is moving or parked, the transport's current speed, transmission status, devices connected to the transport via wireless protocols, infotainment usage, cruise control, parking assist, driving assist, location-based contexts, and other contexts.

[0112] In one example, the solutions described and illustrated herein can be used to partially disable a vehicle by (in certain embodiments) imposing speed limits, restrictions on access to other vehicles, maximum speed limits, and restrictions on distance traveled per time period. In one example, these solutions can also be used to facilitate the exchange of vehicle ownership using blockchain. In this case, data is sent from devices associated with or near an accident in the vehicle to a server. The server notifies the sender of the data based on the severity of the accident or the device near the accident. In one example, these solutions can also be used to assist a vehicle in avoiding an accident, such as if the vehicle is involved in an accident. The server can understand the nature of the accident from multiple perspectives by attempting to obtain data from other vehicles. In one example, these solutions can also be used to determine if a sound from a vehicle is abnormal and send data about the sound and potential sound source locations to a server, allowing the server to identify the cause and avoid potentially dangerous situations. In one example, these solutions can also be used to establish a location boundary through the system when a vehicle is involved in an accident. The boundary is based on the decibels associated with the accident. Multimedia content from devices within the perimeter is captured to further understand the circumstances of the accident. In one example, these solutions can also be used to associate vehicles with accidents and capture media captured by devices near the accident scene. The captured media is saved as media segments. The media segments are sent to another computing device that creates a sound profile of the accident, which can help understand more detailed information about the accident.

[0113] In one example, the solution may utilize sensors to record audio, video, motion, etc., to document areas where potential events occur. For example, when a vehicle comes into contact with, or may come into contact with, another vehicle (whether moving or parked), the system obtains data from sensors that may be present on one or more of the vehicle and / or fixed or moving objects. In one example, the solution may use sensor data to identify the new state of the vehicle during a vehicle event and determine whether the vehicle has been damaged by comparing that state to a vehicle condition profile. This allows for the safe and secure capture of critical data from vehicles about to be involved in a harmful event.

[0114] In one example, the solution can be used to alert a vehicle occupant if the vehicle determines via one or more sensors that it is approaching or traveling the wrong way onto a one-way road. The vehicle has sensors / cameras / maps that interact with the current solution's system. The system knows the geographic location of the one-way road. The system can provide an audio notification to the occupant, for example, "You are approaching a one-way road." In one example, the solution can be used to compensate vehicles, allowing autonomous vehicle owners to monetize the data collected and stored by vehicle sensors, creating an incentive for vehicle owners to share their data and provide additional data to entities that can help improve future vehicle performance and provide services to vehicle owners.

[0115] In one example, these solutions can also be used to increase or decrease vehicle functionality depending on the vehicle's operation over a period of time. In one example, these solutions can also be used to assign fractional ownership to a vehicle. Sensor data associated with one or more vehicles and devices proximate to the vehicle is used to determine the state of the vehicle. Fractional ownership of the vehicle is determined based on this state, and responsibility for the new vehicle is provided. In one example, these solutions can also be used to provide data to a replacement / upgrade part that attempts to disrupt the replacement / upgrade part's authorized functionality and, if the authorized functionality is not disrupted, authorizes the part to use the replacement / upgrade part's authorized functionality.

[0116] In one example, the solution can be used to provide individuals with the ability to ensure that a passenger is aboard the vehicle and that the passenger will arrive at a specific destination. Additionally, the system ensures that the driver (in the case of a non-autonomous vehicle) and / or other passengers are authorized to interact with the passenger. Pick-up, drop-off, and location are also recorded. All of the above is stored in an immutable format on the blockchain. In one example, the solution can be used to determine driver characteristics by analyzing driving style and other factors to address situations where the driver is not driving in a typical manner (e.g., the driver's past driving behavior in specific conditions, such as daytime, nighttime, rainy, or snowy weather). Additionally, vehicle attributes are also considered. Attributes include weather, whether headlights are on, whether navigation is in use, whether a HUD is in use, the volume of media being played, and so on. In one example, the solution can be used to notify passengers in a vehicle of dangerous situations when items in the vehicle may prevent the passenger from noticing the situation.

[0117] In one example, the solution can be used to mount a calibration device on a rig fixed to the vehicle, in which case various sensors on the vehicle can automatically self-calibrate based on what the calibration device should detect and what it actually detects. In one example, the solution can be used to use blockchain to seek consensus from multiple service centers when a vehicle requiring service submits fault information, thereby enabling remote diagnostic capabilities where data severity thresholds require agreement from other service centers. Once consensus is reached, the service center can transmit and store a fault security level on the blockchain. In one example, the solution can be used to determine differences between sensor data external to the vehicle and the vehicle's own sensor data. The vehicle then requests software from a server to correct the problem. In one example, the solution can be used to enable messaging to nearby or within the area of ​​an event (e.g., a collision).

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

[0119] The processor 296A includes an arithmetic logic unit, microprocessor, general-purpose controller, and / or similar processor array for performing computational operations and providing electronic display signals to the display unit 299A. The processor 296A processes data signals and can include various computing architectures, such as a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of multiple instruction sets. The transport 276 can include one or more processors 296A. Other processors, operating systems, sensors, displays, and physical configurations (not shown) communicatively connected to each other can also be used in the solution.

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

[0121] The memory 297A of the transport 276 stores one or more of the following data: navigation route data 295A and autonomous function data 294A. In some embodiments, the memory 297A stores data necessary for the navigation application 295A to provide functionality.

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

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

[0124] Sensor set 292A can include any sensor that generates sensor data within transport 276. For example, sensor set 292A can include short-range and long-range sensors. In some embodiments, sensor set 292A of transport 276 can include a camera, a lidar sensor, an ultrasonic sensor, an automobile engine sensor, a radar sensor, a laser altimeter, a manifold absolute pressure sensor, an infrared detector, a motion detector, a thermostat, an acoustic 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 timer, 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 oil temperature sensor, a turbine speed sensor (TSS), a variable reluctance sensor, a vehicle speed sensor (VSS), a water sensor, a wheel speed sensor, a GPS sensor, a mapping function, and any other type of automobile sensor. Navigation system 295A can store sensor data in memory 297A.

[0125] The communications unit 298A transmits and receives data to and from the network 292 or other communications channels. In some embodiments, the communications unit 298A may include a DSRC transceiver, a DSRC receiver, and other hardware or software necessary to make the transport 276 a DSRC-enabled device.

[0126] The transport 276 can communicate with other transports 277 via V2V technology. For example, V2V communication includes detecting radar information corresponding to the relative distance to an external object, receiving GPS information of the transport, setting an area where the other transport 277 is located based on the detected radar information, calculating the probability that the GPS information of the target vehicle is located in the set area, and identifying the transport 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 illustrated herein can be utilized to manage emergency scenarios and vehicle functionality when it is determined that the vehicle is entering an area without network access. In one example, these solutions can also be utilized to manage and provide functionality (e.g., audio, video, navigation) in a vehicle without network connectivity. In one example, these solutions can also be utilized to determine whether a profile of a person near the vehicle matches attributes of a profile of at least one occupant within the vehicle. A notification is sent from the vehicle to establish communication.

[0128] In one example, these solutions can be used to analyze the availability of voice-enabled crew members in each vehicle based on the vehicle's remaining time and communication status. In one example, these solutions can be used to determine two levels of threat from an obstacle on a roadway and determine whether the vehicle is moving forward along the roadway upon receiving a gesture indicating that the obstacle has not exceeded a threshold and reached an alert level. In one example, these solutions can be used to remove sensitive data from a vehicle if it is damaged and becomes unusable.

[0129] In one example, the solution can be used to verify that customer data targeted for deletion has indeed been deleted from all necessary locations within an enterprise, thereby demonstrating GDPR compliance. In one example, the solution can be used to enhance lower-level autonomous vehicle autonomy capabilities by providing rewards from one transport to another in exchange for data related to safety, important notifications, etc. In one example, the solution can be used to provide a transport with the ability to receive data based on a first biometric associated with the occupant. The transport then decrypts the encrypted data based on verification of a second biometric, where the second biometric is a continuum of the first biometric. The transport provides unencrypted data to the occupant when only the occupant can receive the decrypted data, deletes the sensitive portion of the unencrypted data when the sensitive portion is provided, and deletes the non-sensitive portion after a period associated with the biometric. In one example, the solution can be used to provide the ability to authenticate an individual based on the weight and grip pressure applied to the steering wheel of the vehicle. In another example, the solution can be used to provide a vehicle with functionality that already exists but is not currently enabled, thereby presenting vehicle occupants with a profile that reflects their unique characteristics.

[0130] In one example, these solutions may be utilized to modify a vehicle, particularly the interior and exterior of the vehicle, to reflect and assist at least one occupant. In another example, replicating a occupant's work environment and / or home environment is disclosed. The system may attempt to "recreate" a user's work / home environment while the user is aboard the vehicle if the system determines the user is in "work mode" or "home mode." All data regarding the interior and exterior of the vehicle, as well as the various occupants using the vehicle, is stored on a blockchain and executed via smart contracts. In one example, these solutions may be utilized to detect occupant gestures and assist in communication with nearby vehicles so the vehicle can maneuver accordingly. In one example, these solutions may be utilized to provide the vehicle with the ability to detect intended gestures using a gesture definition data store. In one example, these solutions may be utilized to enable a vehicle to perform various actions based on gait or user gestures. In another example, these solutions may be utilized to ensure that a vehicle driver performing various maneuvers (e.g., driving while talking on the phone with navigation on) does not exceed a dangerous number of gestures before being allowed.

[0131] In one example, the solution can also be used to assign a status to each occupant in a vehicle and validate gestures from the occupants based on the occupant's status. In one example, the solution can also be used to collect details of sounds associated with a collision (such as location, direction, ascending or descending, generating device, device type, manufacturer, owner, associated data such as number of simultaneous sounds, time of occurrence, etc.) and provide the data to a system that analyzes the data and helps determine details about the collision. In one example, the solution can also be used to determine whether a vehicle is unsafe to operate. A vehicle includes multiple components that interoperate to control the vehicle, each component associated with a separate component key. A cryptographic key is transmitted to the vehicle to reduce the vehicle's functionality. In response to receiving the cryptographic key, the vehicle disables one or more component keys. Disabling one or more component keys can result in one or more of the following: restricting the transport from traveling faster than a specified speed; restricting the transport from coming closer to another transport than a certain distance; and restricting the transport from traveling beyond a threshold distance.

[0132] In one example, the solution can also be used to provide instructions from one specific vehicle (trying to vacate a location) to another specific vehicle (trying to occupy a location), with blockchain used to perform authentication and coordination. In one example, the solution can also be used to determine shared ownership of a vehicle. For example, if multiple people own a single vehicle, the system uses vehicle usage (which may change over time) to update shared ownership. The application also includes other embodiments, including determining minimum ownership of a vehicle based on vehicle availability, vehicle driver decisions, etc., rather than vehicle usage.

[0133] In one example, the solution can be used to allow a transportation vehicle to allow users to share their subscriptions with a limited group, such as family or friends. For example, a user may want to share their membership, in which case the associated transaction is stored on a blockchain or traditional database. When subscribed materials are requested by a user who is not the primary subscriber, the blockchain node (i.e., the transportation vehicle) can verify that the person requesting the service is an authorized person with whom the subscriber shared their profile. In one example, the solution can be used to allow a person to use secondary transportation to reach their destination. When determining secondary transportation, functional relationship values ​​(e.g., values ​​indicating various parameters and their importance when determining what type of alternative transportation to use) are used. In one example, the solution can be used to allow a passenger involved in an accident to use other transportation to travel to their original destination.

[0134] In one example, the solution can be used to propagate software / firmware uploads to a first subset of transports. This first transport set tests the update, and if the test is successful, the update is propagated to additional transport sets. In one example, the solution can be used to propagate software / firmware updates from a master transport to vehicles, where the update is propagated from the first subset through the vehicle network and then to a larger subset. A portion of the update may be sent initially, and the remaining portion may be sent from the same vehicle or another vehicle. In one example, the solution can be used to provide transport computer updates to transports and transport operator / occupant devices. The update may be approved by all drivers and / or all occupants. The software update is provided to the vehicles and devices. The user does not need to do anything, they just approach the vehicle; the function is performed automatically. A notification is sent to the device indicating the software update is complete. In one example, these solutions can also be used to verify that an OTA software update was performed by a qualified technician, with one or more transport components generating a status regarding the origin of the verification code, the procedure for receiving the software update over the air, the information contained in the software update, and the verification result.

[0135] In one example, the solution can be used to provide a second component with the ability to analyze software updates deployed on a first component, then verify a first portion of critical updates and a second portion of non-critical updates, assign the verified first portion to one process within the transport, execute the verified first portion in one process for a set period of time, and if a positive result is obtained based on the set period of time, execute the verified first portion in another process after the set period of time. In one example, the solution can be used to provide a selection of services to a transport's passengers based on their profile and a shared profile shared with the passenger's profile. In one example, the solution can be used to store user profile data on a blockchain and intelligently present offers and recommendations to a user based on the user's purchase history and preferences retrieved from the user profile on the blockchain.

[0136] Properly securing a transport requires protection not only from unauthorized physical access but also from unauthorized remote access (e.g., cyber threats). To prevent unauthorized physical access, transports are equipped with secure access systems such as keyless entry. Security protocols are also added to transport computers and computer networks to facilitate secure remote communication between transports.

[0137] Electronic control units (ECUs) are nodes within a vehicle that control tasks from windshield wiper operation to anti-lock braking systems. ECUs are often connected to each other via the vehicle's central network, sometimes called a Controller Area Network (CAN). Cutting-edge features such as autonomous driving rely heavily on the implementation of new and complex ECUs, including advanced driver assistance systems (ADAS), sensors, and more. These new technologies are helping to improve vehicle safety and the driving experience, but they also increase the number of externally communicating units within the vehicle, making it more vulnerable to attack. Below are some examples of securing your vehicle from physical and remote intrusions:

[0138] FIG. 2J illustrates a keyless entry system 290B that prevents unauthorized physical access to a transport 291B according to an example embodiment. Referring to FIG. 2J, a key fob 292B, in one example, transmits commands to the transport 291B using radio frequency signals. In this example, the key fob 292B includes a transmitter 2921B with an antenna capable of transmitting short-range radio signals. The transport 291B includes a receiver 2911B with an antenna capable of receiving the short-range radio signals transmitted from the transmitter 2921B. The key fob 292B and the transport 291B each include a CPU 2922B and a CPU 2913B, respectively, which control their respective devices. Here, the memory of the CPU 2922B and the CPU 2913B (or memory accessible to the CPU) is used. In one example, the key fob 292B and the transport 291B each include a power supply 2924B and a power supply 2915B for powering their respective devices.

[0139] When a user presses button 293B on key fob 292B (or activates the fob, etc.), CPU 2922B within key fob 292B is activated and transmits a data stream to transmitter 2921B. This data stream is output via an antenna. In other embodiments, the user's intent is recognized by key fob 292B through other means, such as a microphone for receiving audio, a camera for capturing images and / or video, or other sensors commonly used in the art for detecting user intent, including gestures, motion, eye movement, etc. The data stream is a signal 64 to 128 bits long that includes one or more of a preamble, a command code, and a rolling code. The signal can be transmitted at a rate of 2 KHz to 20 KHz, although embodiments are not limited thereto. In response, receiver 2911B of transport 291B captures the signal from transmitter 2921B, demodulates the signal, and transmits the data stream to CPU 2913B. CPU 2913B decodes the signals and sends commands (lock doors, unlock doors, etc.) to command module 2912B.

[0140] If the key fob 292B and the transport 291B use a mutually fixed code, a replay attack is possible. In this case, if an attacker can capture / sniff the fixed code during close-range communication, the attacker can replay this code and infiltrate the transport 291B. To improve security, the key fob and the transport 291B may use a rolling code that changes with each use. In this case, the key fob 292B and the transport 291B are synchronized with an initial seed 2923B (e.g., a random number, a pseudorandom number, etc.). This is called pairing. The key fob 292B and the transport 291B also contain a shared algorithm to change the initial seed 2914B each time the button 293B is pressed. The next key press takes the result of the previous key press as input and converts it to the next number in the sequence. In some cases, the transport 291B may store multiple next codes (e.g., 255 next codes) in case a key press on the key fob 292B is not detected by the transport 291B. Therefore, key presses on key fob 292B that are not recognized by transport 291B will not prevent the transport from going out of synchronization.

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

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

[0143] In this example, ECU 291C includes a transceiver 2911C and a microcontroller 2912C. The transceiver is used to send and receive messages to and from CAN bus 297C. For example, transceiver 2911C converts data from microcontroller 2912C into the format of CAN bus 297C, and converts data from CAN bus 297C into the format of microcontroller 2912C. Meanwhile, microcontroller 2912C interprets messages and determines which messages to send, for example, using ECU software installed thereon.

[0144] Various security protocols can be implemented to protect CAN 290C from cyber threats. For example, subnetworks (e.g., subnetworks A and B) can be used to divide CAN 290C into smaller sub-CANs, limiting an attacker's ability to remotely access the transport. In the example of Figure 2K, ECUs 291C and 292C are part of the same subnetwork, while ECU 293C is part of a separate subnetwork. Additionally, a firewall 294C (or gateway, etc.) can be added to block messages from traveling between subnetworks via CAN bus 297C. Even if an attacker gains access to one subnetwork, they cannot access the entire network. To further enhance subnetwork security, one example is to not place the most critical ECUs in the same subnetwork.

[0145] Although not shown in Figure 2K, other examples of security controls within the CAN include intrusion detection systems (IDS). An IDS is added to each sub-network and reads all passing data to detect malicious messages. If a malicious message is detected, the IDS can notify the vehicle user. Other security protocols include encryption / security keys that can be used to hide messages. Also, authentication protocols are implemented, for example, to allow messages to authenticate themselves.

[0146] In addition to protecting the transport's internal network, the transport can also be protected when communicating with external networks, such as the Internet. One advantage of transport connectivity to data sources, such as the Internet, is that information from the transport can be transmitted over the network to remote locations for analysis. Examples of transport information include GPS, on-board diagnostics, tire pressure, etc. These communication systems are often referred to as telematics because they combine telecommunications and informatics. Additionally, the solution described and illustrated with respect to FIG. 2K can be utilized in this network and / or system, as well as other networks and / or systems, including those described and illustrated herein.

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

[0148] The secure management of data begins with the transport 291D. In some embodiments, the device 296D collects information before, during, and after a trip. Collected data includes GPS data, trip data, passenger information, diagnostic data, fuel data, speed data, and the like. However, the device 296D transmits collected information to the host server 295D only in response to the transport being ignited and completing a trip. Furthermore, communications are initiated only by the device 296D, and never by the host server 295D. Thus, in one example, the device 296D does not accept communications initiated from external sources.

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

[0150] In addition to communicating with external servers, transports can also communicate with each other. In particular, transport-to-vehicle (V2V) communication systems enable transports to communicate with each other and with roadside infrastructure (e.g., traffic lights, signs, cameras, parking meters, etc.) over wireless networks. Wireless networks include one or more of Wi-Fi networks, cellular networks, dedicated short-range communications (DSRC) networks, etc. Transports can use V2V communication to provide other transports with information regarding speed, acceleration, braking, direction, etc. Thus, transports can understand the situation ahead before it becomes apparent, significantly reducing collisions. Furthermore, the solution described and illustrated with respect to FIG. 2L can be utilized in this network and / or system, as well as other networks and / or systems, including those described and illustrated herein.

[0151] FIG. 2M illustrates example 290E of transports 293E and 292E performing secure V2V communication using security certificates according to an example embodiment. Referring to FIG. 2M, transports 293E and 292E can communicate via V2V communication over a short-range network, a cellular network, etc. Prior to sending a message, transports 293E and 292E can sign the message with their respective public key certificates. For example, transport 293E can sign the V2V message with public key certificate 294E. Similarly, transport 292E can sign the V2V message with public key certificate 295E. In one example, public key certificates 294E and 295E are associated with transports 293E and 292E, respectively.

[0152] When transports receive communications from each other, they can verify the signatures using, for example, a certificate authority 291E. For example, transport 292E can use certificate authority 291E to verify that public key certificate 294E used by transport 293E to sign the V2V communication is authentic. If transport 292E successfully verifies public key certificate 294E, the transport knows that the data is from a legitimate source. Similarly, transport 293E can use certificate authority 291E to verify that public key certificate 295E used by transport 292E to sign the V2V communication is authentic. Furthermore, the solution described and illustrated with respect to FIG. 2M can be utilized in this network and / or system, as well as other networks and / or systems, including those described and illustrated herein.

[0153]

[0033] Figure 2N shows a further diagram 290F illustrating an example of a transport interacting with a security processor and a wireless device, according to an example embodiment. In some embodiments, the computer 224 shown in Figure 2B can include a security processor 292F, as shown in example process 290F of Figure 2N. In particular, the security processor 292F can perform authorization, authentication, encryption (e.g., encryption), etc., on data transmissions sent between ECUs and other devices on a vehicle's CAN bus, as well as data messages sent between different vehicles.

[0154] 2N, security processor 292F can include authorization module 293F, authentication module 294F, and encryption module 295F. Security processor 292F is implemented within the transport's computer and can communicate with other transport elements, e.g., wired and wireless devices 298F, such as ECU / CAN network 296F, wireless network interfaces, input ports, etc. Security processor 292F ensures that data frames (e.g., CAN frames, etc.) transmitted within the transport (e.g., via ECU / CAN network 296F) are secure. Similarly, security processor 292F ensures that messages transmitted between different transports and devices wired or connected to the transport's computer are also secure.

[0155] For example, the authentication module 293F can store passwords, usernames, PIN codes, biometric scans, etc. for different transport users. The authentication module 293F can determine whether a user (or technician) has permission to access certain settings, such as the transport's computer. In some embodiments, the authentication module can communicate with a network interface to download the necessary authentication information from an external server. When a user modifies transport settings or technical details of the transport through a console or GUI within the transport or a connected device, the authentication module 293F can require the user to verify their identity in some manner before modifying such settings. For example, the authentication module 293F can request a username, password, PIN code, biometric scan, a predefined line drawing or gesture, etc. In response, the authentication module 293F can determine whether the user has the necessary permission (e.g., access) being requested.

[0156] The authentication module 294F can be used to authenticate internal communications between ECUs on a 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 ECUs on the CAN network. The ECUs can use this bit signature algorithm to insert authentication bits into the CAN field of a CAN frame. All ECUs on the CAN network typically receive each CAN frame. The bit signature algorithm can dynamically change the position, amount, etc. of the authentication bits each time a new CAN frame is generated by any ECU. The authentication module 294F can also provide a list of exempt ECUs (safe list) that do not need to use authentication bits. The authentication module 294F can communicate with a remote server to obtain updates to the bit signature algorithm, etc.

[0157] The encryption module 295F can store asymmetric key pairs that the transport uses to communicate with other external user devices and transports. For example, the encryption module 295F provides a private key that the transport uses to encrypt / decrypt communications, while providing the corresponding public key to other user devices and transports so that the other devices can decrypt / encrypt the communications. The encryption module 295F can communicate with a remote server to receive new keys, key updates, new transport, user, etc. keys, etc. The encryption module 295F can also send updates of its local private / public key pair to the remote server.

[0158] 3A illustrates a flow diagram 300 according to an exemplary embodiment. Referring to FIG. 3A, flow diagram 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, charging locations used by other vehicles with the same preferences (304), and routing the vehicle to the charging locations based on the determination (306).

[0159] 3B illustrates another flow diagram 320 according to an exemplary embodiment. As illustrated in FIG. 3B , flow diagram 320 may include one or more of: determining that the vehicle's battery level is below a threshold and including one or more preferences and the battery level in the request 322; routing based on the proximity of the vehicle and other vehicles to one another 323; determining a route from the vehicle's current location to a charging location and transferring the route to the vehicle 324; comparing one or more preferences associated with the vehicle with one or more historical preferences associated with the vehicle 325; partially modifying the one or more preferences according to the one or more historical preferences 326; selecting a charging location from one or more charging locations based on the modified one or more preferences 325; identifying an area of ​​high charging demand near the vehicle and modifying preferences based on characteristics of the area 326; routing the vehicle to a charging location different from the charging location 327; determining a modification of the vehicle's charging preferences based on the different charging locations 328; and saving the modified vehicle's charging preferences 329.

[0160] 3C illustrates yet another flow diagram 340 according to an example embodiment. Referring to FIG. 3C, the flow diagram includes one or more of receiving confirmation of an event from one or more elements described or illustrated herein, where the confirmation includes a blockchain consensus between peers represented by any of elements 342, and executing a smart contract to record the confirmation on the blockchain based on the blockchain consensus 344.

[0161] 4 illustrates a machine learning transport network diagram 400 according to an example embodiment. The network 400 includes a transport 402 that interfaces with a machine learning subsystem 406. The transport 402 includes one or more sensors 404.

[0162] The machine learning subsystem 406 includes learning models 408, which are mathematical artifacts created by a machine learning training system 410, and generates predictions by finding patterns in one or more training datasets. In some embodiments, the machine learning subsystem 406 resides within the transport 402. In other embodiments, the machine learning subsystem 406 resides external to the transport 402.

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

[0164] In further embodiments, transport 402 may transmit data from one or more sensors 404 to machine learning training system 410. In yet another example, machine learning subsystem 406 may transmit data from sensors 404 to machine learning subsystem 410. One or more of the applications, functions, steps, solutions, etc. described and / or illustrated herein may utilize machine learning network 400 as described herein.

[0165] FIG. 5A illustrates an example vehicle configuration 500 for managing database transactions related to a vehicle, according to an example embodiment. Referring to FIG. 5A, when a particular vehicle / vehicle 525 is engaged in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, transportation service, etc.), the vehicle can receive assets 510 and / or emit / transfer assets 512 in response to the transaction. A transport processor 526 resides within the vehicle 525, and communication occurs between the transport processor 526, database 530, transport processor 526, and transaction module 520. The transaction module 520 can record information such as assets, parties, credits, service descriptions, dates, times, locations, outcomes, notifications, unexpected events, etc. These transactions in the transaction module 520 are replicated to database 530. Database 530 can be an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, or a distributed ledger, and can be onboard or offboard the vehicle, accessed directly and / or over a network, and accessible to the vehicle.

[0166] FIG. 5B illustrates an example vehicle configuration 550 for managing database transactions between various vehicles, according to an embodiment. When a vehicle 525 needs to share services with other vehicles, it can coordinate with other vehicles 508 to perform various actions, such as sharing, transferring, or retrieving service calls. For example, the vehicle 508 may need to charge its battery, have a tire problem, or be on its way to pick up a package for delivery. The vehicle 508 includes a transport processor 528, and communication exists between the transport processor 528, a database 554, and a transaction module 552. The vehicle 508 can notify other vehicles 525 within its network that are running its blockchain member service. The vehicle 525 includes a transport processor 526, and communication exists between the transport processor 526, a database 530, the transport processor 526, and the transaction module 520. The vehicle 525 can receive information via wireless communication requests and perform package pickup from the vehicle 508 and / or a server (not shown). The transaction is recorded in transaction modules 552 and 520 of both vehicles. Credits are transferred from vehicle 508 to vehicle 525 and a record of the transferred service is recorded in database 530 / 554, assuming the blockchains are different from each other or recorded on the same blockchain used by all members. Database 554 may be an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, or a distributed ledger and may be on-board the vehicle, off-board the vehicle, and accessible directly and / or over a network.

[0167] FIG. 6A illustrates a blockchain architecture configuration 600 according to an example embodiment. Referring to FIG. 6A, the blockchain architecture 600 can include certain blockchain elements, such as a group of blockchain member nodes 602-606, as part of a blockchain group 610. In one embodiment, a permissioned blockchain is not accessible to all parties, but only to members with authorized access to the blockchain data. Blockchain nodes participate in several activities, such as adding blockchain entries and a validation process (consensus). One or more blockchain nodes can approve entries based on an endorsement policy and provide an ordering service to all blockchain nodes. Blockchain nodes can initiate blockchain actions (e.g., authentication) and attempt writes to a blockchain immutable ledger stored in the blockchain. A copy of this ledger may also be stored in the underlying physical infrastructure.

[0168] Once a blockchain transaction 620 is received and approved by a consensus model determined by member nodes, it is stored in computer memory. Approved transactions 626 are stored in the blockchain's current block and committed to the blockchain via a commit procedure (which involves performing a hash of the transaction's data content in the current block and referencing the previous hash in the previous block). Within the blockchain, there may be one or more smart contracts 630 that define the transaction agreements and action terms (e.g., registered recipient, vehicle features, requirements, permissions, sensor thresholds, etc.) contained in smart contract executable application code 632. This code can be configured to identify whether the requesting entity is registered to receive vehicle services, which service features it is entitled / required to receive based on its profile status, and whether to monitor the action for subsequent events. For example, when a service event occurs and a user is in the vehicle, sensor data monitoring is triggered and, if a certain parameter, such as the vehicle's charge level, is identified as being above / below a certain threshold for a certain period of time, the current status is changed, an alert is sent to a management entity (e.g., the vehicle owner, vehicle operator, or server), and the service is identified and stored for reference. The collected vehicle sensor data may be based on the type of sensor data used to gather information about the vehicle's status. Sensor data may also form the basis of vehicle event data 634, such as the planned trip location, average speed, maximum speed, acceleration, whether there were any collisions, whether the expected route was traversed, the next destination, whether safety measures have been implemented, and whether the vehicle has sufficient charge / fuel. All of this information forms the basis of smart contract conditions 630 and is stored on the blockchain. For example, sensor thresholds stored in the smart contract can be used as criteria to determine whether the detected service is required, as well as when and where the service should be performed.

[0169] FIG. 6B illustrates a shared ledger configuration according to an example embodiment. Referring to FIG. 6B, example blockchain logic 640 includes a blockchain application interface 642 as an API or plug-in application that links to computing devices and execution platforms for specific transactions. The blockchain configuration 640 can include one or more applications, which are linked to an application programming interface (API) and can access and execute stored program / application code (e.g., smart contract execution code, smart contracts, etc.). These applications can be created according to the customized configuration desired by participants and can maintain their own state, control their own assets, and receive external information. They can be deployed as entries and installed on all blockchain nodes via addition to the distributed ledger.

[0170] Smart contract application code 644 provides the foundation for blockchain transactions by establishing application code. When this application code is executed, the terms of the transaction become effective. When executed, smart contract 630 generates and transmits approved transactions 626 to a blockchain platform 652. This platform includes a computing device that runs security / authorization 658, transaction management 656, and storage 654, which is memory that stores transactions and smart contracts in the blockchain.

[0171] A blockchain platform may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure. These infrastructures may be used to receive and store new entries and provide access to auditors seeking access to data entries. The blockchain may expose interfaces that provide access to the virtual execution environments required to process program code and access the physical infrastructure. Cryptographic trust services may be used to validate entries, such as asset exchange entries, and to maintain the confidentiality of information.

[0172] The blockchain architecture configuration of Figures 6A and 6B can process and execute program / application code through one or more interfaces and services exposed by the blockchain platform. As a non-limiting example, smart contracts can be created to execute reminders, updates, and / or other notifications in response to changes, updates, etc. The smart contract itself can be used to identify authorization and access requirements, as well as rules associated with use of the ledger. For example, information can include new entries, which 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 peer consensus. Physical infrastructure can be utilized to obtain any of the data or information described herein.

[0173] Within smart contract executable code, smart contracts can be created via high-level application and programming languages ​​and then written into blocks within a blockchain. Smart contracts can include executable code that is registered, stored, and / or replicated on a blockchain (e.g., a distributed network of blockchain peers). An entry is an execution of smart contract code that can be executed in response to a condition associated with the smart contract being met. Execution of a smart contract can trigger trusted changes to the state of a digital blockchain ledger. Changes to the blockchain ledger caused by smart contract execution can be automatically replicated across a distributed network of blockchain peers through one or more consensus protocols.

[0174] Smart contracts can write data to the blockchain in the form of key-value pairs. Additionally, smart contract code can read values ​​stored on the blockchain and use them in application operations. Smart contract code can write the output of various logic operations to the blockchain. This code can be used to create temporary data structures on virtual machines and other computing platforms. Data written to the blockchain can be public or encrypted and kept private. The temporary data used / generated by smart contracts is kept in memory by the provided execution environment and is deleted once the data needed for the blockchain is identified.

[0175] The smart contract executable code can include code interpretations and additional functionality for the smart contract. As described herein, the smart contract executable code is program code deployed on a computing network and concurrently executed and validated by chain validators during the consensus process. The smart contract executable code receives a hash and retrieves a hash from the blockchain associated with a data template created using a previously stored feature extractor. If the hash of the hashed identifier matches the hash created from the stored identifier template data, the smart contract executable code sends an authentication key to the requested service. The smart contract executable code can write data associated with cryptographic details to the blockchain.

[0176] FIG. 6C illustrates a blockchain configuration for storing blockchain transaction data, according to an example embodiment. Referring to FIG. 6C, the exemplary configuration 660 enables a vehicle 662, a user device 664, and a server 666 to share information with a distributed ledger (i.e., blockchain) 668. The server may represent a service provider entity that queries vehicle service providers and shares user profile rating information when a known, established user profile seeks to rent a vehicle with an established rating profile. The server 666 may receive and process data related to the vehicle's service requirements. When a service event occurs, such as vehicle sensor data indicating the need for fuel / charging, maintenance service, etc., smart contracts may be used to invoke rules, thresholds, sensor information collections, etc. that can be used to invoke vehicle service events. Blockchain transaction data 670 is stored for each transaction, such as an access event, subsequent updates to the vehicle's service status, event updates, etc. A transaction includes the parties involved, requirements (e.g., over 18 years of age, eligible for service, valid driver's license, etc.), coverage level, distance traveled during the event, registered recipients authorized to access the event and host vehicle services, rights / permissions, sensor data acquired during the vehicle event operation to record details of the upcoming service event and identify the vehicle's health status, and thresholds used to determine if the service event is completed and if the vehicle's health status has changed.

[0177] FIG. 6D illustrates a blockchain block 680 and the contents of block structures 682A-682n that can be added to a distributed ledger according to an example embodiment. Referring to FIG. 6D, a client (not shown) can submit entries to a blockchain node to perform activities on the blockchain. As an example, a client can be an application that proposes entries to the blockchain on behalf of a requester, such as a device, person, or entity. Multiple blockchain peers (e.g., blockchain nodes) can maintain copies of the blockchain network state and the distributed ledger. A blockchain network can have different types of blockchain nodes / peers, such as endorsing peers that simulate and approve entries proposed by clients, and committing peers that verify the endorsement, validate the entries, and commit the entries to the distributed ledger. In this example, a blockchain node can act as an endorser node, a committer node, or both.

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

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

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

[0181] The ordering service accepts approved entries, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service can initiate a new block when a threshold number of entries is reached, a timer times out, or other conditions occur. In this example, the blockchain node is the committing peer that received data block 682A for storage in the blockchain. The ordering service can consist of a cluster of orderers. The ordering service does not process entries or smart contracts or maintain a shared ledger. Rather, the ordering service accepts approved entries and specifies the order in which those entries are committed to the distributed ledger. The architecture of a blockchain network can be designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) are pluggable components.

[0182] Entries are written to the distributed ledger in a consistent order. The order of entries is established to ensure that updates to the state database are valid when committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin) where ordering is achieved by solving a cryptographic puzzle, i.e., mining, in this example, the parties to the distributed ledger can choose the ordering mechanism that is best suited for their network.

[0183] Referring to FIG. 6D , a block 682A (also referred to as a data block) stored in a blockchain and / or distributed ledger may include multiple data segments, such as block headers 684A-684n, transaction-specific data 686A-686n, and block metadata 688A-688n. It should be understood that the various blocks and their contents shown, such as block 682A and its contents, are merely for illustrative purposes and do not limit the scope of the embodiments. In some cases, both the block header 684A and block metadata 688A may be smaller than the transaction-specific data 686A, which stores entry data, although this is not required. Block 682A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) in block data 690A-690n. Block 682A may also include a link to a previous block (e.g., on a blockchain) in block header 684A. In particular, block header 684A may include a hash of the previous block's header. The block header 684A may also include a unique block number, a hash of the block data 690A of the current block 682A, etc. Block numbers for blocks 682A are unique and assigned in incremental / sequential order starting from 0. The first block of a blockchain is called the genesis block and contains information about the blockchain, its members, the data stored therein, etc.

[0184] The block data 690A may store entry information for each entry recorded in the block. For example, the entry data may include one or more of the following: entry type, version, timestamp, distributed ledger channel ID, entry ID, epoch, payload visibility, smart contract execution code path (deploy transaction), smart contract execution code name, smart contract execution code version, inputs (smart contract execution code and functions), client (creator) ID such as a public key or certificate, client signature, endorser ID, endorser signature, proposal hash, smart contract execution code event, response status, namespace, read set (e.g., a list of keys and versions read by the entry), write set (e.g., a list of keys and values), start key, end key, list of keys, Merkel tree query summary, etc. 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-linked chain of blocks in the blockchain. Thus, data 686A may be stored in an immutable log of blocks on a distributed ledger. Some of the benefits of storing such data 686A are reflected in various embodiments disclosed and illustrated herein. Block metadata 688A may store multiple metadata fields (e.g., a byte array, etc.). The metadata fields include a signature at the time of block creation, a reference to the last constituent block, an entry filter that identifies valid and invalid entries in the block, and the last offset maintained by the ordering service that ordered the block. The signature, last constituent block, and orderer metadata are added by the ordering service. Alternatively, the block committer (e.g., a blockchain node) may add validity / invalidity information based on endorsement policies, validation of read / write sets, etc. The entry filter may include a byte array of size equal to the number of entries in block data 610A and a validation code that identifies whether the entry is valid or invalid.

[0186] The other blocks 682B-682n in the blockchain also contain headers, files, and values. However, unlike the first block 682A, each header 684A-684n of the other blocks contains the hash value of the immediately preceding block. The hash value of the immediately preceding block may be just the hash value of the previous block's header, or it may be the hash value of the entire previous block. By including the hash value of the previous block in each remaining block, a block-by-block tracing can be performed from the Nth block back to the genesis block (and associated original files), establishing an auditable, immutable chain of custody, as indicated by arrow 692.

[0187] The above embodiments may be implemented in hardware, a computer program executed by a processor, firmware, or a combination thereof. The computer program may be implemented in 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 is coupled to the processor such that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the storage medium may reside as discrete components. For example, FIG. 7 illustrates an example computer system architecture 700, which may represent or be integrated with any of the aforementioned components, etc.

[0189] 7 is not intended to suggest any limitations regarding the scope of use or functionality of the application embodiments described herein, and in any event, computing node 700 may implement and / or perform any of the functionality described herein.

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

[0191] The 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 include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 702 may be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices that are 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] 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 the computer system / server 702 include, but are not limited to, one or more processors or processing units 704, a system memory 706, and a bus connecting various system components including the system memory 706 to the processor 704.

[0193] A bus represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures, including, but not limited to, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, a Peripheral Component Interconnects (PCI) bus, etc.

[0194] The computer system / server 702 typically includes a variety of computer system-readable media. Such media are any available media accessible by the computer system / server 702, including both volatile and nonvolatile, removable and non-removable media. The system memory 706, in one example, implements the flow diagrams of other figures. The system memory 706 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 708 and / or cache memory 710. The computer system / server 702 may also include removable / non-removable, volatile / non-volatile computer system storage media. As one example, the memory 706 may provide for reading from and writing to non-removable, non-volatile magnetic media (not shown, commonly referred to as a "hard drive"). Although not shown, the memory may include a magnetic disk drive that reads from and writes to removable, non-volatile magnetic disks (e.g., "floppy disks") and an optical disk drive that reads from and writes to removable, non-volatile optical disks, such as CD-ROMs, DVD-ROMs, and other optical media. In such case, each may be connected to the bus by one or more data media interfaces. As further illustrated and described below, memory 706 may include at least one program product including a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of the present application.

[0195] A program / utility including a set of program modules (at least one) may be stored in memory 706, as well as, for example, but not limited to, an operating system, one or more application programs, other program modules, and program data. Each or a combination of the operating system, one or more application programs, other program modules, and program data may comprise an implementation of a network environment. The program modules generally perform the functions and / or methodologies of various embodiments of the applications described herein.

[0196] As will be appreciated by one skilled in the art, aspects of the present application may be embodied as a system, method, or computer program product. Accordingly, aspects of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects (which may be referred to collectively herein as a "circuit," "module," or "system"). Furthermore, aspects of the present application may take the form of a computer program product having computer-readable program code embodied in one or more computer-readable medium(s).

[0197] The computer system / server 702 may also communicate with one or more external devices via I / O devices 712 (e.g., I / O adapters) including a keyboard, pointing device, display, voice recognition module, etc. It may also communicate with one or more devices that allow a user to interact with the computer system / server 702 and / or any devices (e.g., network cards, modems, etc.) that allow the computer system / server 702 to communicate with one or more other computing devices. Such communication may occur via I / O interfaces of the devices 712. Additionally, the computer system / server 702 may communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via network adapters. As shown, the devices 712 communicate with other components of the computer system / server 702 via a bus. It should be understood that other hardware and / or software components, not shown, may be used 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, data archive storage systems, and the like.

[0198] While at least one exemplary embodiment of the system, method, and non-transitory computer-readable medium is illustrated in the accompanying drawings and described in the foregoing detailed description, it will be understood that the present application is not limited to the disclosed embodiments, but rather is susceptible to numerous rearrangements, modifications, and substitutions, as indicated and defined by the following claims. For example, the functionality of the various illustrated systems may be performed by one or more of the modules or components described herein, or in a distributed architecture, and may include pairs of transmitters, receivers, or both. For example, all or a portion of the functionality performed by individual modules may be performed by one or more of these modules. Furthermore, the functionality described herein may be performed at various times and in conjunction with various events internal or external to the modules or components. Furthermore, information transmitted between the various modules may be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or multiple protocols. Furthermore, messages sent or received by any module may 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, server, console, personal digital assistant (PDA), mobile phone, tablet computer, smartphone, or other suitable computing device, or a combination of these devices. Presenting the above-described functions as being performed by a "system" is not intended to limit the scope of the present application, but rather to provide one example of many embodiments. Indeed, the methods, systems, and apparatuses disclosed herein may be implemented in both local and distributed fashions consistent with computing technology.

[0200] It should be noted that some of the system functionality described herein is presented as modules to further emphasize implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integrated circuits (VLSI) or off-the-shelf semiconductors such as gate arrays, logic chips, transistors, and other discrete components. A module may also be implemented as a programmable hardware device such as a field programmable gate array, programmable array logic, programmable logic device, graphics processing unit, etc.

[0201] Modules may be implemented, at least in part, in software for execution by various types of processors. A particular executable code unit may include one or more physical or logical blocks of computer instructions, which may be organized, for example, as an object, procedure, or function. However, the executable files of a particular module need not be physically located together and may include different instructions stored in different locations that, when logically combined, constitute the module and achieve the module's intended purpose. Furthermore, modules may be stored on a computer-readable medium, such as a hard disk drive, a flash device, random access memory (RAM), tape, or other medium used to store data.

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

[0203] It will be readily understood that the components of the present application, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of configurations, and thus, the detailed description of the embodiments is not intended to limit the scope of the present application, as set forth in the claims, but is merely representative of selected embodiments of the present application.

[0204] Those skilled in the art will readily recognize that the above description can be implemented using a different order of steps and / or different hardware elements than those in the configurations disclosed. Thus, while the present application has been described in terms of these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative configurations may be readily apparent.

[0205] While preferred embodiments of the present application have been described, it should be understood that the described embodiments are exemplary only, and that the scope of the present application is defined solely by the appended claims, taking into account the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. receiving a request for charging from a vehicle; determining, based on one or more preferences associated with the vehicle, charging locations to be used by other vehicles having the same preferences; and routing the vehicle to the charging location based on the determination.

2. Receiving the request to charge comprises: determining that the vehicle's battery level is below a threshold; and including one or more of the preferences and the battery level in the request.

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

4. Routing the vehicle to the charging location based on the determination includes: determining a route from the current location of the vehicle to the charging location; and transferring the route to the vehicle.

5. comparing one or more preferences associated with the vehicle with one or more past preferences associated with the vehicle; partially modifying one or more of said preferences according to one or more of said past preferences; and selecting a charging location from among one or more charging locations based on one or more of the modified preferences.

6. Identifying an area near the vehicle where there is a high demand for charging; and modifying the preferences based on characteristics of the area.

7. determining to route the vehicle to a charging location different from the charging location; determining a change in charging preferences for the vehicle based on the different charging locations; and storing the changed vehicle charging preferences.

8. a processor; a memory coupled to the processor; The memory, when executed by the processor, receiving a request for charging from a vehicle; determining, based on one or more preferences associated with the vehicle, charging locations to be used by other vehicles having the same preferences; and routing the vehicle to the charging location based on the charging location determined by the processor.

9. The processor: determining that the vehicle's battery level is below a threshold; and including one or more of the preferences and the battery level in the request.

10. The system of claim 8 , wherein the processor routes the vehicle based on the proximity of the vehicle and the other vehicle to one another.

11. The instructions for the processor to route the vehicle include: determining a route from the current location of the vehicle to the charging location; The system of claim 8 configured to transfer the route to the vehicle.

12. The instruction: comparing one or more preferences associated with the vehicle to one or more past preferences associated with the vehicle; partially modifying one or more of said preferences according to one or more of said past preferences; The system of claim 8 , configured to select a charging location from among one or more charging locations based on one or more of the modified preferences.

13. The instruction: Identifying an area near the vehicle where there is a high demand for charging; The system of claim 8 , configured to modify the preferences based on characteristics of the area.

14. The instruction: determining to route the vehicle to a charging location different from the charging location; determining a change in charging preferences for the vehicle based on the different charging locations; The system of claim 8 , configured to save the modified vehicle charging preferences.

15. When read by a processor, the processor: receiving a request for charging from a vehicle; determining, based on one or more preferences associated with the vehicle, charging locations to be used by other vehicles having the same preferences; and routing the vehicle to the charging location based on the determination.

16. Receiving the request to charge comprises: determining that the vehicle's battery level is below a threshold; and including one or more of the preferences and the battery level in the request.

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

18. Routing the vehicle to the charging location includes: determining a route from the current location of the vehicle to the charging location; and transferring the route to the vehicle.

19. The instructions cause the processor to: comparing one or more preferences associated with the vehicle with one or more past preferences associated with the vehicle; partially modifying one or more of said preferences according to one or more of said past preferences; and selecting a charging location from among the one or more charging locations based on the one or more modified preferences.

20. The instructions cause the processor to: Identifying an area near the vehicle where there is a high demand for charging; and modifying the preferences based on characteristics of the area.

Images