Content delivery based on vehicle charging

Abstract

Example operations include one or more of querying a computer of a vehicle via a charging station, where the querying includes receiving an attribute of a rechargeable battery of the vehicle from the computer; determining a total charging time of the rechargeable battery based on the attribute of the rechargeable battery and the attribute of the charging station; selecting a media content from among a plurality of media contents based on the determined total charging duration of the rechargeable battery; and outputting the media content via the charging station.

Description

Background Technology

[0001] Vehicles or means of transport (such as cars, motorcycles, trucks, airplanes, trains, etc.) typically provide for the transport of passengers and / or goods in various ways. Vehicle-related functions can be identified and utilized by various computing devices, such as computers or smartphones located on and / or outside the vehicle. Summary of the Invention

[0002] One example embodiment provides a method comprising one or more of the following operations: querying a vehicle’s computer via a charging station, wherein the query includes receiving attributes of the vehicle’s rechargeable battery from the computer; determining a total charging time for the rechargeable battery based on the attributes of the rechargeable battery and attributes of the charging station; selecting media content from a plurality of media content based on the determined total charging time of the rechargeable battery; and outputting the media content via the charging station.

[0003] Another example embodiment provides an apparatus comprising: a memory storing a plurality of media contents; and a processor communicatively coupled to the memory, wherein the processor performs one or more of the following operations: querying a vehicle's computer via a charging station, wherein the query includes receiving attributes of the vehicle's rechargeable battery from the computer; determining a total charging time for the rechargeable battery based on the attributes of the rechargeable battery and attributes of the charging station; selecting media contents from the plurality of media contents stored in the memory based on the determined total charging time of the rechargeable battery; and outputting the media contents via the charging station.

[0004] Another example embodiment provides a computer-readable storage medium including instructions that, when executed by a processor, cause the processor to perform one or more of the following operations: querying a vehicle's computer via a charging station, wherein the query includes receiving attributes of the vehicle's rechargeable battery from the computer; determining a total charging time for the rechargeable battery based on the attributes of the rechargeable battery and the attributes of the charging station; selecting media content from a plurality of media content based on the determined total charging time of the rechargeable battery; and outputting the media content via the charging station. Attached Figure Description

[0005] Figure 1A The process of outputting media content to a display device of a vehicle based on the charging time of the vehicle's rechargeable battery, according to an example embodiment, is illustrated.

[0006] Figure 1BThe process of selecting media files based on the charging time of a rechargeable battery, according to an example embodiment, is illustrated.

[0007] Figure 1C The process of analyzing a battery charging curve according to an example embodiment is shown.

[0008] Figure 2A A vehicle network diagram according to an example embodiment is shown.

[0009] Figure 2B Another vehicle network diagram according to an example embodiment is shown.

[0010] Figure 2C Another vehicle network diagram according to an example embodiment is shown.

[0011] Figure 2D Another vehicle network diagram according to an example embodiment is shown.

[0012] Figure 2E A flowchart according to an example embodiment is shown.

[0013] Figure 2F Another flowchart based on an example embodiment is shown.

[0014] Figure 3A An AI / ML network diagram for integrating an artificial intelligence (AI) model into any decision point is shown in an example embodiment.

[0015] Figure 3B The process for developing an artificial intelligence (AI) / machine learning (ML) model to support AI-assisted decision points for vehicles or occupants is illustrated.

[0016] Figure 3C The process is illustrated for using an artificial intelligence (AI) / machine learning (ML) model to assist vehicle or occupant decision points.

[0017] Figure 3D A machine learning network diagram according to an example embodiment is shown.

[0018] Figure 3E Another machine learning network diagram according to an example embodiment is shown.

[0019] Figure 4A A diagram depicting the electrification of one or more components according to an example embodiment is shown.

[0020] Figure 4B A diagram depicting the interconnection between different components according to an example embodiment is shown.

[0021] Figure 4CAnother diagram depicting the interconnection between different elements according to an example embodiment is shown.

[0022] Figure 4D Another diagram depicting the interconnection between elements according to an example embodiment is shown.

[0023] Figure 4E Another figure is shown illustrating an example of a vehicle using a security certificate to perform secure vehicle-to-vehicle (V2V) communication, according to an example embodiment.

[0024] Figure 5A An example vehicle configuration for managing database transactions associated with a vehicle, according to an example embodiment, is shown.

[0025] Figure 5B An example blockchain group according to an example embodiment is shown.

[0026] Figure 5C An example interaction between an element and a blockchain, according to an example embodiment, is shown.

[0027] Figure 5D An example data block interaction is shown according to an example embodiment.

[0028] Figure 5E A blockchain network diagram according to an example embodiment is shown.

[0029] Figure 5F An example new data block is shown according to an example embodiment.

[0030] Figure 6 An example system supporting one or more example embodiments is shown. Detailed Implementation

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

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

[0033] The features, structures, or characteristics described herein can be combined in any suitable manner in one or more embodiments. For example, the use of phrases such as “example embodiment,” “some embodiments,” “first embodiment,” or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with one or more embodiments can be included in one or more other embodiments described or depicted herein. Therefore, one or more embodiments described or depicted throughout this specification may refer entirely to the same embodiment. Thus, these embodiments can work in conjunction with any other embodiments, can be functionally inseparable, and the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Although described in a particular manner by way of example only, unless expressly indicated otherwise herein, one or more features, one or more elements, and one or more steps described herein can be used together or in various combinations, and are not exclusive. In the drawings, any connection between elements can allow unidirectional and / or bidirectional communication, even if the depicted connection is unidirectional or bidirectional, such as arrows.

[0034] In this solution, a vehicle may include one or more of the following: automobiles, trucks, internal combustion engine (ICE) vehicles, battery electric vehicles (BEVs), fuel cell vehicles, any vehicle utilizing renewable energy, hybrid vehicles, electric flatbed trucks (e-Palettes), buses, motorcycles, scooters, bicycles, boats, recreational vehicles, aircraft, drones, unmanned aerial vehicles (UAVs), and any object that can be used to transport people and / or goods from one location to another.

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

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

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

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

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

[0040] A ledger is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions can be caused by smart contract executable code calls (i.e., entries) submitted by participants (e.g., client nodes, sorting nodes, endorser nodes, peer nodes, etc.). An entry can result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as creation, update, deletion, etc. The ledger includes the blockchain (also known as the chain), which stores an immutable, ordered record in blocks. The ledger also includes a state database that maintains the current state of the blockchain. Typically, each channel has its own ledger. Each peer node maintains a copy of the ledger for each channel for which they are members.

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

[0042] The current state of an immutable ledger represents the latest value of all keys included in the chain entry log. Because the current state represents the latest key-value pair known to the channel, it is sometimes referred to as the world state. Smart contract executables invoke the current state data of the ledger to execute entries. To make these smart contract executable interactions efficient, the latest value of the key can be stored in a state database. The state database can simply be an indexed view of the chain entry log and therefore can be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) when peer nodes start up and before entries are accepted.

[0043] The difference between blockchain and traditional databases is that blockchain is not a central store, but a decentralized, immutable, and secure store where nodes must share changes to the records stored. Some inherent properties of blockchain that help enable it 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 that vehicle. For example, a user may be the owner of the vehicle or the operator of a vehicle owned by another party. Vehicles may require service at intervals, and service requests may require authorization before being allowed to receive service. Furthermore, the service center may provide service to vehicles in the vicinity based on the vehicle's current route plan and the relative level of service demand (e.g., immediate, severe, moderate, minor, etc.). Vehicle demand may be monitored via one or more vehicle and / or road sensors or cameras, which report the sensed data to a central controller computer device located in and / or away from the vehicle. This data is forwarded to a management server for review and action. Sensors may be located inside the vehicle, outside the vehicle, on a fixed object away from the vehicle, or on one or more other vehicles nearby. Sensors may also be associated with vehicle speed, vehicle braking, vehicle acceleration, fuel level, service demand, vehicle gear shifting, vehicle steering, etc. As described herein, sensors may also be devices such as wireless devices located in and / or near the vehicle. Furthermore, sensor information can be used to identify whether the vehicle is operating safely and whether occupants have been involved in any unforeseen vehicle conditions, such as during vehicle access and / or usage periods. Vehicle information collected before, during, and / or after vehicle operation can be identified and stored in transactions on a shared / distributed ledger, which can be generated and submitted to an immutable ledger as determined by a permissioned consortium, and thus in a “decentralized” manner, such as via a blockchain membership group.

[0045] Each relevant party (i.e., owner, user, company, agent, etc.) may want to limit the exposure of private information, and therefore blockchain and its immutability can be used to manage permissions for each specific user's vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when service is needed, identify collision and / or degradation 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. Moreover, the results can be identified, and the necessary information can be shared among registered companies and / or individuals based on consensus methods associated with the blockchain. Such methods cannot be implemented on traditional centralized databases.

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

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

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

[0049] Any action described herein can be performed by one or more processors (such as microprocessors, sensors, electronic control units (ECUs), head units, etc.) with or without memory, and these processors can be located on or outside the vehicle (such as servers, computers, mobile / wireless devices, etc.). One or more processors can communicate with other memory and / or other processors on or outside other vehicles to utilize data transmitted by and / or sent to the vehicle. One or more processors and other processors can send data, receive data, and utilize that data to perform one or more of the actions described or depicted herein.

[0050] Electric vehicles continue to gain popularity and are expected to become one of the primary modes of transportation. Electric vehicles contain rechargeable batteries that can be recharged via charging stations. Charging stations (also known as charging points or electric vehicle power supply equipment (EVSEs)) are power supply devices that provide electricity to recharge "plug-in" electric vehicles, including hybrid vehicles. There are two main types of electric vehicle chargers: AC charging stations and DC charging stations. Electric batteries typically require the transfer of charge in direct current (DC). In some cases, electric vehicles or charging stations may include a built-in AC-DC converter, enabling AC charging stations to charge electric vehicles.

[0051] During the charging process, the charging station draws electrical energy (e.g., current) from a 240V outlet or the power grid to which it is hardwired and delivers this energy to the vehicle. Unlike gas stations, where refueling takes only a few minutes, charging stations can take several hours to fully charge a battery. For example, the average electric vehicle may require eight hours or more to charge from empty to full. Furthermore, the charging rate is not constant. In particular, the charging rate when the battery is empty is much faster than when it is nearly full (e.g., 80% full). This is because as battery cells begin to fill, electricity must flow to available empty cells. However, when there is less available capacity in the battery, it takes longer for electrical energy to find empty cells.

[0052] The example embodiment relates to an advanced charging station that can dynamically provide media content to the occupants of an electric vehicle based on the amount of charging time required for the vehicle's rechargeable battery. The charging station also includes the ability to provide different content to different occupants of the vehicle based on the vehicle's charging time. As an example, first media content can be transmitted to an in-vehicle display system, and second media content can be transmitted to a connected user device.

[0053] Charging time can be determined based on various attributes retrieved from the vehicle itself, the charging station environment, and other factors. These attributes may include, but are not limited to, the type of rechargeable battery installed in the vehicle, the current state of charge of the rechargeable battery, a predefined battery charging rate curve, the availability of the charging station, and the rate at which the power is supplied by the charging station. Media content can be selected such that it has sufficient time to complete playback within the expected charging time. As another example, media content can be selected such that it has an intermediate pause point with sufficient time to complete based on the expected charging time.

[0054] Figure 1A A process 100A is illustrated, which outputs media content to a display device of vehicle 110 based on the charging time of a vehicle's rechargeable battery according to an example embodiment. (See reference...) Figure 1A Process 100A can be performed by a charging station 130 that communicates with vehicle 110 (or a user device, such as mobile device 120, paired with the vehicle). In this example, charging station 130 includes a communication interface 132 for communicating with vehicle 110 via a wired or wireless connection and a charger 136 for charging the rechargeable battery (not shown) of vehicle 110. Charger 136 may include a charging cable (not shown) that can be inserted into the charging port of vehicle 110 and supply power to the rechargeable battery of vehicle 110 through the inserted cable.

[0055] According to various embodiments, the communication interface 132 can be connected to the vehicle computer 112 via a wired or wireless connection. Figure 1B (As shown in the diagram) Communication. As an example, a wired connection can be established via a charging cable inserted into the charging port, but this also enables bidirectional data communication between the vehicle computer 112 and the communication interface 132. As another example, a wireless connection can exist between the communication interface 132 and the vehicle computer 112 via a network such as the Internet. When communication is in progress, the communication interface 132 can query the vehicle computer 112 for the properties of the vehicle's rechargeable battery. Regarding... Figure 1B Further examples of the process are described.

[0056] Continue to refer to Figure 1AThe charging station 130 also includes a software application 134 that provides media content to the occupants of the vehicle 110 during charging operations by the charging station 130 and the rechargeable battery of the vehicle 110. Here, the software application 134 can receive attributes of the vehicle 110 retrieved by the communication interface 132. In some embodiments, the software application 134 can also retrieve attributes of the charging station 130, such as availability data of the charging station 130. Availability data may include how quickly the charging station 130 can begin charging the vehicle 110, the charging rate provided by the charger 136, etc.

[0057] According to various embodiments, software application 134 can determine the total charging time of vehicle 110 based on attributes retrieved by communication interface 132, and select media files to be played during the charging operation from media file system 140, which includes a database of media files containing content that can be output to the display device of vehicle 110. In this example, media file system 140 may be part of charging station 130; however, it should be understood that media file system 140 may be a remote platform that software application 134 can query and retrieve media content via a computer network. By enabling charging station 130 to retrieve files to be played remotely, charging station 130 does not need to store media files.

[0058] Software application 134 can determine where media content is displayed during charging operations. For example, software application 134 can use sensors (not shown) on charging station 130 to identify whether the driver is the only occupant. As another example, charging station 130 can determine whether a user device (such as mobile device 120) is paired with vehicle 110. Software application 134 can deliver media content to an in-vehicle display system, such as an infotainment system, an embedded video monitor, etc. As another example, software application 134 can deliver media content to an occupant's user device (such as mobile device 120), allowing the occupant to view the media content via user interface 122 of user device 120. In some embodiments, software application 134 can simultaneously deliver media content (e.g., different media content) to multiple different devices, including in-vehicle displays and user devices, at the same time.

[0059] The time required to charge the rechargeable battery of an electric vehicle is based on various factors, such as how much charge (kilowatt-hours (kWh)) will enter the vehicle and how much power (kilowatts (kW)) the charging station provides. Dividing the required charge by the provided power can give a rough estimate of the time required to complete charging. However, other variables can affect charging time. In the example embodiment, a more accurate time estimate can be generated by considering additional attributes associated with the vehicle battery and / or the charging station, including charging station availability, ambient temperature around the vehicle, battery temperature, battery type and capacity, battery state of charge, etc.

[0060] An empty battery will charge much faster than a battery that is already at 80% charge. This is because power must flow to available empty cells as the battery cells begin to utilize their charge to fill up. In a battery that is almost at its full capacity, power will take longer to find empty cells compared to a battery that is mostly depleted. In some embodiments, a battery profile can be used to further refine the determination of charging time. Battery profiles may vary slightly based on the manufacturer and the composition of the corresponding battery, but each battery will have a charging profile that exhibits similar behavior over time, where charging time increases as the battery's state of charge increases.

[0061] By including additional variables in the equation, such as those for a specific battery charging curve, battery temperature, charging station power, and the amount of charge applied to the battery, a more accurate charging time estimate can be derived. Given this accurate time estimate, software application 134 can query the media file system 140 or a remote entertainment content distribution platform for recommendations on various forms of entertainment based on the expected charging time. Media content can be output to vehicle passengers where the viewing time required to watch the content (or interact with it in the case of gaming) closely matches the charging time estimate, ensuring that viewers can finish watching the content or reach a natural stopping point when charging is complete.

[0062] Figure 1B A process 100B for selecting media files based on the charging time of a rechargeable battery, according to an example embodiment, is shown, and Figure 1C A process 100C for analyzing battery charging curves according to an example embodiment is shown. (Reference) Figure 1B and Figure 1CAn advanced vehicle charging interface (e.g., communication interface 132, etc.) can communicate with the vehicle's onboard computer (e.g., vehicle computer 112) to retrieve attributes of the vehicle 110's battery, including battery state of charge, battery type, battery capacity, battery temperature, etc. These attributes can be provided to software application 134. Software application 134 can also communicate with an environmental sensor that provides the temperature of the environment surrounding vehicle 110 and / or charging station 130. Software application 134 can also communicate with charger 136 of charging station 130 to obtain charging rate / power output rate of charger 136 and other availability data associated with charging station 130.

[0063] Software application 134 can execute predefined algorithms 160 based on attribute values ​​(such as...). Figure 1C As shown in the diagram, predefined algorithms 160 can be used to determine the estimated charging time of vehicle 110, such as artificial intelligence (AI) models, machine learning models, statistical equations, etc. The predefined algorithm 160 can be based on factors such as the vehicle's battery capacity, current charging level, and power output at the charging point. In some embodiments, the predefined algorithm 160 can consider factors such as... Figure 1C The battery charging rate graph 150 shown is a plot / curve relating the charging power (at the charging station) to the state of charge (SOC) of the vehicle's rechargeable battery. Here, the graph indicates that the battery will charge at a faster rate until the SOC reaches a certain capacity and the charging rate slows down. As the SOC increases, the slowing down continues until fully charged.

[0064] Once this time is established, software application 134 can query the application programming interface (API) 142 of media file system 140 to obtain a list of media files with a duration equal to or less than the charging time. As another example, media file system 140 can obtain media files with a duration greater than the expected charging time but with an intermediate stop point that occurs before the end of the expected charging time. Media content can include movies, video games, advertisements, games, etc. Software application 134 can automatically play content to one or more occupants of vehicle 110 based on the media files returned from media file system 140 via API 142. As another example, software application 134 can display a list of selectable media files on the user interface of the vehicle's display device, allowing occupants to select from the list of possible media content.

[0065] Content distribution in software application 134 can be designed to intelligently select content based on a given charging time. This ensures that passengers can fully consume the content when the vehicle finishes charging or reach a natural stop point within the content. Prioritization within software application 134 can typically identify primary and secondary passengers based on vehicle ownership records or user profiles created within the system. Primary passengers (usually the driver) are given access to the vehicle's built-in display, where they can play video games or watch movies. Meanwhile, secondary passengers can receive content recommendations for their personal devices. If these devices lack an audio system, subtitles are activated, or if headphones are available, passengers can enjoy content with audio.

[0066] Software application 134 may include a synchronization function that ensures all selected content (whether video games, movies, or TV shows) starts and ends at approximately the same time. This is achieved through a content alignment function that adjusts or provides recommendations based on content length and shared passenger interests. When an occupant is engrossed in an exciting video game or when several minutes remain after charging has finished, the solution makes an instant assessment in conjunction with charging station occupancy sensors. If no other vehicles are waiting for their turn, the solution notifies the driver, giving them the option to continue charging at a reduced rate or simply remain parked to finish their content.

[0067] This solution includes a credit system (not shown) that serves as an incentive to encourage longer stays (and therefore more content consumption), where credits are granted based on the amount of time spent at the station. These credits can be redeemed for premium content or discounts on future charging sessions. In one embodiment, if content has not yet reached its end and no subsequent vehicles are waiting to access the charging bay, a notification is received upon completion of the charging session, providing the option to continue charging at a reduced rate or remain parked without charging. In one embodiment, entertainment content is synchronized such that it ends approximately at the end of the charging session, or that it can be fully consumed within the estimated charging time or reach a natural stopping point. In one embodiment, the solution delivers content destined for the personal devices of vehicle occupants by routing the content via the vehicle's network capabilities. In one embodiment, the solution delivers bifurcated content to the occupants in the vehicle. The bifurcated content is the same basic content for all occupants; however, depending on the display or device, the content may include additional enhanced features. For example, if the bifurcated content is a sporting event, the enhanced features may include sports statistics, multiple viewing angles of the event, and / or other enhancements. This additional enhanced content is only transmitted to displays or devices capable of processing it. In the case of primary passengers, their content is typically transmitted to the main in-vehicle display, which has greater processing power, higher quality resolution, a larger display screen, etc., and is capable of handling such enhanced content. Meanwhile, forked content of the same sporting event transmitted to the personal devices of one or more secondary passengers may not include the additional enhanced content due to the capabilities of their devices.

[0068] Content to be delivered to the vehicle can be dynamically transmitted via this solution to the devices associated with occupants leaving the vehicle. The content delivered to the vehicle follows the occupant, so that when the occupant leaves the vehicle, the content is transmitted to the occupant's device. When the occupant returns to the vehicle or otherwise enters the vehicle, the content is transmitted from the device to the vehicle. When more than one occupant is in the vehicle, each occupant can consume different content, all provided by the vehicle and / or this solution. When each occupant leaves the vehicle, content follows them on the device associated with each occupant. When returning to the vehicle, the content delivered to each device is transmitted to the vehicle. The content can be viewed on the display closest to each occupant's location within the vehicle.

[0069] A charging point can be a charging port, charging station, or any location where a vehicle can receive electricity. Multiple charging points can exist within a charging location. A charging point, charging port, and / or charging station can be a place where a vehicle can receive and / or provide electricity. The terms "charging point," "charging port," or "charging station" are used interchangeably with "charging location." In one embodiment, content can be provided to the vehicle from a server at a charging port, charging location, and / or a server in a network / cloud located remotely from the charging location. The terms "energy," "electricity," and "charge" refer to power obtained from the utilization of physical or chemical resources.

[0070] In one embodiment, the system provides educational content to an electric vehicle (EV) during its charging time. The system offers a range of educational programs and courses specifically tailored to match the EV's charging duration. When the vehicle arrives at a charging station, the onboard computer interfaces with the station to determine the estimated charging time. This time is then used as a parameter to select educational content from a diverse library, which may include language courses, coding tutorials, short professional courses, TED talks, podcasts, and more. The system adapts to the user's ongoing educational pursuits. For example, if a user is taking an online course, the system synchronizes with their learning profile (potentially through an app or online platform they have registered for). It resumes the course where it left off during the last session, ensuring that even short charging periods are used effectively for learning. The system includes interactive elements that can be accessed on a tablet or the vehicle's infotainment system, such as quizzes, voice-activated responses for language learning, or exercises for coding courses. Furthermore, the system can be customized based on the user's preferences and learning goals. For example, a user preparing for a certification exam might choose to receive content particularly relevant to their learning topic. Similarly, a traveler learning a new language for an upcoming trip could focus on language courses. The system also offers child-friendly educational content, such as interactive learning games or educational cartoons. It's a valuable tool for parents who want to engage constructively with their children during recharge sessions.

[0071] In one embodiment, the system enriches the charging experience for electric vehicles (EVs) by integrating virtual reality (VR) technology at the charging station. When an EV is plugged in for charging, the onboard system calculates an estimated charging time. This information is transmitted to VR settings available at the charging station. Depending on the duration of the charging, a range of VR experiences are offered to passengers. These experiences range from short virtual tours of famous cities and landmarks to longer, more immersive experiences, such as virtual hikes through exotic locations or deep-sea diving adventures. The VR settings can be stand-alone kiosks or self-service terminals with high-resolution VR headsets and controllers, ensuring a fully immersive experience. For shorter charging times, quick and engaging experiences are offered, such as virtual roller coaster rides or brief space walks. For longer charging sessions, more sophisticated experiences are available, such as guided tours of historical sites, virtual reality games, or educational experiences (such as walks inside the human body). A key feature of the system is its ability to provide multi-user VR experiences, allowing different vehicles at the same charging station to interact within the same virtual space, thus creating opportunities for social interaction and community building among EV users. For example, families can embark on virtual safari together, or individuals can participate in multiplayer games or cooperative puzzle-solving. The content offered in VR experiences can be tailored to the location of the charging station. For instance, charging stations near tourist attractions can offer virtual tours related to local culture and history, enhancing the user's travel experience. Similarly, stations in urban areas can focus on relaxing and nature-based experiences, providing a refreshing escape from the city.

[0072] In one embodiment, the system incorporates interactive fitness classes while the vehicle is charging at a charging station. Upon arrival at the charging station, the vehicle's system calculates an estimated charging time. Based on this duration, the system suggests various fitness programs tailored to the available time frame. Exercises are designed to suit different fitness levels and preferences, ranging from quick, energetic stretches suitable for short charging sessions to more vigorous workouts for longer charging periods. The system integrates foldable or portable exercise equipment, such as yoga mats, resistance bands, or compact stationary bikes, at the charging station. The equipment is stored in a designated area easily accessible to the EV driver and passengers. Users can select exercises from a digital platform and use the appropriate equipment to facilitate their workout plans. Alternatively, the vehicle uses its infotainment system to display interactive digital workouts. These can include guided yoga classes, Pilates, bodyweight exercises, and meditation and breathing exercises for relaxation. Exercises can be performed inside or near the vehicle, utilizing the vehicle to support certain workouts. The system also syncs with personal fitness devices or apps, allowing users to record their workouts, track their progress, and even continue their existing fitness plans or challenges. The system also includes interactive elements such as virtual fitness challenges or leaderboards. Users at different charging stations can compete against each other in fitness challenges, adding an interactive and competitive edge to the charging wait.

[0073] In one embodiment, the system provides an entertainment package to customers while the EV is charging at a charging station. The system enhances the family's electric vehicle (EV) charging experience by offering a variety of entertainment options to suit passengers of all ages. The system recognizes the presence of family members in the vehicle and provides each with a range of age-appropriate and engaging content. When the vehicle is plugged into a charging station, the vehicle's systems interact with the charging infrastructure to estimate the charging duration. Based on the time frame, the system proposes a range of entertainment options tailored to the family setting. This could include a selection of movies, educational games, interactive storybooks, or family-friendly trivia and puzzle games. The content is carefully curated to ensure it is age-appropriate and appeals to a variety of interests. The system personalizes the content through integration with a family profile, taking into account each family member's preferences and viewing history. For example, if a child in the vehicle enjoys animated films, the system might recommend the latest releases in that genre. If the family is known to enjoy playing games together, it might offer new multiplayer games that can be played using the vehicle's infotainment system or personal devices. The content duration is aligned with charging time, ensuring entertainment ends or reaches a suitable stopping point when charging is complete, thus preventing the frustration of stopping a movie midway or giving up a game prematurely. The system allows family members to vote on what to watch or play, making the selection process engaging and inclusive. Furthermore, educational content, such as documentaries or interactive learning apps, is included to balance fun and learning. The system also considers practical aspects such as screen visibility and audio. Depending on the vehicle's configuration, it directs audio to individual headphones or enables subtitles, ensuring everyone has a comfortable viewing or playing experience without disturbing each other.

[0074] In one embodiment, the system enriches the electric vehicle (EV) charging experience by connecting it with local exploration and discovery. The system provides passengers with engaging content about the area surrounding the charging station, transforming charging wait times into opportunities for cultural and educational enrichment. When the EV is plugged into the charging station, the vehicle's system calculates an estimated charging time. Simultaneously, it accesses a local content database, including information on nearby attractions, historical sites, cultural landmarks, and events. The local content is curated based on the charging station's current location and the duration of the charging session. The types of content offered can vary considerably. For shorter charging sessions, the system offers quick and informative video or virtual tours of nearby points of interest, such as local museums or historical monuments. For longer charging periods, more in-depth content is provided, such as documentaries about the area's history, culture, or natural wonders. This includes interactive guides or augmented reality experiences that bring local stories and heritage to life. Content includes information on local restaurants, craft shops, and events, encouraging passengers to further explore the area after their vehicle has charged. The system provides personalized recommendations based on the passenger's interests. For example, if the system identifies a preference for culinary experiences, it might highlight local food tours or specialty restaurants. Similarly, for nature lovers, it might suggest nearby parks or scenic trails. The local discovery content system incorporates interactive elements, such as quizzes about the area or treasure hunts that passengers can participate in if they explore the area on foot while their vehicles are charging.

[0075] In one embodiment, the system integrates the vehicle charging process with a media content delivery system. The charging station is equipped with a unique software application. The charging station includes both a communication interface and a charger, and it connects to the vehicle's onboard computer. Once the vehicle connects to the charging station, the communication interface queries the vehicle's computer. This query collects specific attributes of the vehicle's rechargeable battery, such as its current state of charge, type, capacity, and temperature. Additionally, the charging station acquires data about its capabilities, such as charging rate and availability. Upon receiving battery attributes from the vehicle's computer and data from the charging station, the charging station application calculates the total charging time required for the vehicle's battery. The charging time estimate is refined by considering various factors, including the battery's specific charging curve, environmental conditions (such as ambient temperature), and the charger's power output. After determining the total charging time, the charging station application selects media content based on the calculated charging duration. The media content ranges from movies and video games to interactive content. It originates from a media file system, which can be an integral part of the charging station or a remote platform accessible via a network. In response to queries from the software application, the media file system provides a list of media files. These files have a duration equal to or less than the estimated charging time, or longer but with appropriate intermediate stops. The software application then automatically plays content for the vehicle occupants or presents it as an optional option on the vehicle's display. Furthermore, the system is designed to meet the diverse needs of both primary and secondary passengers. For example, the primary passenger (typically the driver) can receive content recommendations for the vehicle's main display, while secondary passengers can receive recommendations for their devices. The system ensures the synchronization of content start and end times, aligning them with the charging duration. If an occupant leaves the vehicle, the system can dynamically transfer content to their device and continue the content in the vehicle when they return. It can also extend the dwell time at the charging station if the content has not yet finished and the charging port is not immediately requested by another vehicle, further enhancing the overall experience.

[0076] The flowcharts depicted in this article (such as...) Figure 2C , Figure 2D , Figure 2E and Figure 2F The examples shown are separate examples, but may be the same or different embodiments. Any operation in one flowchart may be adopted and shared with another flowchart. The example operations are not intended to limit the subject matter of any embodiment or the corresponding claims.

[0077] It is important to note that, from Figure 2C , Figure 2D , Figure 2E and Figure 2FAll derived flowcharts and corresponding processes can be part of the same process or can share subprocesses with each other, so that these diagrams can be combined into a single preferred embodiment that does not require any particular operation but performs certain operations from an example process and from one or more additional processes. All example processes involve the same physical system and can be used individually or interchangeably.

[0078] This solution can be used in conjunction with one or more types of vehicles: battery electric vehicles, hybrid vehicles, fuel cell vehicles, internal combustion engine vehicles, and / or vehicles utilizing renewable energy.

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

[0080] Figure 2B Another vehicle network diagram 210 according to an example embodiment is shown. The network includes components including vehicle 202 containing processor 204 and vehicle 202' containing processor 204'. Vehicles 202 and 202' communicate with each other via processors 204 and 204' and other components (not shown), including transceivers, transmitters, receivers, storage devices, sensors, and other components capable of providing communication. Communication between vehicles 202 and 202' can be performed directly, via a private network and / or a public network (not shown), or via other vehicles and components including one or more processors, memory, and software. Processors 204 and 204' can also communicate with one or more components 230, including sensors 212, wired devices 214, wireless devices 216, databases 218, mobile phones 220, vehicles 222, computers 224, input / output (I / O) devices 226, and voice applications 228. Processors 204, 204' can also communicate with one or more of the following components: processor, memory, and software.

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

[0082] Figure 2C Another vehicle network diagram 240 according to an example embodiment is shown. The network includes elements including a vehicle 202, a processor 204, and a non-transitory computer-readable medium 242C. The processor 204 is communicatively coupled to the computer-readable medium 242C and element 230 (which is in...). Figure 2B (As depicted in the image). Vehicle 202 can be a vehicle, a server, or any device with a processor and memory.

[0083] The processor 204 performs one or more of the following operations: in 244C, it queries the vehicle's computer via a charging station, wherein the query includes receiving attributes of the vehicle's rechargeable battery from the computer; in 246C, it determines the total charging time of the rechargeable battery based on the attributes of the rechargeable battery and the attributes of the charging station; in 248C, it selects media content from a plurality of media content based on the determined total charging time of the rechargeable battery; and in 250C, it outputs the media content via the charging station.

[0084] Figure 2D Another vehicle network diagram 250 according to an example embodiment is shown. The network includes elements including a vehicle 202, a processor 204, and a non-transitory computer-readable medium 242D. The processor 204 is communicatively coupled to the computer-readable medium 242D and element 230 (which is in...). Figure 2B (As depicted in the image). Vehicle 202 can be a vehicle, a server, or any device with a processor and memory.

[0085] Processor 204 performs one or more of the following operations: In 244D, it queries the application programming interface (API) of the entertainment content distribution platform based on the value of the total charging time to select media content from multiple media content sources; In 245D, it determines the total charging time based on the type of rechargeable battery, the capacity of the rechargeable battery, the current state of charging of the rechargeable battery, and the availability of charging stations; In 246D, it determines the total charging time based on a battery power charging graph, wherein the battery power charging graph includes a first axis representing the charging power of the charging station and a second axis representing the state of charging of the rechargeable battery; In 247D, it selects media content to be selected based on the total charging time. The output includes playing a video file that has been played before the end of the charging time, and playing the video file via one or more of the user devices of the occupants in the vehicle and the display devices installed in the vehicle; in 248D, selecting a video file that includes an intermediate stop point, which will be played before the end of the total charging time; and the output includes playing the video file via the user interface of the charging station until the intermediate stop point; and in 249D, selecting a first media file and a second media file based on the total charging time of the rechargeable battery, and the output includes playing the first media file on a first display device in the vehicle and playing the second media file on a second display device in the vehicle.

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

[0087] Processor 204 performs one or more of the following operations: receiving confirmation of an event from one or more elements described or depicted herein, wherein the confirmation includes blockchain consensus among peers represented by any element; and executing a smart contract to record the confirmation on the blockchain consensus. Consensus is formed between any element 230 and / or one or more of any elements described or depicted herein, including vehicles, servers, wireless devices, etc. In another example, vehicle 202 may be any element 230 and / or one or more of any elements described or depicted herein, including servers, wireless devices, etc.

[0088] The processor and / or computer-readable medium may reside wholly or partially inside or outside the vehicle. Steps or features stored in the computer-readable medium may be executed wholly or partially by any processor and / or element in any order. Furthermore, one or more steps or features may be added, omitted, combined, or executed later.

[0089] Figure 2E A flowchart 260 according to an example embodiment is shown. (Reference) Figure 2E This solution includes one or more of the following operations: in 262E, querying the vehicle's computer via a charging station, wherein the query includes receiving the attributes of the vehicle's rechargeable battery from the computer; in 264E, determining the total charging time of the rechargeable battery based on the attributes of the rechargeable battery and the attributes of the charging station; in 266E, selecting media content from multiple media content based on the determined total charging time of the rechargeable battery; and in 268E, outputting the media content via the charging station.

[0090] Figure 2F Another flowchart 270 according to an example embodiment is shown. (Reference) Figure 2F This solution includes one or more of the following operations: In 271F, querying the application programming interface (API) of the entertainment content distribution platform based on the total charging time value to select media content from multiple media content sources; In 272F, determining the total charging time based on the type of rechargeable battery, the capacity of the rechargeable battery, the current state of charge of the rechargeable battery, and the availability of the charging station; In 273F, determining the total charging time based on a battery power charging graph, wherein the battery power charging graph includes a first axis representing the charging power of the charging station and a second axis representing the state of charge of the rechargeable battery; In 274F, selecting the content to be charged based on the total charging time. The output includes playing a video file that has been played before the end of the charging time, and playing the video file via one or more of the user devices of the occupants in the vehicle and the display devices installed in the vehicle; in 275F, selecting a video file that includes an intermediate stop point, which will be played before the end of the total charging time; and playing the video file via the user interface of the charging station until the intermediate stop point; and in 276F, selecting a first media file and a second media file based on the total charging time of the rechargeable battery, and playing the first media file on a first display device in the vehicle and playing the second media file on a second display device in the vehicle.

[0091] Technological advancements typically build upon predecessor technologies; this is the case with artificial intelligence (AI) models. AI classification systems describe the stages of AI development. The first category is called "reactive machines," followed by today's AI classification, "machines with limited memory" (also known as "artificial narrow intelligence"), then progressing to "theory of mind" (also known as "artificial general intelligence"), and finally reaching the AI ​​classification "self-awareness" (also known as "artificial superintelligence"). Today's machines with limited memory are an ever-growing set of AI models built upon their predecessor, "reactive machines." Reactive machines simulate human responses to stimuli; however, they are limited in their capabilities because they typically cannot learn from prior experience. Once the learning ability of AI models emerged, their classification was elevated to machines with limited memory. In this current classification, AI models learn from vast amounts of data, detect patterns, solve problems, generate and predict data, and so on, while inheriting all the capabilities of reactive machines. Examples of AI models classified as machines with limited memory include, but are not limited to, chatbots, virtual assistants, machine learning (ML), deep learning (DL), natural language processing (NLP), generative AI (GenAI) models, and any future AI models still under development that possess characteristics of machines with limited memory. Generative AI models combine machine-with-limited-memory technologies, merging ML and DL, to form the foundational building blocks of future AI models. For example, theory of mind, the next advance in AI, is able to perceive, connect, and react by generating appropriate responses in response to entities with which the AI ​​model interacts; all these capabilities rely on the foundations of generative AI. Furthermore, in the evolution towards a self-awareness classification, AI models will be able to understand and evoke emotions in the entities they interact with, and possess their own emotions, beliefs, and needs—all of which rely on the foundations of generative AI learned from experience to generate and draw conclusions about themselves and their surroundings. Generative AI models are an integral and core component of future artificial intelligence models. As discussed in this paper, generative AI refers to both current and future generative AI models.

[0092] Figure 3A An AI / ML network diagram 300A supporting AI-assisted vehicle or occupant decision points is shown. Other branches of AI (such as, but not limited to, computer vision, fuzzy logic, expert systems, neural networks / deep learning, generative AI, and natural language processing) can be used when developing the AI ​​models shown in these embodiments. Furthermore, the AI ​​models included in these embodiments are not limited to specific AI algorithms. Any algorithm or combination of algorithms related to supervised, unsupervised, and reinforcement learning can be employed.

[0093] In one embodiment, generative AI (GenAI) can be used by this solution in data transformation. Vehicles are equipped with various sensors, cameras, radars, and LIDARs, which collect large amounts of data, such as images, speed readings, GPS data, and acceleration measurements. However, once the raw data is acquired, it undergoes preprocessing, which may involve normalization, anonymization, missing value imputation, or noise reduction to allow for further effective use of the data.

[0094] Following data preprocessing, GenAI performs data augmentation. Due to the limitations of the dataset in capturing the immense complexity of real-world vehicle scenes, augmentation tools are employed to expand the dataset. This may involve image-specific transformations such as rotation, translation, or brightness adjustment. For non-image data, techniques like dithering can be used to introduce synthetic noise, thereby simulating a broader set of conditions.

[0095] In this solution, data generation is then performed on the data. Tools such as Generative Adversarial Networks (GANs) and Variational Autoencoders (VAEs) are trained on existing datasets to generate new, plausible data samples. For example, a GAN might be assigned the task of creating images of a vehicle under unclassified conditions or from unique perspectives. As another example, sensor data synthesis can be performed to model such scenarios and create synthetic readouts, enabling comprehensive system testing without actual physical encounters. Given the safety-critical nature of vehicles, a key step in using GenAI is validation. This validation can include comparing the output data to real-world datasets or using specialized tools like GAN discriminators to measure the plausibility of the generated samples.

[0096] Vehicle node 310 may include multiple sensors 312, which may include, but are not limited to, light sensors, weight sensors, cameras, LiDAR, and radar. In some embodiments, these sensors 312 send data to a database 320 that stores data about the vehicle and its occupants. In some embodiments, these sensors 312 send data to one or more decision subsystems 316 within vehicle node 310 to assist in decision-making.

[0097] Vehicle node 310 may include one or more user interfaces (UIs) 314, such as a steering wheel, navigation controls, audio / video controls, temperature controls, etc. In some embodiments, these UIs 314 send data to a database 320 that stores event data about the UIs 314, including but not limited to selection, status, and display data. In some embodiments, these UIs 314 send data to one or more decision subsystems 316 in vehicle node 310 to assist in decision-making.

[0098] Vehicle node 310 may include one or more decision subsystems 316 that drive the decision-making process, including but not limited to vehicle control, temperature control, and charging control. In some embodiments, decision subsystem 316 collects data from one or more sensors 312 to assist the decision-making process. In some embodiments, decision subsystem 316 may collect data from one or more UIs 314 to aid the decision-making process. In some embodiments, decision subsystem 316 may provide feedback to UI 314.

[0099] The AI / ML production system 330 can be used by the decision subsystem 316 in the vehicle node 310 to assist in its decision-making process. The AI / ML production system 330 includes one or more AI / ML models 332, which are executed to retrieve required data, such as, but not limited to, prediction, classification, UI cues, etc. In some embodiments, the AI / ML production system 330 is hosted on a server. In some embodiments, the AI / ML production system 330 is cloud-hosted. In some embodiments, the AI / ML production system 330 is deployed in a distributed multi-node architecture. In some embodiments, the AI / ML production system resides in the vehicle node 310.

[0100] AI / ML development system 340 creates one or more AI / ML models 332. In some embodiments, AI / ML development system 340 utilizes data in database 320 to develop and train one or more AI models 332. In some embodiments, AI / ML development system 340 utilizes feedback data from one or more AI / ML production systems 330 to develop new models and / or retrain existing models. In one embodiment, AI / ML development system 340 resides on a server and executes on the server. In another embodiment, AI / ML development system 340 is cloud-hosted. In a further embodiment, AI / ML development system 340 utilizes a distributed data pipeline / analysis engine.

[0101] Once the AI / ML model 332 has been trained and validated in the AI / ML development system 340, it can be stored in the AI / ML model registry 360 for retrieval by the AI / ML development system 340 or by one or more AI / ML production systems 330. In one embodiment, the AI / ML model registry 360 resides on a dedicated server. In some embodiments, the AI / ML model registry 360 is cloud-hosted. In other embodiments, the AI / ML model registry 360 is a distributed database. In a further embodiment, the AI / ML model registry 360 resides in the AI / ML production system 330.

[0102] Figure 3B A process 300B for developing one or more AI / ML models to support AI-assisted vehicle or occupant decision points is illustrated. An AI / ML development system 340 performs steps 332 to develop the AI / ML model, beginning with data extraction 342, where data is loaded and ingested from one or more data sources. In some embodiments, vehicle and user data are extracted from a database 320. In some embodiments, model feedback data is extracted from one or more AI / ML production systems 330.

[0103] Once the required data 342 has been extracted, it must be prepared 344 for model training. In some embodiments, this step involves statistical testing of the data to examine its degree of reflection of real-world events, its distribution, the diversity of data in the dataset, etc. In some embodiments, the results of this statistical test may lead to one or more data transformations being used to normalize one or more values ​​in the dataset. In some embodiments, this step includes removing data considered noisy. Noisy datasets include values ​​that do not contribute to training, such as, but not limited to, null values ​​and long string values. Data preparation 344 can be an automated or manual process using one or more elements or functions described or depicted herein.

[0104] Features 346 are identified and extracted from the data. In some embodiments, the features of the data are internal to the prepared data from step 344. In other embodiments, the features of the data require that the prepared data fragments from step 344 be enriched with data from another data source to be useful in developing the AI / ML model 332. In some embodiments, feature identification is an automated or manual process using one or more elements or functions described or depicted herein. Once the features are identified, the values ​​of the features are collected into a dataset that will be used to develop the AI / ML model 332.

[0105] The dataset output from feature extraction step 346 is split into training and validation datasets. The training dataset is used to train the AI / ML model 332, and the validation dataset is used to evaluate the performance of the AI / ML model 332 on unseen data.

[0106] The AI / ML model 332 is trained and tuned 350 using the training dataset from data segmentation step 348. In this step, the training dataset is fed into the AI / ML algorithm and an initial set of algorithm parameters. Then, the performance of the AI / ML model 332 is tested within the AI / ML development system 340 using the validation dataset from step 348. These steps can be repeated with adjustments to one or more algorithm parameters until the model's performance is acceptable based on various objectives and / or results.

[0107] The AI / ML model 332 is evaluated 352 in a hierarchical environment (not shown) similar to the final AI / ML production system 330. This evaluation uses a validation dataset to ensure that performance in the AI / ML production system 330 matches or exceeds expectations. In some embodiments, the validation dataset from step 348 is used. In other embodiments, one or more unknown validation datasets are used. In some embodiments, the hierarchical environment is part of the AI / ML development system 340. In other embodiments, the hierarchical environment is managed separately from the AI / ML development system 340. Once the AI / ML model 332 has been validated, it is stored in an AI / ML model registry 360, which can be retrieved for deployment and future updates. As previously described, in some embodiments, the model evaluation step 352 is an automated or manual process using one or more elements or functions described or depicted herein.

[0108] Once the AI / ML model 332 has been validated and published to the AI / ML model registry 360, it can be deployed 354 to one or more AI / ML production systems 330. In some embodiments, the performance of the deployed AI / ML model 332 is monitored 356 by the AI / ML development system 340. In some embodiments, feedback data for the AI / ML model 332 is provided by the AI / ML production system 330 to enable model performance monitoring 356. In some embodiments, the AI / ML development system 340 periodically requests feedback data for model performance monitoring 356. In some embodiments, model performance monitoring includes one or more triggers that cause the AI / ML model 332 to be updated by repeating steps 342-354 using updated data from one or more data sources.

[0109] Figure 3CA process 300C for utilizing an AI / ML model that supports AI-assisted vehicle or occupant decision points is illustrated. As previously stated, the AI ​​model utilization process depicted herein reflects ML, a specific branch of AI; however, this solution is not limited to ML, nor to any AI algorithm or combination of algorithms.

[0110] refer to Figure 3C The AI / ML production system 330 can be used by the decision subsystem 316 in vehicle node 310 to assist in its decision-making process. The AI / ML production system 330 provides an application programming interface (API) 334 executed by the AI / ML server process 336, through which requests can be made. In some embodiments, a request may include an identifier of an AI / ML model 332 to be executed. In some embodiments, the AI / ML model 332 to be executed is implicit based on the type of request. In some embodiments, a data payload (e.g., input to the model during execution) is included in the request. In some embodiments, the data payload includes sensor 312 data from vehicle node 310. In some embodiments, the data payload includes UI 314 data from vehicle node 310. In some embodiments, the data payload includes data from other vehicle node 310 subsystems (not shown), including but not limited to the occupant data subsystem. In embodiments, one or more elements or nodes 320, 330, 340, or 360 may be located within vehicle 310.

[0111] Upon receiving API 334, AI / ML server process 336 may need to transform the data payload or a portion thereof into valid feature values ​​in AI / ML model 332. Data transformation may include, but is not limited to, combining data values, normalizing data values, and enriching the incoming data with data from other data sources. Once any required data transformation has occurred, AI / ML server process 336 uses the transformed input data to execute the appropriate AI / ML model 332. Upon receiving the execution result, AI / ML server process 336 responds to the API caller, which is decision subsystem 316 of vehicle node 310. In some embodiments, the response may result in an update to UI 314 in vehicle node 310. In some embodiments, the response includes a request identifier, which may later be used by decision subsystem 316 to provide feedback on the performance of AI / ML model 332. Furthermore, in some embodiments, immediate performance feedback may be logged by AI / ML server process 336 to model feedback log 338. In some embodiments, failure to execute the model is the cause of the immediate feedback.

[0112] In some embodiments, API 334 includes an interface that provides feedback to AI / ML model 332 after the AI / ML model 332 execution response has been processed. This mechanism can be used to evaluate the performance of AI / ML model 332 by enabling the API caller to provide feedback on the accuracy of the model results. For example, this could be indicated if AI / ML model 332 provides an estimated arrival time of 20 minutes, but the actual travel time is 24 minutes. In some embodiments, the feedback interface includes an identifier of the initial request, making it possible to associate feedback with the request. Upon receiving a call to the feedback interface of API 334, AI / ML server process 336 logs the feedback in model feedback log 338. In some embodiments, the data in model feedback log 338 is provided to model performance monitoring 356 in AI / ML development system 340. In one embodiment, the log data is streamed to AI / ML development system 340. In some embodiments, the log data is provided upon request.

[0113] Several decisions / steps of the AI / ML process described in this paper can be utilized, including: querying the vehicle's computer via a charging station, wherein the query includes receiving attributes of the vehicle's rechargeable battery from the computer; determining the total charging time of the rechargeable battery based on the attributes of the rechargeable battery and the attributes of the charging station; selecting media content from multiple media content based on the determined total charging time of the rechargeable battery; and outputting the media content via the charging station; querying the application programming interface (API) of an entertainment content distribution platform based on the value of the total charging time to select media content from multiple media content; determining the total charging time based on the type of rechargeable battery, the capacity of the rechargeable battery, the current state of charging of the rechargeable battery, and the availability of the charging station; and determining the total charging time based on the battery power charging map. The battery power charging graph includes a first axis representing the charging power of the charging station and a second axis representing the charging state of the rechargeable battery; selects a video file that will be played before the end of the total charging time, and outputs playback of the video file via one or more of a user device of an occupant in the vehicle and a display device installed in the vehicle; selects a video file including an intermediate stop point that will be played before the end of the total charging time; outputs playback of the video file via the user interface of the charging station until the intermediate stop point; and selects a first media file and a second media file based on the total charging time of the rechargeable battery, and outputs playback of the first media file on a first display device in the vehicle and playback of the second media file on a second display device in the vehicle.

[0114] With any of these steps / features and any other features or functions described or depicted herein, AI / ML production system 330 and Figure 3CData associated with one or more of the other elements depicted herein may be used to process the data during the pre-conversion and / or post-conversion process. Data related to this process may be used by vehicle node 310. In one embodiment, data related to this process may be used with a charging station / charging point, server, wireless device, and / or any processor described or depicted herein.

[0115] Figure 3D A process 300D for designing a new machine learning model via a system user interface 370, according to an example embodiment, is illustrated. As an example, the model can be output as part of an AI / ML development system 340. References Figure 3D Users can use the input mechanism from the menu 372 of the user interface 370 to add parts / assemblies to the model developed in the workspace 374 of the user interface 370.

[0116] Menu 372 includes several graphical user interface (GUI) menu options that can be selected to display additional components that can be added to the model design shown in workspace 374. The GUI menu includes options for adding elements to the workspace, such as features that can include neural networks, machine learning models, AI models, data sources, transformation processes (e.g., vectorization, encoding, etc.), analytics, etc. Users can continue adding features to the model and connect them using edges or other methods to create flows within workspace 374. For example, a user can add node 376 to the flow of a new model within workspace 374. For instance, a user can connect node 376 to another node in the graph via edge 378, thereby creating dependencies in the graph. When the user is finished, they can save the model for subsequent training / testing.

[0117] In another example, the name of the object can be identified from a webpage or user interface 370, where the object is visible within a browser or workspace 374 on the user's device. Pop-ups within the browser or workspace 374 can be overlaid where the object is visible; this includes options to navigate via a ruleset to the identified webpage corresponding to the alternative object.

[0118] Figure 3EA process 300E is illustrated for accessing object 392 from object storage device 390 of host platform 380 according to an example embodiment. For example, object storage device 390 may store data used by AI models and machine learning (ML) models, training data, expected outputs for testing, training results, etc. Object storage device 390 may also store any other types of data. Each object may include a unique identifier, a data portion 394, and a metadata portion 396, which provide a descriptive context associated with the data, including data that can be extracted later for machine learning purposes. The unique identifier can uniquely identify the object relative to all other objects in object storage device 390. Data portion 394 may include unstructured data such as web pages, digital content, images, audio, text, etc.

[0119] Object storage device 390 treats objects as discrete units of data stored in a flattened data environment, rather than breaking down files into blocks on a disk stored in a file system. Here, object storage may not use folders, directories, or complex hierarchical structures. Instead, each object can be a simple, self-contained repository comprising data, metadata, and a unique identifier that client applications can use to locate and access it. In this case, metadata is more descriptive than a file-based approach. Metadata can be customized with additional context, which can later be extracted and used for other purposes, such as data analysis.

[0120] Objects stored in object storage device 390 can be accessed via API 384. API 384 can be a RESTful API (also known as a RESTful web service) based on the Hypertext Transfer Protocol (HTTP). API 384 can be used by client applications to query the metadata of objects in order to locate the desired object (data) from anywhere on any device via the Internet. API 384 can use HTTP commands, such as using "PUT" or "POST" to upload objects, using "GET" to retrieve objects, and using "DELETE" to remove objects.

[0121] Object storage device 390 may provide a directory 398 that uses object metadata to locate the appropriate data file. Directory 398 may contain descriptive information about each object stored in object storage device 390, such as name, unique identifier, creation timestamp, collection name, etc. To query objects within object storage device 390, client applications may submit commands, such as HTTP commands, containing the identifier of object 392, payload, etc. Object storage device 390 may store the actions and results described herein, including associating two or more ranked asset lists with each other based on variables used by two or more ranked asset lists having a correlation higher than a predetermined threshold.

[0122] Figure 4A Figure 400A illustrates the electrification of one or more components. In one example, vehicle 402B can supply power stored in its battery to one or more components, including one or more other vehicles 408B, one or more charging stations 406B, and one or more power grids 404B. One or more power grids 404B are coupled to one or more charging stations 406B, which can be coupled to one or more vehicles 408B. This configuration allows for the distribution of power / electricity received from vehicle 402B. Vehicle 402B can also interact with one or more other vehicles 408B, such as via V2V technology, cellular, WiFi communication, etc. Vehicle 402B can also interact wirelessly and / or wiredly with other vehicles 408B, one or more charging stations 406B, and / or one or more power grids 404B. In one example, vehicle 402B is routed (or routes itself) to one or more power grids 404B, one or more charging stations 406B, or one or more other vehicles 408B in a secure and efficient manner. Using one or more embodiments of this solution, vehicle 402B can supply energy to one or more elements depicted herein in various advantageous manners as described and / or illustrated herein. Furthermore, vehicle safety and efficiency can be increased, and the environment can be positively impacted as described and / or illustrated herein.

[0123] The terms “energy,” “electricity,” “power,” etc., can be used to refer to any form of energy received, stored, used, shared, and / or lost by one or more vehicles. During charging / use operations, energy can refer to a combination of a voltage source and / or a current source of charge supplied from an entity to one or more vehicles. Energy can also be in the form of fossil fuels (e.g., for use with hybrid vehicles) or via alternative energy sources, including but not limited to lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, fusion-based energy, and energy generated during energy sharing and / or use operations to increase or decrease the energy level of one or more vehicles at a given time.

[0124] In one example, charging station 406B manages the amount of energy transferred from vehicle 402B such that vehicle 402B has sufficient charge remaining to reach its destination. In one example, a wireless connection is used to wirelessly guide the amount of energy transferred between vehicles 408B, where all vehicles may be in motion. In one embodiment, wireless charging may be performed via a fixed charger aligned with each other and the vehicle's battery (such as a charging pad in a garage or parking space). In one example, an idle vehicle, such as vehicle 402B (which may be autonomous), is guided to provide a certain amount of energy to charging station 406B and return to its original location (e.g., its original location or a different destination). In one example, a mobile energy storage unit (not shown) is used to collect excess energy from at least one other vehicle 408B and transfer the stored excess energy at charging station 406B. In one example, factors determine the amount of energy to be transferred to charging station 406B, such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle condition (weight, etc.), occupant schedules (one or more) while the vehicle is in use, expected occupant schedules (one or more) while waiting for the vehicle, etc. In one example, one or more vehicles 408B, one or more charging stations 406B, and / or one or more power grids 404B can provide energy to vehicle 402B.

[0125] In one embodiment, a location such as a building, residence, etc. (not shown) is communicatively coupled to one or more of a power grid 404B, a vehicle 402B, and / or a charging station 406B. The current rate to one or more of the location, vehicle 402B, and other vehicles 408B is modified based on external conditions such as weather. For example, when the outside temperature is very hot or very cold, increasing the chance of a power outage, the current to the connected vehicles 402B / 408B is slowed down to help minimize the chance of a power outage.

[0126] In one embodiment, vehicles 402B and 408B can be used as bidirectional vehicles. Bidirectional vehicles are those that can be used as mobile microgrids, which can help supply power to and / or reduce power consumption of the grid 404B when the grid is under strain. Bidirectional vehicles incorporate bidirectional charging, which, in addition to receiving charge into the vehicle, also allows the vehicle to transfer energy from the vehicle to the grid 404B, a process also referred to as “V2G”. In bidirectional charging, power flows bidirectionally to and from the vehicle. When the vehicle is charging, alternating current (AC) from the grid 404B is converted to direct current (DC). This can be done by one or more of a converter on the vehicle itself or on the charging station 406B. Energy stored in the vehicle's battery can be sent back to the grid in the opposite direction. Energy is converted from DC to AC by a converter typically located in the charging station 406B, also referred to as a bidirectional charger. Furthermore, as per [reference to...] Figure 4B The solution described and depicted here can be used in this and other networks and / or systems.

[0127] Figure 4BFigure 400B illustrates the interconnections between different components. This solution can be fully or partially stored and / or executed on and by one or more computing devices 414C, 418C, 424C, 428C, 432C, 436C, 406C, 442C, and 410C associated with various entities, all communicatively coupled to and communicating with network 402C. Database 438C is communicatively coupled to the network and allows for the storage and retrieval of data. In one example, the database is an immutable ledger. One or more of the various entities can be vehicles 404C, one or more service providers 416C, one or more public buildings 422C, one or more transportation infrastructures 426C, one or more residential buildings 430C, a power grid / charging station 434C, a microphone 440C, and / or another vehicle 408C. Other entities and / or devices (such as one or more private users using smartphones 412C, laptops 420C, augmented reality (AR) devices, virtual reality (VR) devices, and / or any wearable devices) can also interact with this solution. Smartphones 412C, laptops 420C, microphones 440C, and other devices can connect to one or more of the connected computing devices 414C, 418C, 424C, 428C, 432C, 436C, 406C, 442C, and 410C. One or more public buildings 422C may include various institutions. One or more public buildings 422C may utilize computing device 424C. One or more service providers 416C may include dealerships, towing services, collision centers, or other repair shops. One or more service providers 416C may utilize computing device 418C. These various computing devices can be directly and / or communicatively coupled to each other, such as via wired networks, wireless networks, blockchain networks, etc. In one example, microphone 440C can be used as a virtual assistant. In one example, one or more traffic infrastructure 426C may include one or more traffic signals, one or more sensors including one or more cameras, vehicle speed sensors or traffic sensors, and / or other traffic infrastructure. One or more traffic infrastructure 426C may utilize computing device 428C.

[0128] In one embodiment, at any time that a charge is supplied to or received from a charging station and / or the power grid, the entities that allow this to happen are one or more of the vehicle, the charging station, the server, and the network communicatively coupled to the vehicle, the charging station, and the power grid.

[0129] In one example, vehicle 408C / 404C can transport people, objects, permanent or temporary fixtures, etc. In one example, vehicle 408C can communicate with vehicle 404C via V2V communication through a computer associated with each vehicle 406C and 410C, and can be referred to as an automobile, vehicle, motor vehicle, etc. Vehicle 404C / 408C can be a self-propelled wheeled vehicle, such as an automobile, SUV, truck, bus, van, or other electric motor or battery-powered or fuel cell-powered vehicle. For example, vehicle 404C / 408C can be an electric vehicle, a hybrid vehicle, a hydrogen fuel cell vehicle, a plug-in hybrid vehicle, or any other type of vehicle with a fuel cell stack, motor, and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, boats, and any other form of transportation capable of carrying out transport. Vehicle 404C / 408C can be semi-autonomous or autonomous. For example, vehicle 404C / 408C can be self-motorized and navigate without human input. Autonomous vehicles can have and use one or more sensors and / or navigation units to drive autonomously. All data described or depicted herein can be obtained from… Figure 4B One or more components are used to store, analyze, process, and / or forward data.

[0130] Figure 4C This is another block diagram 400C illustrating the interconnections between different components in one example. A vehicle 412D is presented, and includes ECUs 410D, 408D, and a host unit (also referred to as an infotainment system) 406D. An ECU is an embedded system in automotive electronics that controls one or more of the vehicle's electrical systems or subsystems. An ECU may include, but is not limited to, management of the vehicle's engine, braking system, transmission system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECU is connected to the vehicle's Controller Area Network (CAN) bus 416D. The ECU can also communicate with the vehicle computer 404D via the CAN bus 416D. The vehicle's processors / sensors (such as the vehicle computer) 404D can communicate with external components (such as a server 418D) via a network 402D (such as the Internet). Each ECU 410D, 408D, and host unit 406D may contain its own security policy. The security policy defines the permissible processes that can be executed in the appropriate context. In one example, the security policy may be provided in part or in part in the vehicle computer 404D.

[0131] ECUs 410D, 408D, and the host unit 406D may each include a custom safety function element 414D that defines authorized processes and the contexts in which these processes are allowed to run. Context-based authorization, which determines the validity of a process's execution, allows the ECU to maintain safe operation and prevents unauthorized access from components such as the vehicle's CAN bus. When the ECU encounters an unauthorized process, it can block that process from operating. The vehicle ECU can use various contexts to determine whether a process is operating within its permitted scope, such as proximity contexts (nearby objects, distance to an approaching object, speed, and trajectory relative to other moving objects), operational contexts (such as indications of whether the vehicle is moving or stopped, the vehicle's current speed, and transmission status), user-related contexts (such as devices connected to the vehicle via wireless protocols, infotainment use, cruise control, parking assistance, and driver assistance), location-based contexts, and / or other contexts.

[0132] refer to Figure 4D The diagram illustrates an operating environment 400D for a connected vehicle according to some embodiments. As depicted, the vehicle 410E includes a CAN bus 408E connecting vehicle components 412E-426E. Other components may be connected to the CAN bus and are not depicted herein. The depicted components connected to the CAN bus include a sensor group 412E, an electronic control unit 414E, an autonomous feature or advanced driver assistance system (ADAS) 416E, and a navigation system 418E. In some embodiments, the vehicle 410E includes a processor 420E, a memory 422E, a communication unit 424E, and an electronic display 426E.

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

[0134] Memory 422E is a non-transitory memory that stores instructions or data that can be accessed and executed by processor 420E. Instructions and / or data may include code for performing the techniques described herein. Memory 422E 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 422E may also include non-volatile memory or similar permanent storage devices and media, which may include hard disk drives, floppy disk drives, compact disc read-only memory (CD-ROM) devices, digital versatile disc read-only memory (DVD-ROM) devices, digital versatile disc random access memory (DVD-RAM) devices, digital versatile disc rewritable (DVD-RW) devices, flash memory devices, or some other high-capacity storage device for storing information on a permanent basis. A portion of memory 422E may be reserved for use as a buffer or virtual random access memory (virtual RAM). Without departing from the present solution, vehicle 410E may include one or more memories 422E.

[0135] The memory 422E of vehicle 410E may store one or more of the following types of data: navigation route data 418E and autonomous characteristic data 416E. In some embodiments, memory 422E stores data that may be required by navigation application 418E to provide functionality.

[0136] Navigation system 418E can describe at least one navigation route including a start point and an end point. In some embodiments, navigation system 418E of vehicle 410E receives a request for a navigation route from a user, wherein the request includes a start point and an end point. Navigation system 418E can query navigation route data corresponding to the navigation route, including the start point and end point, from real-time data server 404E (such as a server providing driving guidance) via network 402E. Real-time data server 404E transmits navigation route data to vehicle 410E via wireless network 402E, and communication system 424E stores navigation data 418E in memory 422E of vehicle 410E.

[0137] ECU 414E controls the operation of many systems in vehicle 410E, including ADAS system 416E. ECU 414E can, in response to instructions received from navigation system 418E, deactivate any unsafe and / or unselected autonomous features during the duration of a journey controlled by ADAS system 416E. In this way, navigation system 418E can control whether ADAS system 416E is activated or enabled so that it can be activated for a given navigation route.

[0138] Sensor group 412E may include any sensor in vehicle 410E that generates sensor data. For example, sensor group 412E may include short-range sensors and long-range sensors. In some embodiments, sensor group 412E of vehicle 410E may include one or more of the following vehicle sensors: camera, light detection and ranging (Lidar) sensor, ultrasonic sensor, motor vehicle engine sensor, radar sensor, laser altimeter, manifold absolute pressure sensor, infrared detector, motion detector, thermostat, sound detector, carbon monoxide sensor, carbon dioxide sensor, oxygen sensor, mass airflow sensor, engine coolant temperature sensor, throttle position sensor, crankshaft position sensor, valve timer, air-fuel ratio meter, blind spot meter, curb detector, defect detector, Hall effect sensor, parking sensor, radar gun, speedometer, speed sensor, tire pressure monitoring sensor, torque sensor, transmission fluid temperature sensor, turbine speed sensor (TSS), variable magnetoresistive sensor, vehicle speed sensor (VSS), water sensor, wheel speed sensor, global positioning system (GPS) sensor, mapping function, and any other type of motor vehicle sensor. Navigation system 418E may store sensor data in memory 422E.

[0139] Communication unit 424E transmits and receives data to and from network 402E or another communication channel. In some embodiments, communication unit 424E may include a dedicated short-range communication (DSRC) transceiver, a DSRC receiver, and other hardware or software required to make vehicle 410E a DSRC-equipped device.

[0140] Vehicle 410E can interact with other vehicles 406E via V2V technology. In one example, V2V communication includes sensing radar information corresponding to the relative distance to external objects, receiving GPS information of the vehicle, setting an area based on the sensed radar information as the area where other vehicles 406E are located, calculating the probability that the GPS information of the target vehicle will be located in the set area, and identifying the vehicle and / or object corresponding to the radar information and GPS information of the target vehicle based on the calculated probability.

[0141] For a vehicle to be sufficiently secure, it must be protected from both unauthorized physical and remote access (e.g., cyber threats). To prevent unauthorized physical access, in one example, the vehicle is equipped with a secure access system, such as keyless entry. Simultaneously, in another example, security protocols are added to the vehicle's computers and computer networks to facilitate secure remote communication to and from the vehicle.

[0142] An ECU (Electronic Control Unit) is a node within a vehicle that controls everything from tasks such as activating windshield wipers to systems like anti-lock braking systems (ABS). ECUs are typically interconnected via a central network, often referred to as a Controller Area Network (CAN). State-of-the-art features, such as autonomous driving, heavily rely on new, sophisticated ECUs, along with ADAS (Advanced Driver Assistance Systems) and sensors. While these new technologies have helped improve vehicle safety and the driving experience, they have also increased the number of external communication units within the vehicle, making them more vulnerable to attack. Below are some examples of protecting vehicles from physical and remote intrusion.

[0143] In one embodiment, CAN includes a CAN bus with high-side and low-side terminals and multiple ECUs connected to the CAN bus via wired connections. The CAN bus is designed to allow microcontrollers and devices to communicate with each other in applications without a host computer. The CAN bus implements a message-based protocol (i.e., the ISO 11898 standard), which allows ECUs to send commands to each other at the root level. Meanwhile, an ECU represents a controller used to control electrical systems or subsystems within a vehicle. Examples of electrical systems include power steering, anti-lock braking, air conditioning, tire pressure monitoring, cruise control, and many other features.

[0144] In this example, the ECU includes a transceiver and a microcontroller. The transceiver can be used to send messages to and receive messages from the CAN bus. For example, the transceiver can convert data from the microcontroller into the CAN bus format, and vice versa. Meanwhile, in one example, the microcontroller interprets the messages and also uses the ECU software installed therein to determine which messages to send.

[0145] To protect the CAN bus from network threats, various security protocols can be implemented. For example, subnets (such as subnets A and B) can be used to divide the CAN bus into smaller sub-CANs and restrict an attacker's ability to remotely access the vehicle. In one embodiment, a firewall (or gateway, etc.) can be added to block messages from crossing the subnets across the CAN bus. If an attacker gains access to one subnet, the attacker will not have access to the entire network. To make the subnets even more secure, in one example, the most critical ECUs are not placed on the same subnet.

[0146] In addition to protecting the vehicle's internal network, the vehicle can also be protected when communicating with external networks such as the Internet. One of the benefits of having vehicle connectivity to data sources such as the Internet is that information from the vehicle can be transmitted over the network to remote locations for analysis. Examples of vehicle information include GPS, on-board diagnostics, tire pressure, etc. These communication systems are often referred to as telematics because they involve a combination of telecommunications and computer science. Furthermore, the solution described and depicted herein can be used in this and other networks and / or systems, including those described and depicted herein.

[0147] Figure 4E Example 400E of vehicles 402I and 408I performing secure V2V communication using a security certificate according to an example embodiment is shown. Reference Figure 4E Vehicles 402I and 408I can communicate over short-range networks, cellular networks, etc., via V2V communication. Before sending a message, vehicles 402I and 408I can sign the message using the corresponding public key certificate. For example, vehicle 402I can sign a V2V message using public key certificate 404I. Similarly, vehicle 408I can sign a V2V message using public key certificate 410I. In one example, public key certificates 404I and 410I are associated with vehicles 402I and 408I, respectively.

[0148] Upon receiving communication from each other, vehicles can verify the signature with a Certificate Authority (CA) such as 406I. For example, vehicle 408I can verify with CA 406I that the public key certificate 404I used by vehicle 402I to sign V2V communication is authentic. If vehicle 408I successfully verifies public key certificate 404I, the vehicle knows the data comes from a legitimate source. Similarly, vehicle 402I can verify with CA 406I that the public key certificate 410I used by vehicle 408I to sign V2V communication is authentic. Furthermore, as per [the relevant documentation]... Figure 4E The solution described and depicted herein can be used in this and other networks and / or systems, including those described and depicted herein.

[0149] In some embodiments, the computer may include a security processor. Specifically, the security processor can perform authorization, authentication, and cryptographic (e.g., encryption) on data transmissions between ECUs and other devices on the vehicle's CAN bus, as well as on data messages transmitted between different vehicles. The security processor may include an authorization module, an authentication module, and an encryption module. The security processor can be implemented within the vehicle's computer and can communicate with other vehicle components, such as the ECU / CAN network, wired and wireless devices such as wireless network interfaces, input ports, etc. The security processor can ensure the security of data frames (e.g., CAN frames, etc.) transmitted internally within the vehicle (e.g., via the ECU / CAN network). Similarly, the security processor can ensure the security of messages transmitted between different vehicles and devices connected to or attached to the vehicle's computer via wires.

[0150] For example, the authorization module can store passwords, usernames, PIN codes, biometric scans, etc., for different vehicle users. The authorization module can determine whether a user (or technician) has permission to access certain settings, such as the vehicle's computer. In some embodiments, the authorization module can communicate with a network interface to download any necessary authorization information from an external server. When a user wishes to change vehicle settings or modify technical details via the in-vehicle console or GUI or via attached / connected devices, the authorization module can require the user to authenticate themselves in some way before making such changes. For example, the authorization module can request a username, password, PIN code, biometric scan, predetermined line drawing, or gesture, etc. In response, the authorization module can determine whether the user has the requested necessary permission (access, etc.).

[0151] The authentication module can be used to authenticate internal communication between ECUs on a vehicle's CAN network. As an example, the authentication module can provide information for authenticating communication between ECUs. For instance, it can send a bit signature algorithm to the ECUs on the CAN network. The ECUs can use the 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. Whenever one of the ECUs generates a new CAN frame, the bit signature algorithm can dynamically change the position, number, etc., of the authentication bits. The authentication module can also provide a list of exempt ECUs (a security list) that do not require the use of authentication bits. The authentication module can communicate with a remote server to retrieve updates to the bit signature algorithm, etc.

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

[0153] Figure 5A An example vehicle configuration 500A for managing database transactions associated with a vehicle, according to an example embodiment, is shown. References Figure 5A When a specific vehicle 525 participates in a transaction (e.g., vehicle service, dealership transaction, delivery / pickup, transportation service, etc.), the vehicle can receive assets 510 and / or expel / transfer assets 512 according to the transaction. A vehicle processor 526 resides in the vehicle 525 and communicates with the database 530 and the transaction module 520. The transaction module 520 can record information such as assets, parties, credit, service description, date, time, location, results, notifications, and unexpected events. Transactions in the transaction module 520 can be copied to the database 530. The database 530 can be one of an SQL database, a relational database management system (RDBMS), a relational database, a non-relational database, a blockchain, or a distributed ledger, and can be located on the vehicle, outside the vehicle, directly accessible and / or accessed via a network, or accessible by the vehicle itself.

[0154] In one embodiment, when a vehicle has reached a state where it needs to share a service with another vehicle, it can engage with the other vehicle to perform various actions, such as sharing, transferring, and receiving service calls. For example, the vehicle may need battery charging and / or may have tire problems and may be on a route to pick up a package for delivery. A vehicle processor resides in the vehicle and there is communication between the vehicle processor, a first database, and a transaction module. The vehicle can notify another vehicle that it is in its network and operating on its blockchain member service. A vehicle processor resides in another vehicle and there is communication between the vehicle processor, a second database, the vehicle processor, and the transaction module. The other vehicle can then request to receive information from that vehicle and / or from a server (not shown) via wireless communication to perform a package pickup. Transactions are recorded in the transaction modules of both vehicles. Credit transferred from one vehicle to another, and the record of the transferred service, is recorded in the first database, assuming the blockchains are different from each other, or in the same blockchain used by all members. The first database can be one of the following: SQL database, RDBMS, relational database, non-relational database, blockchain, distributed ledger, and it can be on the vehicle, off the vehicle, directly accessible, and / or accessed via a network.

[0155] Figure 5B A blockchain architecture configuration 500B according to an example embodiment is shown. (Reference) Figure 5B Blockchain architecture 500B may include certain blockchain elements, such as a group of blockchain member nodes 502-505 as part of blockchain group 510. In one example embodiment, the permissioned blockchain is not accessible to all parties, but only to those members who are permitted to access the blockchain data. Blockchain nodes participate in multiple activities, such as the blockchain entry addition and verification process (consensus). One or more blockchain nodes may endorse entries based on an endorsement policy and may provide ordering services for all blockchain nodes. Blockchain nodes may initiate blockchain actions (such as authentication) and seek to write to the immutable blockchain ledger stored in the blockchain, a copy of which may also be stored on the underlying physical infrastructure.

[0156] When a transaction is received and approved by the consensus model defined by the member nodes, blockchain transaction 520 is stored in the computer's memory. The approved transaction 526 is stored in the current block of the blockchain and submitted to the blockchain via a commit process that includes hashing the data content of the transaction in the current block and referencing previous hashes from previous blocks. Within the blockchain, one or more smart contracts 530 may exist, defining the terms of the transaction protocol and actions included in the smart contract executable application code 532, such as registered recipients, vehicle characteristics, requests, permissions, sensor thresholds, etc. The code can be configured to identify whether a requesting entity is registered to receive vehicle services, what service characteristics they are authorized / requested to receive given their profile status, and whether their actions are monitored in subsequent events. For example, when a service event occurs and a user is in the vehicle, sensor data monitoring can be triggered, and specific parameters such as the vehicle's charging level can be identified as being above / below a specific threshold within a specific time period. The result could then be a change in the current state, requiring an alert to be sent to management (i.e., the vehicle owner, vehicle operator, server, etc.) for identification and storage services to reference. The collected vehicle sensor data can be based on the type of sensor data used to collect information about the vehicle's state. Sensor data can also form the basis of vehicle event data 534, such as the location to be traveled, average speed, maximum speed, acceleration rate, whether there has been any collision, whether the expected route has been taken, what the next destination is, whether safety measures are in place, whether the vehicle has sufficient charge / fuel, etc. All such information can form the basis of smart contract terms 530, which are then stored in the blockchain. For example, sensor thresholds stored in the smart contract can be used as the basis for determining whether a detected service is needed and when and where the service should be performed.

[0157] In one embodiment, an example of blockchain logic includes a blockchain application programming interface (API), which serves as an API or plug-in application linked to computing devices and execution platforms for specific transactions. The blockchain configuration may include one or more applications linked to the API to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.), which can be created according to a customized configuration sought by the participants and can maintain its own state, control its own assets, and receive external information. This can be deployed as entries and installed on all blockchain nodes via attachment to the distributed ledger.

[0158] Smart contract application code provides the foundation for blockchain transactions by establishing application code that, when executed, makes the terms and conditions of the transaction valid. When executed, a smart contract generates certain approved transactions, which are then forwarded to the blockchain platform. This platform includes security / authorization, computing devices for managing transactions, and a storage component that serves as a repository for storing transactions and smart contracts within the blockchain.

[0159] A blockchain platform can include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and the underlying physical computing infrastructure. This infrastructure can be used to receive and store new entries and provide access to auditors seeking access to data entries. The blockchain can expose interfaces that provide access to the virtual execution environment required by the processor code and the participating physical infrastructure. Cryptographic trust services can be used to verify entries such as asset exchange entries while maintaining the privacy of information.

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

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

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

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

[0164] Figure 5C A blockchain configuration for storing blockchain transaction data is illustrated according to an example embodiment. (Reference) Figure 5C Example configuration 500C provides a vehicle 562, user equipment 564, and server 566 sharing information with a distributed ledger (i.e., blockchain) 568. The server can represent a service provider entity that, in the event that a known and established user profile attempts to rent a vehicle with an established rating profile, queries the vehicle service provider to share user profile rating information. Server 566 can receive and process data related to vehicle service requests. When service events occur, such as vehicle sensor data indicating a need for fuel / charging, maintenance services, etc., smart contracts can be used to invoke rules, thresholds, sensor information collection, etc., which can be used to invoke vehicle service events. Blockchain transaction data 570 is stored for each transaction, such as access events, subsequent updates to the vehicle service status, event updates, etc. A transaction may include the parties involved, requirements (e.g., 18 years of age, eligible candidates, valid driver's license, etc.), compensation level, distance traveled during the event, registered recipients who are allowed access to the event and host the vehicle service, permissions / permissions, sensor data retrieved during the vehicle event operation to record details of the next service event and identify the vehicle's condition status, and thresholds used to determine whether the service event has been completed and whether the vehicle's condition status has changed.

[0165] Figure 5D This illustrates blockchain blocks that can be added to a distributed ledger according to an example embodiment, as well as the contents of block structures 582A to 582n. (Reference) Figure 5D A client (not shown) can submit entries to a blockchain node to enact activity on the blockchain. As an example, the client could be an application acting on behalf of a requester (such as a device, person, or entity) to propose an entry for the blockchain. Multiple blockchain peers (e.g., blockchain nodes) can maintain the state of the blockchain network and copies of the distributed ledger. Different types of blockchain nodes / peers can exist in a blockchain network, including: endorser peers, which simulate and endorse entries proposed by clients; and submitting peers, which verify endorsements, validate entries, and submit entries to the distributed ledger. In this example, a blockchain node can act as an endorser node, a submitter node, or both.

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

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

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

[0169] The ordering service accepts endorsed entries, orders them into blocks, and delivers the blocks to committing peers. For example, the ordering service can initiate a new block when a threshold for entries is reached, a timer times out, or another condition is met. In this example, the blockchain nodes are committing peers that have already received data block 582A for storage on the blockchain. The ordering service can consist of a cluster of orderers. The ordering service does not handle entries, smart contracts, or maintain the shared ledger. Instead, it accepts endorsed 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 the specific implementation of "ordering" is a pluggable component.

[0170] Entries are written to the distributed ledger in a consistent order. This order ensures that entries are valid when updates to the state database are committed to the network. Unlike cryptocurrency blockchain systems that sort entries through solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger can choose the sorting mechanism best suited to the network.

[0171] refer to Figure 5DBlock 582A (also referred to as a data block) stored on the blockchain and / or distributed ledger may include multiple data segments, such as block headers 584A to 584n, transaction-specific data 586A to 586n, and block metadata 588A to 588n. It should be understood that the various blocks and their contents shown (such as block 582A and its contents) are for illustrative purposes only and are not intended to limit the scope of the illustrative embodiments. In some cases, both block header 584A and block metadata 588A may be smaller than the transaction-specific data 586A that stores entry data; however, this is not a requirement. Block 582A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 590A to 590n. Block 582A may also include links to (e.g., on the blockchain) previous blocks within its block header 584A. Specifically, block header 584A may include the hash of previous block headers. Block header 584A may also include a unique block number, the hash of block data 590A of the current block 582A, etc. The block number of block 582A can be unique and is assigned in an incremental / sequential order starting from zero. The first block in the blockchain can be called the genesis block, which includes information about the blockchain, its members, the data stored in it, etc.

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

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

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

[0175] Figure 5E The process 500E of adding a new block to the distributed ledger 520E according to an example embodiment is shown, and Figure 5D An example embodiment is shown. Figure 5E The content of 530E, a new data block structure for blockchain. (Reference) Figure 5EA client (not shown) can submit transactions to blockchain nodes 511E, 512E, and / or 513E. The client can be an instruction received from any source to formulate an activity on blockchain 522E. As an example, the client can be an application acting on behalf of a requester (such as a device, person, or entity) to propose a transaction for the blockchain. Multiple blockchain peers (e.g., blockchain nodes 511E, 512E, and 513E) can maintain the state of the blockchain network and a copy of the distributed ledger 520E. Different types of blockchain nodes / peers can exist in the blockchain network, including: endorser peers, which simulate and endorse transactions proposed by clients; and committing peers, which verify endorsements, validate transactions, and commit transactions to the distributed ledger 520E. In this example, blockchain nodes 511E, 512E, and 513E can perform the roles of endorser node, committer node, or both.

[0176] The distributed ledger 520E comprises a blockchain that stores immutable, ordered records in blocks, and a state database 524E (the current world state) that maintains the current state of blockchain 522E. Each channel can have its own distributed ledger 520E, and each peer maintains its own copy of the distributed ledger 520E for each channel to which it is a member. Blockchain 522E is a transaction log constructed as hashed linked blocks, where each block contains a sequence of N transactions. A link between blocks can be generated by appending the hash of the previous block header to the current block header. Figure 5E (As indicated by the arrow in the diagram). In this way, all transactions on Blockchain 522E are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, due to the links, the latest block in Blockchain 522E represents every transaction that arrived before it. Blockchain 522E can be stored on a peer-to-peer file system (local or attached storage) that supports append-only blockchain workloads.

[0177] The current state of blockchain 522E and distributed ledger 520E can be stored in state database 524E. Here, the current state data represents the latest values ​​of all keys ever included in the chain transaction log of blockchain 522E. Chaincode calls execute transactions against the current state in state database 524E. To make these chaincode interactions highly efficient, the latest values ​​of all keys are stored in state database 524E. State database 524E can include an indexed view of the transaction log of blockchain 522E and can therefore be regenerated from the chain at any time. State database 524E can be automatically restored (or automatically generated if needed) when peers start up before a transaction is accepted.

[0178] Endorsing nodes receive transactions from clients and endorse them based on the simulation results. The endorsing nodes maintain a smart contract that simulates the transaction proposal. When an endorsing node endorses a transaction, it creates a transaction endorsement, a signed response from the endorsing node to the client application instructing it to endorse the simulated transaction. The method of endorsing a transaction depends on the endorsement policy, which can be specified within the chaincode. An example of an endorsement policy is "most endorsing peers must endorse the transaction." Different channels can have different endorsement policies. The endorsed transaction is forwarded by the client application to the ordering service 510E.

[0179] The ordering service 510E accepts endorsed transactions, orders them into blocks, and delivers the blocks to commit peers. For example, the ordering service 510E can initiate new blocks when a transaction threshold is reached, a timer times out, or another condition is met. Figure 5E In the example, blockchain node 512E is a committing peer that has received a new data block 530E for storage on blockchain 522E. The first block in a blockchain can be called the genesis block, which includes information about the blockchain, its members, the data stored in it, etc.

[0180] The ordering service 510E can consist of a cluster of orderers. Ordering service 510E does not handle transactions, smart contracts, or maintain a shared ledger. Instead, ordering service 510E can accept endorsed transactions and specify the order in which those transactions are submitted to the distributed ledger 522E. The architecture of the blockchain network can be designed so that the specific implementation of "ordering" becomes a pluggable component.

[0181] Transactions are written to the distributed ledger 520E in a consistent order. This ordering ensures that transactions are valid when updates to the state database 524E are committed to the network. Unlike cryptocurrency blockchain systems that order transactions through solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger 520E can choose the ordering mechanism best suited to the network.

[0182] When the sorting service 510E initializes a new data block 530E, the new data block 530E can be broadcast to commit peers (e.g., blockchain nodes 511E, 512E, and 513E). In response, each commit peer verifies the transactions within the new data block 530E by checking to ensure that the read and write sets still match the current world state in the state database 524E. Specifically, the commit peers can determine whether the read data present when the endorser simulates the transaction is the same as the current world state in the state database 524E. When the commit peers verify the transaction, the transaction is written to blockchain 522E on the distributed ledger 520E, and the state database 524E is updated using the write data from the read and write sets. If the transaction fails, i.e., if the commit peers find that the read and write sets do not match the current world state in the state database 524E, the transaction that was sorted into the block will still be included in the block, but it will be marked as invalid, and the state database 524E will not be updated.

[0183] refer to Figure 5F The new data block 530 (also referred to as a data block), stored on the blockchain 522E of the distributed ledger 520E, can include multiple data segments, such as the block header 540, block data 550, and block metadata 560. It should be understood that the various blocks shown and their contents (such as...) Figure 5F The new data block 530 and its contents shown are merely examples and are not intended to limit the scope of the example embodiments. The new data block 530 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 550. The new data block 530 may also include (e.g., ...) related information within the block header 540. Figure 5E The block header 540 is a link to previous blocks on blockchain 522E. Specifically, the block header 540 may include a hash of previous block headers. The block header 540 may also include a unique block number, a hash of the block data 550 of the new data block 530, etc. The block number of the new data block 530 may be unique and assigned in various orders such as incremental / sequential starting from zero.

[0184] Block data 550 can store transaction information for each transaction recorded in the new data block 530. For example, transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of distributed ledger 520E (…). Figure 5EThe data includes: transaction ID, epoch, payload visibility, chaincode path (deployment tx), chaincode name, chaincode version, inputs (chaincode and functions), client (creator) identifiers such as public keys and certificates, client signature, endorser identity, endorser signature, proposal hash, chaincode events, response status, namespace, read set (a list of keys and versions read by the transaction, etc.), write set (a list of keys and values, etc.), start key, end key, list of keys, Merkel tree query digest, etc. Transaction data can be stored for each of N transactions.

[0185] In one embodiment of this solution, blockchain data 563 may include data comprising one or more of the following: predicted charging time for charging the rechargeable battery, attributes for predicting the charging time, algorithms for making the prediction, etc. Although in Figure 5F In this context, blockchain data 563 is depicted in block data 550, but it can also be located in block header 540 or block metadata 560.

[0186] Block metadata 560 can store multiple fields of metadata (e.g., as byte arrays). Metadata fields may include a signature at the time of block creation, a reference to the last configured block, transaction filters identifying valid and invalid transactions within the block, and a persistent last offset of the sorting service that sorts the blocks, etc. The signature, last configured block, and sorter metadata can be provided by... Figure 5E The sorting service 510E is added. Meanwhile, the block submitter (such as...) Figure 5E Blockchain nodes (512E) can add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. Transaction filters can include a byte array of size equal to the number of transactions in the block data and a verification code that identifies whether a transaction is valid / invalid.

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

[0188] An exemplary storage medium can be coupled to a processor, allowing the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be integrated into the processor. The processor and storage medium can reside in an application-specific integrated circuit (“ASIC”). Alternatively, the processor and storage medium can reside as discrete components. For example, Figure 6 An example computer system architecture 600 is shown, which can be represented or integrated into any of the components mentioned above.

[0189] Figure 6 A computing environment according to an example embodiment is shown. Figure 6 This is not intended to impose any limitation on the scope or functionality of the embodiments of the applications described herein. In any case, computing environment 600 can be implemented to perform any of the functions described herein. Within computing environment 600, computer system 601 can operate within many other general-purpose or special-purpose computing system environments or configurations.

[0190] Computer system 601 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, server computer system, thin client, fat client, network PC, minicomputer system, mainframe computer, quantum computer, and a distributed cloud computing environment including any of the systems or devices described, or any other form of computer or mobile device now known or to be developed in the future capable of running programs, accessing network 650, or querying databases. Depending on the technology, the execution of the computer-implemented methods may be distributed among multiple computers and multiple locations. However, in this presentation of computing environment 600, the detailed discussion focuses on a single computer, specifically computer system 601, to keep the presentation as simple as possible.

[0191] Computer system 601 can reside in the cloud, even if it is Figure 6 The cloud is not shown. On the other hand, computer system 601 does not need to be located in the cloud, except to any extent that can be definitively indicated. Computer system 601 can be described in the general context of computer system executable instructions such as program modules executed by computer system 601. Typically, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform tasks or implement certain abstract data types. Figure 6 As shown, the computer system 601 in the computing environment 600 is illustrated as a general-purpose computing device. Components of the computer system 601 may include, but are not limited to, one or more processors or processing units 602, system memory 630, and a bus 620 that couples various system components, including the system memory 630, to the processor 602.

[0192] Processing unit 602 includes one or more computer processors of any type now known or to be developed. Processing unit 602 may contain circuitry distributed across multiple integrated circuit chips. Processing unit 602 may also implement multiple processor threads and multiple processor cores. Cache 632 is memory that can be within the processor chip package or located "off-chip," such as… Figure 6 As shown in the diagram. Cache 632 is typically used for data or code that should be readily accessible to threads or cores running on processing unit 602. In some computing environments, processing unit 602 may be designed to work with qubits and perform quantum computing.

[0193] Network adapter 603 enables computer system 601 to connect and communicate with one or more networks 650, such as a local area network (LAN), a wide area network (WAN), and / or a public network (e.g., the Internet). It bridges the computer's internal bus 620 with the external network, exchanging data efficiently and reliably. Network adapter 603 may include hardware such as a modem or Wi-Fi transceiver, and software for packetizing and / or depacketizing data transmitted over the communication network. Network adapter 603 supports various communication protocols to ensure compatibility with network standards. For Ethernet connections, it conforms to protocols such as IEEE 802.3, while for wireless communication, it may support the IEEE 802.11 standard, Bluetooth, Near Field Communication (NFC), or other network wireless radio standards.

[0194] Computer system 601 may include a removable / non-removable, volatile / non-volatile computer storage device 610. By way of example only, storage device 610 may be a non-removable, non-volatile magnetic medium (not shown, and often referred to as a "hard disk drive"). One or more data interfaces may connect it to bus 620. In embodiments requiring a large amount of storage for computer system 601 (e.g., where computer system 601 locally stores and manages a large database), this storage may be provided by a peripheral storage device 610 designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers.

[0195] Operating system 611 is software that manages the hardware resources of computer system 601 and provides public services to computer programs. Operating system 611 can take several forms, such as various known proprietary operating systems or operating systems of the kernel-based open-source portable operating system interface type.

[0196] Bus 620 represents one or more of several types of bus architectures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses using various bus architectures. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses. Bus 620 is a signaling path that allows various components of computer system 601 to communicate with each other.

[0197] Memory 630 is any volatile memory now known or to be developed in the future. Examples include dynamic random access memory (RAM 631) or static type RAM 631. Typically, volatile memory is characterized by random access, but this is not required unless explicitly stated otherwise. In computer system 601, memory 630 is in a single package and internal to computer system 601; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally relative to computer system 601. By way of example only, memory 630 may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (shown as storage device 610 and commonly referred to as a "hard disk drive"). Memory 630 may include at least one program product having a set (e.g., at least one) of program modules configured to perform various functions. A typical computer system 601 may include cache 632, which is a dedicated volatile memory that is typically faster than RAM 631 and typically located closer to processing unit 602. Cache 632 stores frequently accessed data and instructions accessed by processing unit 602 to speed up processing time. Computer system 601 may include non-volatile memory 633 in ROM, PROM, EEPROM, and flash memory. Non-volatile memory 633 typically contains programming instructions for booting the computer, including information required for BIOS and booting operating system 611.

[0198] Computer system 601 can also communicate with one or more peripheral devices 641 via I / O interface 640. Such devices may include a keyboard, pointing device, display, etc.; one or more devices that enable a user to interact with computer system 601; and / or any device that enables computer system 601 to communicate with one or more other computing devices (e.g., network interface card, modem, etc.). Such communication can be performed via input / output (I / O) interface 640. As depicted, I / O interface 640 communicates with other components of computer system 601 via bus 620.

[0199] Network 650 is any computer network capable of receiving and / or sending data. Network 650 may include a WAN, LAN, private cloud, or public Internet, capable of transmitting computer data over non-local distances using any technology now known or to be developed in the future. Any connections depicted may be wired and / or wireless and may pass through other components not shown. In some embodiments, network 650 may be replaced and / or supplemented by a LAN designed to transmit data between devices located in a local area, such as a Wi-Fi network. Network 650 typically includes computer hardware such as copper transmission cables, optical fiber transmission, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers. Computer system 601 is connected to network 650 via network adapter 603 and bus 620.

[0200] User equipment 651 is any computer system used and controlled by an end user in conjunction with computer system 601. For example, assuming computer system 601 is designed to provide recommendations to the end user, these recommendations can typically be transmitted from network adapter 603 of computer system 601 to user equipment 651 via network 650, allowing user equipment 651 to display or otherwise present the recommendations to the end user. User equipment can be a wide variety of devices, including PCs, laptops, tablets, handheld devices, mobile phones, etc.

[0201] Remote server 660 is any computer that provides at least some data and / or functionality to computer system 601 via network 650 (such as a WAN, Virtual Private Network (VPN), private cloud, or via the Internet). These networks 650 may communicate with a LAN to reach the user. The user interface may include an application or web browser that facilitates communication between the user and remote data. Such an application is referred to as a "thin" desktop or "thin client." Thin clients typically incorporate software programs to emulate desktop sessions, such as Microsoft RDP (Remote Desktop Protocol) or Citrix ICA (Independent Computing Architecture). Mobile applications may also be used. Remote server 660 may also host a remote database 661, which may reside on one remote server 660 or be distributed across multiple remote servers 660. Remote database 661 can be accessed via network 650 from database client applications locally installed on remote server 660, other remote servers 660, user device 651, or computer system 601.

[0202] Public cloud 670 refers to the on-demand availability of computer system resources, including data storage and computing power, without direct active management by users. Public cloud 670 is typically distributed, with data centers located in multiple locations for availability and performance. Computing resources on the public cloud (670) are shared among multiple tenants through virtual computing environments that include virtual machines 671, databases 672, containers 673, and other resources. Container 673 is isolated, lightweight software for running applications on the host operating system 611. Container 673 is built on top of the host operating system kernel and contains only the application (app) and some lightweight operating system APIs and services. In contrast, virtual machine 671 is a software layer that includes the complete operating system 611 and kernel. Virtual machine 671 is built on top of a hypervisor emulation layer designed to abstract the host computer's hardware from the operating software environment. Public cloud 670 typically provides a managed database 672 that abstracts high-level database management activities. It should also be understood that... Figure 6 One or more elements described or depicted herein may perform one or more actions, functions, or features described or depicted herein.

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

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

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

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

[0207] In practice, a module of executable code can be a single instruction or multiple instructions, and can even be distributed across several different code segments, between different programs, and across several memory devices. Similarly, operational data can be identified and represented within this module, and can be embodied in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single dataset, or it can be distributed across different locations, including across different storage devices, and can exist at least in part as electronic signals on a system or network.

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

[0209] Those skilled in the art will readily understand that the above content can be practiced using steps in different sequences and / or hardware components in configurations different from the disclosed configuration. Therefore, although this application has been described based on these preferred embodiments, certain modifications, variations, and alternative constructions will be apparent to those skilled in the art.

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

Claims

1. A method comprising: The vehicle's computer is queried via a charging station, wherein the query includes receiving the attributes of the vehicle's rechargeable battery from the computer; The total charging time for the rechargeable battery is determined based on the properties of the rechargeable battery and the properties of the charging station. Based on the determined total charging time of the rechargeable battery, media content is selected from multiple media content sources; and Media content is output via the charging station.

2. The method according to claim 1, wherein, The selection includes querying the application programming interface (API) of the entertainment content distribution platform based on the value of the total charging time to select media content from the plurality of media content.

3. The method according to claim 1, wherein, The determination includes determining the total charging time based on the type of the rechargeable battery, the capacity of the rechargeable battery, the current state of charging of the rechargeable battery, and the availability of the charging station.

4. The method according to claim 1, wherein, The determination includes determining the total charging time based on a battery power charging graph, wherein the battery power charging graph includes a first axis representing the charging power of the charging station and a second axis representing the charging state of the rechargeable battery.

5. The method according to claim 1, wherein, The selection includes choosing a video file that will be played before the end of the total charging time, and the output includes playing the video file via one or more of the user devices of the occupants in the vehicle and the display devices installed in the vehicle.

6. The method according to claim 1, wherein, The selection includes: selecting a video file that includes an intermediate stop point, the intermediate stop point being played before the end of the total charging time; and the output includes playing the video file via the user interface of the charging station up to the intermediate stop point.

7. The method according to claim 1, wherein, The selection includes selecting a first media file and a second media file based on the total charging time of the rechargeable battery, and the output includes playing the first media file on a first display device in the vehicle and playing the second media file on a second display device in the vehicle.

8. An apparatus comprising: The memory is configured to store multiple media contents; as well as A processor, communicatively coupled to the memory, is configured to: The vehicle's computer is queried via a charging station, wherein the query includes receiving attributes of the vehicle's rechargeable battery from the computer. The total charging time for the rechargeable battery is determined based on the properties of the rechargeable battery and the properties of the charging station. Based on the determined total charging time of the rechargeable battery, media content is selected from the plurality of media contents stored in the memory, and Media content is output via the charging station.

9. The apparatus according to claim 8, wherein, The processor is configured to query the application programming interface (API) of the entertainment content distribution platform based on the value of the total charging time in order to select media content from the plurality of media content.

10. The apparatus according to claim 8, wherein, The processor is configured to determine the total charging time based on the type of the rechargeable battery, the capacity of the rechargeable battery, the current state of charge of the rechargeable battery, and the availability of the charging station.

11. The apparatus according to claim 8, wherein, The processor is configured to determine the total charging time based on a battery power charging graph, wherein the battery power charging graph includes a first axis representing the charging power of the charging station and a second axis representing the charging state of the rechargeable battery.

12. The apparatus according to claim 8, wherein, The processor is configured to select a video file that will be played before the end of the total charging time, and to play the video file via one or more of the user devices of the occupants in the vehicle and the display devices installed in the vehicle.

13. The apparatus according to claim 8, wherein, The processor is configured to select a video file that includes an intermediate stop point, the intermediate stop point of which will finish playing before the end of the total charging time; And play the video file via the user interface of the charging station until the intermediate stop point.

14. The apparatus according to claim 8, wherein, The processor is configured to select a first media file and a second media file based on the total charging time of the rechargeable battery, and to play the first media file on a first display device in the vehicle and the second media file on a second display device in the vehicle.

15. A computer-readable storage medium comprising instructions that, when executed by a processor, cause the processor to perform: The vehicle's computer was accessed via the charging station, among which... The query includes receiving the attributes of the vehicle's rechargeable battery from the computer; The total charging time for the rechargeable battery is determined based on the properties of the rechargeable battery and the properties of the charging station. Based on the determined total charging time of the rechargeable battery, media content is selected from multiple media content options; as well as Media content is output via the charging station.

16. The computer-readable storage medium according to claim 15, wherein, The selection includes querying the application programming interface (API) of the entertainment content distribution platform based on the value of the total charging time to select media content from the plurality of media content.

17. The computer-readable storage medium according to claim 15, wherein, The determination includes determining the total charging time based on the type of the rechargeable battery, the capacity of the rechargeable battery, the current state of charging of the rechargeable battery, and the availability of the charging station.

18. The computer-readable storage medium according to claim 15, wherein, The determination includes determining the total charging time based on a battery power charging graph, wherein the battery power charging graph includes a first axis representing the charging power of the charging station and a second axis representing the charging state of the rechargeable battery.

19. The computer-readable storage medium according to claim 15, wherein, The selection includes choosing a video file that will be played before the end of the total charging time, and the output includes playing the video file via one or more of the user devices of the occupants in the vehicle and the display devices installed in the vehicle.

20. The computer-readable storage medium according to claim 15, wherein, The selection includes selecting a first media file and a second media file based on the total charging time of the rechargeable battery, and the output includes playing the first media file on a first display device in the vehicle and playing the second media file on a second display device in the vehicle.

Images