Content management during vehicle charging

Abstract

Example operations include one or more of determining a remaining time until completion of charging of the vehicle and transmitting content to the vehicle based on the remaining time.

Description

Background Technology

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

[0002] One example embodiment provides a method that includes one or more of the following: determining the remaining time until the vehicle is fully charged, and transmitting content to the vehicle based on the remaining time.

[0003] Another example embodiment may include a system comprising a memory and a processor configured to determine the remaining time until the vehicle is fully charged, and to transmit content to the vehicle based on the remaining time.

[0004] Another example embodiment may include a non-transitory computer-readable medium configured to store instructions that, when executed, cause a processor to determine the remaining time until the vehicle's charging is complete, and to transmit content to the vehicle based on the remaining time. Attached Figure Description

[0005] Figure 1A The illustration shows an example system diagram of a vehicle charging at a charging station and receiving content from a server, according to an example embodiment.

[0006] Figure 1B The diagram illustrates a network diagram of a vehicle using a charging station, receiving content, and performing vehicle operations based on that content, according to an example embodiment.

[0007] Figure 2A The illustration shows a vehicle network diagram according to an example embodiment.

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

[0009] Figure 2C Another vehicle network diagram according to an example embodiment is also illustrated.

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

[0011] Figure 2E A flowchart according to an example embodiment is illustrated.

[0012] Figure 2F Another flowchart according to an example embodiment is illustrated.

[0013] Figure 3A The diagram illustrates an artificial intelligence (AI) / machine learning (ML) network used in an example embodiment to integrate an artificial intelligence (AI) model into any decision point.

[0014] Figure 3B The diagram illustrates the processing used to develop artificial intelligence (AI) / machine learning (ML) models that support AI-assisted vehicle or occupant decision-making points.

[0015] Figure 3C The diagram illustrates the processing used to leverage artificial intelligence (AI) / machine learning (ML) models that support AI-assisted vehicle or occupant decision-making points.

[0016] Figure 3D The diagram illustrates a machine learning network diagram according to an example embodiment.

[0017] Figure 3E The diagram illustrates a machine learning network diagram according to an example embodiment.

[0018] Figure 4A The diagram illustrates the electrification of one or more elements according to an example embodiment.

[0019] Figure 4B The diagram illustrates the interconnections between different elements according to an example embodiment.

[0020] Figure 4C Another diagram is illustrated, depicting the interconnection between different elements according to an example embodiment.

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

[0022] Figure 4E Another diagram is shown depicting an example of a vehicle using a security certificate to perform secure vehicle-to-vehicle (V2V) communication according to an example embodiment.

[0023] Figure 5A The illustration shows an example vehicle configuration for managing database transactions associated with a vehicle, according to an example embodiment.

[0024] Figure 5B An example blockchain group according to an example embodiment is illustrated.

[0025] Figure 5C The illustration shows an example interaction between an element and a blockchain according to an example embodiment.

[0026] Figure 5D The illustration shows an example data block interaction according to an example embodiment.

[0027] Figure 5EThe diagram illustrates a blockchain network according to an example embodiment.

[0028] Figure 5F The illustration shows an example new data block according to an example embodiment.

[0029] Figure 6 An example system supporting one or more of the example embodiments is illustrated. Detailed Implementation

[0030] It will be readily understood that the components described and illustrated herein, as generally presented in the figures, can be arranged and designed in a wide variety of different configurations. Therefore, the following detailed description of at least one embodiment of a method, apparatus, computer-readable storage medium, and system (as illustrated in the accompanying drawings) is not intended to limit the scope of the 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.

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

[0032] The features, structures, or characteristics described herein can be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrases “example embodiment,” “some embodiments,” “first embodiment,” or other similar language 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. While one or more features, elements, and steps described herein are described in a particular manner by way of example only, they can be used together or in various combinations without exclusivity unless expressly indicated herein. In the figures, any connection between elements can allow unidirectional and / or bidirectional communication, even if the connections drawn are unidirectional or bidirectional (such as arrows).

[0033] 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, e-Palette vehicles, 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.

[0034] Furthermore, 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. Additionally, although certain types of messages and signaling may be depicted in the exemplary embodiments, they are not limited to any particular type of message and signaling.

[0035] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide at least one of the following: a means of transport (also referred to herein as a vehicle or automobile), a data collection system, a data monitoring system, a verification system, an authorization system, and a vehicle data distribution system. Vehicle condition 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 condition conditions and provide feedback on the condition and / or changes of the vehicle. In one example, a user profile can be applied to a specific vehicle to authorize current vehicle events, service stops at service stations, and subsequent vehicle rental services, as well as to enable vehicle-to-vehicle communication.

[0036] 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 among 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 build a hash chain via blocks. This process forms the ledger by ordering the storage entries, as is necessary for consistency. In public or permissionless blockchains, anyone can participate without a specific identity. Public blockchains can involve cryptocurrencies and use consensus based on various protocols such as Proof-of-Work (PoW). Conversely, permissioned blockchain databases can ensure secure interactions between a group of entities (such as businesses exchanging funds, goods, information, etc.) that share common goals but cannot fully trust each other. This solution can work in both permissioned and / or permissionless blockchain settings.

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

[0038] A node is a communication entity in a blockchain system. In the sense that multiple different types of nodes can run on the same physical server, a "node" can perform logical functions. 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, submit entries, and maintain the state and copies 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 node 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.

[0039] A ledger is an ordered, tamper-proof record of all state transitions in a blockchain. State transitions can be triggered by smart contract executable code calls (i.e., entries) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). An entry can result in a set of asset key-value pairs being committed to the ledger as one or more operands (such as create, update, delete, etc.). The ledger includes the blockchain (also called 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. Each channel typically has its own ledger. Each peer node maintains a copy of the ledger for each channel for which it is a member.

[0040] A chain is a log of entries structured as a chain of hashed 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, as well as the hash of the header of the previous block. In this way, all entries on the ledger can be ordered and cryptographically linked together. Consequently, 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 preceding it, making it possible to ensure that all peer nodes are in a consistent and trusted state. This chain can be stored on peer node file systems (i.e., local, attached storage, the cloud, etc.), thus efficiently supporting the append-only nature of blockchain workloads.

[0041] The current state of an immutable ledger represents the latest value of all keys included in the chain's 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 entries based on the ledger's current state data. 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's entry log and therefore can be regenerated from the chain at any time. The state database can be automatically restored (or generated when needed) after peer nodes start up and before accepting entries.

[0042] The difference between blockchain and traditional databases is that blockchain is not a central storage device, but a decentralized, immutable, and secure storage device, in which nodes must share changes recorded in the storage device. Some inherent characteristics of blockchain that help enable it include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility.

[0043] Example embodiments provide services to specific vehicles and / or user profiles applied to vehicles. For example, a user may be the owner of a vehicle or the operator of a vehicle owned by another party. Vehicles may require service at certain intervals, and service requests may require authorization before being allowed to receive service. Moreover, service centers may provide services to vehicles in a nearby area based on the vehicle's current route plan and relative service level requirements (e.g., immediate, severe, moderate, minor, etc.). Vehicle requests 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 inside and / or outside the vehicle. This data is forwarded to a management server for review and action. Sensors may be located on one or more of the following: inside the vehicle, outside the vehicle, on a fixed object away from the vehicle, and on another vehicle nearby. Sensors may also be associated with vehicle speed, vehicle braking, vehicle acceleration, fuel level, service requests, vehicle gear shifts, vehicle steering, etc. As described herein, sensors may also be devices, such as wireless devices inside and / or near the vehicle. Furthermore, sensor information can be used to identify whether a vehicle is operating safely and whether occupants are in any unexpected vehicle conditions, such as during vehicle entry and / or use. 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 licensing body, and thus in a “decentralized” manner, such as via a blockchain membership group.

[0044] Each stakeholder (i.e., owners, users, companies, agents, etc.) may wish to restrict the disclosure of private information; therefore, blockchain and its immutability can be used to manage the licensing of each specific user's vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event licenses, determine when services are needed, identify collision and / or downgrade events, identify safety issue events, identify the parties involved in an event, and provide distribution to registered entities seeking access to such vehicle event data. Similarly, outcomes can be identified, and necessary information can be shared among registered companies and / or individuals based on a "consensus" approach associated with the blockchain. Such an approach cannot be implemented on traditional centralized databases.

[0045] The various driving systems in this solution can utilize software, sensor arrays, machine learning capabilities, LiDAR projectors, radar, ultrasonic sensors, and more to create maps of terrain and roads that the vehicle can use for navigation and other purposes. In some embodiments, GPS, maps, cameras, sensors, and more can also be used in place of LiDAR in autonomous vehicles.

[0046] In some embodiments, this solution includes authorizing the vehicle to provide service 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 once the service station and / or charging station receives authorization. The vehicle can provide a communication signal that identifies the vehicle with a current activity profile linked to an authorized account for receiving service, which can then be settled through compensation. Further authentication can be provided using other measures, such as another identifier wirelessly transmitted from the user's device to the service center to replace or supplement the initial authorization work between the vehicle and the service center through additional authorization work.

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

[0048] Any action described herein can be performed by one or more processors (such as microprocessors, sensors, electronic control units (ECUs), head units, etc.), which may or may not have memory, and can be located on and / 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 the vehicle to utilize data sent by and / or transmitted to the vehicle. One or more processors and other processors can send data, receive data, and use this data to perform one or more of the actions described or depicted herein.

[0049] Figure 1A The illustration depicts an example system diagram illustrating the process of a vehicle charging at a charging station and receiving content managed by a server, according to an example embodiment. (Reference) Figure 1A System configuration 100 includes a vehicle 130 identified as a candidate to initiate charging at charging station 152 or charging point (which are used interchangeably below). Server 160 may be a remote computer in a cloud network or a local computer, such as a mobile device or other computing device, operating near vehicle 130. Once vehicle 130 is identified as a candidate for electric charging (e.g., electrical charging), server 160 can assign the vehicle to a specific charging station 152 and vehicle 130 can begin receiving charging 112. Vehicle 130 can then communicate with charging station 152 to initiate charging processing 114. The initial vehicle charge level can change rapidly to an increasing / higher / greater amount of charge continuously monitored by server 160. The amount of time, the updated charge level, and other charging attributes can be continuously monitored by server 160 at any given time to determine the condition of vehicle 130. Server 160 can make predictions based on known data about how long the vehicle should charge or will need to charge to reach an optimal charge level (e.g., 60%, 70%, 80%, or higher). The estimated charging time 116 can be determined based on factors such as the type of vehicle, the type of charging station, and the charging duration of each vehicle previously. All of this information can be used as a basis for predicting how long vehicle 130 should remain charging at charging station 152.

[0050] When vehicle 130 has a predefined time frame for charging (such as a period of time that can be identified as an estimated charging window), content 118 can be transmitted from server 160 or other content management entities to the vehicle. Content can be movies, commercials, television programs, videos, audio, etc. Content can also be games, such as online games that users can play via controllers or that provide feedback to manipulate other actions during the game session. Server 160 can identify and maintain a list 122 of actions performed by occupants of vehicle 130. For example, an occupant may be playing a game and using a controller, such as a mobile device and / or computing device integrated with the vehicle, to perform detectable gestures by moving their hands, etc. While playing a game in vehicle 130, server 160 can control one or more functions and parts of vehicle 130 based on the results of the game actions.

[0051] Continuing with the same example, when an occupant plays a game based on content sent to the vehicle's computing device and / or the occupant's mobile device, one or more vehicle functions (124) can be enabled based on actions such as signals transmitted from server 160 and / or control signals provided by the computing device and / or vehicle 130. In one example, if an occupant uses an avatar to jump off a bridge in the game, vehicle 130 can enable air to be blown from the ventilation system and / or controlled parts of the vehicle to shake to simulate a freefall experience. When an action is performed by the occupant on an in-vehicle controller, server 160 can receive that action, such as a digitized command, and respond by transmitting vehicle control functions (126). Another example could include releasing scented air from a diffuser installed in the vehicle based on selected game actions. Seats in the vehicle can be moved to simulate changes in position or condition based on the performed game actions. Any controllable aspect of the vehicle can be modified to simulate identified game actions.

[0052] While vehicle 130 is charging, certain third-party affiliates can be identified from the user and / or vehicle profiles associated with vehicle 130. Examples may include the current status of subscription services, purchase orders requiring delivery (e.g., food delivery orders, purchases from merchants, etc.), all of which can be identified to consider routing those orders to the vehicle during charging. In one example, charging station 152 may be located in a busier part of town than the user's home address, and it may be sensible to consider this temporary location as a delivery point to reduce the number of miles the delivery vehicle might typically have to travel to reach the user's home. Affiliates identified by server 160 can generate a list of locations and / or services to be included in the user's profile as pending services, such as pending deliveries, pending subscriptions, etc. Any of the affiliates with pending status can be dispatched to include orders or services during the estimated time window used to charge the vehicle. Once affiliates are identified, the items or services to be provided to the vehicle can be selected. This can include one, two, or more items, which can include physical items (such as food delivery, package delivery) and intangible items (such as streaming movies, music, etc.). User profiles can have preference settings that allow only computer-based content to be sent to vehicles instead of deliveries, or to send all possible deliveries to charging stations for that particular vehicle at any given time.

[0053] Figure 1B The diagram illustrates a network diagram of a vehicle using a charging station and sending content to the vehicle during a charging session, according to an example embodiment. (Reference) Figure 1B Network 150 includes a vehicle management server 160, which can maintain the status of vehicles 130 undergoing charging cycles at charging points or charging stations 152. A vehicle 130 currently charging may have an initial charge level, such as 10% of a full charge level or a low charge amount. Any vehicle attempting to charge below an initial minimum charge level (such as 30%) will be charged more per unit of charge because, since it has not exceeded the minimum charge level, the vehicle may not be considered undercharged at that particular time. The requested charge amount can be used as the basis for determining the charging time and selecting what to send to the vehicle and share with the vehicle's occupants.

[0054] In this example, vehicle 130 may begin charging at charging station 152, and the estimated charging time 162 may be determined by vehicle management server 160 or another computing device to identify whether the remaining time until vehicle 130 leaves charging station 152 is a sufficiently long period for vehicle 130 to receive content from server 160 and consume the provided content 164 within a period less than or close to the estimated charging time 162. At the moment vehicle 130 links with charging station 152, a timer may begin measuring the estimated total time for vehicle 130 to complete charging as a function of the current time, the amount of charge currently held by the vehicle, and the charging rate of charging station 152. Content selections, such as movies, video games, etc., may have corresponding usage times associated with those selections, and the decision made by vehicle management server 160 to distribute content to vehicle 130 and its corresponding computer systems (such as monitors and computers integrated into the vehicle and / or mobile devices of occupants within the vehicle) may be based on the estimated usage time. When the amount of time is less than or close to the predicted remaining time, that particular selection may be distributed for occupant use.

[0055] In one example, the system app can deliver content to the vehicle and / or (one or more) occupants based on estimated charging time. Recognizing that vehicle owners can charge to 80% or more of their battery capacity, which can take a significant amount of time, the system app makes the most of this available time by providing entertainment and / or informational data to (one or more) occupants. Examples could include streaming media, news updates, games, and / or interactive content tailored to the predicted duration of the charging session. Depending on user preferences, the latest news could also be delivered via video, audio, and / or text, and the content could be premium and licensed to the charging service. Furthermore, games, quizzes, educational content, or even guided meditation sessions could be offered to interactively engage users. The system app can provide a selection of content that users can consume during the time required to charge their vehicle. For example, if a charging session is expected to take 30 minutes, the system app can suggest content that can be completed within that identified time duration, thus providing a satisfying experience for the user at the charging station from start to finish. Once the charging session begins, content delivery can be automated and personalized based on known occupant preferences stored in the vehicle's online profile and / or the occupants' mobile devices. Over time, the system application responsible for sharing content can learn users' content preferences and suggest personalized options for each charging session that differs from previous sessions. Content provisioning can also be based on time of day, location, and / or charging speed, and can be dynamically adjusted so that the options differ if the charging time is shorter or longer than initially expected.

[0056] In one example, the system application can coordinate certain services, such as car washing and repairs while the vehicle is parked at a charging station. The scheduling of these services can be based on the expected duration of the vehicle's stay, conveyed by the system application's ability to predict how long the vehicle will take to charge (e.g., 38 minutes to charge from 20% to 80% battery capacity). This prediction can assist in scheduling certain ancillary services received within that window. By using a combination of predictive analytics for estimating charging time and a scheduling application for creating and confirming service appointments, vehicle owners can be able to optimize their time usage while charging.

[0057] In one example, the system application uses predictive capabilities to determine vehicle accessibility windows for various delivered services or goods. Operating on server 160, the system application can predict availability by assessing factors such as the vehicle's current condition, required maintenance (e.g., fluid levels, tire pressure, or headlight functionality) and the user's consumption of goods (e.g., recently watched videos, recent food purchases). The application can then coordinate with the service provider to ensure appointments for those items are made within the allocated timeframe and by presenting the user with service options and associated costs.

[0058] While charging, users can leave the vehicle and participate in nearby activities such as entertainment or dining. Autonomous vehicles (such as taxis, cars, scooters, or other transportation) can be dispatched to access vehicle 130 and pick up users, taking them on tours of the area or to nearby restaurants while charging. The vehicle can deliver food or other items before allowing users to board. Schedules of times and activities can be autonomously executed based on the vehicle's predicted charging time windows.

[0059] Vehicle seats, such as driver's seats or "cockpits," can be ideally suited for gaming, featuring ergonomically designed seats for good visibility and enhanced video displays, and audio surround systems are standard features in many new electric vehicles (EVs). EVs could soon become ideal gaming consoles, with tactile and sensory effects delivered through vehicle features such as massage seats that can be paired with events happening in the game environment and directional air conditioning. For example, depending on the game scenario (e.g., the Arctic, jungle, etc.), warm or cold air can flow from the vehicle's ventilation nozzles. Moreover, explosions on the screen can be amplified through sudden activation of heated seats, seat movement, or vibrations. If the game activity involves sudden stops or impacts, seatbelt tensioners can tighten to amplify rapid or sudden movements. Furthermore, when the game activity involves entering new environments, vehicle fragrances can infuse the vehicle interior with appropriate scents such as pine, fresh grass, fruit, or smoke.

[0060] In one example, if there isn't a sufficient estimated remaining time for a satisfactory gaming session before the vehicle's charging is complete, it prevents occupants from starting another game after one game has finished. This feature is based on real-time data and helps ensure that an occupant's gaming session isn't abruptly interrupted when charging is complete but the gaming session hasn't ended. When their vehicle is fully charged, the app can allow the occupant to exit or stop the game. In one example, a video recording of the game being played is sent to the user's associated device after exiting the game. Furthermore, pending or active games can be saved and sent to another device to be completed at a later time.

[0061] In one example, vehicle hardware sensors can monitor charging progress. The sensors can measure the current charging rate, battery status, and remaining time until a full charge is achieved. Communication can be established between the vehicle's charging system and the gaming system. The system application can collect and analyze statistics related to one or more gaming sessions. This data may include game duration, user behavior, and preferences. In one embodiment, artificial intelligence (AI) models and machine learning functionality are used to predict the optimal timing for the next gaming session based on historical usage data and the current charging status. Predictions may include selecting a game type suitable for a particular type of vehicle based on in-game actions and vehicle control functions to provide an ideal simulation environment for the type of game being played. Another prediction could be a possible start and end timeline of the game that is closest to the vehicle's estimated charging time, preventing occupants from being interrupted during a gaming session due to the end of the charging session, and thus preventing the game duration from being too short if the vehicle will have to continue charging for a considerable amount of time after the game ends. Since charging is completed before the gaming session, the system application can provide notifications and / or alerts during the gaming session when it seems there is not enough time to complete the game. Notifications can be sent from server 160 to vehicle 130 and the corresponding computing device and / or one or more personal devices of the occupants. Notifications can appear as part of the game or via a separate notification platform.

[0062] In one example, an interface can be designed within the vehicle's entertainment system or via a connected mobile application to allow users to exit or stop the game when charging is complete. Video recording functionality is implemented within the game system application to capture the user's gameplay. This recorded video can be temporarily stored or uploaded to a cloud server for later access. The recorded gameplay video can be sent to the user's associated device, such as a smartphone or tablet. Some examples may include a mobile application that the user can install on their smartphone and / or tablet. This application allows the user to interact with the game system, receive notifications, and access the recorded gameplay video. The game system can be integrated into the vehicle's entertainment system (such as in the head unit) to provide a seamless experience for users within the vehicle.

[0063] One example could include a process that determines the remaining time until the vehicle's charging is complete and transmits content to the vehicle based on that remaining time. This time span can be identified based on estimations performed according to the vehicle's type, the type of charging station, the vehicle's current charge level, the required charge level, and / or the current demand for charging station usage from various other EVs in the area.

[0064] The process may also include identifying an application associated with a vehicle occupant's profile and initiating the application while the vehicle is charging, provided the remaining time falls within the duration of the application's usage. The application could be a type of data service, such as streaming video, movies, news, etc., and / or another type of entertainment, such as games or related interactive experiences (e.g., trivia, online multi-user activities, etc.). The user profile associated with the vehicle and / or one or more of the occupant's user devices can provide information about previous content usage, current interests, age, occupation, hobbies, etc., any of which can be used to select videos, audio, or games to share with the occupant during the charging session. The process may also include identifying one or more actions performed by the occupant while using the application and enabling one or more vehicle functions in response to the one or more actions identified in the application. Actions can be choices made during interactive multimedia sessions, such as games or other selection-based activities. For example, a jumping or fast-moving action could increase the vehicle's air ventilation function to blow air at a faster rate. Another example could be an action of hitting or kicking an opponent, which might cause vibration or movement in the vehicle's seat controls. One or more vehicle functions may include seat movement, changes in air ventilation speed or temperature, changes in lighting control, and changes in the air injector. The transmitted content may be streaming video and / or game content associated with the vehicle's occupants. Processing may also include determining that the game session associated with the application has prematurely ended at the updated remaining time and determining not to initiate another game session based on that updated remaining time. In one example, if the game is expected to average 7 minutes and the charging time is expected to complete in less than 3 minutes, then the decision to allow another game can be stopped by the system application. In this scenario, a short content session, such as recent news headlines and other types of content instead of the game, may be initiated to attempt to fill the remaining charging timeline after the game ends. Processing may also include determining that charging is complete, determining that the game session associated with the application is not complete, and forwarding the game session data to the user's device. The occupant can then access the game at a later time, as the game profile can be stored in a cloud server application, allowing the user to resume the game on their personal device after leaving the vehicle.

[0065] In one embodiment, the system provides interactive lessons on environmental protection, renewable energy, and sustainable living during the vehicle's charging period. Users can learn about solar energy, wind energy, recycling, and wildlife conservation. Quizzes and mini-games keep passengers engaged. The system educates and inspires passengers about environmental sustainability, renewable energy, and ecological awareness. When the vehicle is plugged in for charging, passengers can activate the eco-education mode via the infotainment system or a dedicated button. The vehicle's screens become educational interfaces, whether integrated into the dashboard, headrests, or rear-seat displays. Content is delivered through videos, interactive modules, quizzes, and engaging visuals. Videos are presented in a classroom lesson format, allowing occupants to participate as pseudo-students and progress through the lesson with each charging session. Occupants can learn about a variety of topics, including how solar panels work, utilizing wind energy, understanding hydroelectric dams, battery chemistry, the importance of recycling, and wildlife conservation. The system also includes interactive elements, including quizzes on environmental topics, virtual tours of eco-related locations, and eco-themed games. As passengers engage with the content, they earn points based on their participation. These points can be converted into charging credits or donated to environmental organizations. The system can be customized to an individual's learning experience. For example, it can provide simplified content for younger passengers and in-depth information for adults, enthusiasts, or passengers who have made progress and achieved high scores on quizzes.

[0066] In one embodiment, this solution encourages physical activity while the vehicle is charging. During the charging session, the vehicle's infotainment system transforms into a fitness center. Passengers can participate in various workouts without leaving the vehicle. The vehicle synchronizes with compatible exercise machines (e.g., treadmills, elliptical trainers, rowing machines) available at the charging station. Real-time heart rate data is displayed on the vehicle's screen, allowing users to monitor their workout intensity. Passengers can choose from various workout modes, including aerobic exercise, strength training, and flexibility routines, and set their workout rhythm and mood through music selection. The system tracks the time spent in the target heart rate zone during the workout, and passengers receive feedback on their effort level and overall fitness intensity. As users engage in workouts, they earn charging credits or other incentives. The system can be customized to suit individual fitness experiences, offering gentle workouts for beginners and high-intensity workouts for advanced users.

[0067] In one embodiment, the system utilizes vehicle charging sessions to engage occupants in collaborative art conversations. While the vehicle is charging, its infotainment system transforms into a digital canvas. Passengers—friends, family, or strangers—can contribute to the evolving artwork. They can sketch, doodle, or create complex designs using a touchscreen or stylus. Collaborators can add poems, short stories, or fragments of their thoughts. Passengers can create new music by using the vehicle's audio system to play music, display lyrics, and invite other passengers to sing or compose additional verses. Each charging session adds content to existing artwork, whether it's a new chapter in a novel, a different graphic in an artwork, or a new verse in a song. The vehicle archives past creations, creating a gallery accessible during future rides. Users can revisit their collaborative masterpieces or explore contributions from others. The spontaneous nature of creating art in a vehicle allows for collaboration and creativity that transcends the normal setup of a studio or home environment.

[0068] In one embodiment, the system provides a guided virtual tour while the vehicle is charging. When the vehicle is plugged in for charging, the infotainment system activates the virtual tour guide mode. Passengers can select destinations from a menu or allow the system to select them. The vehicle screen displays detailed 3D models of nearby attractions, allowing users to virtually explore historical buildings, national parks, or iconic landmarks. Short videos provide context, historical anecdotes, and engaging facts. When users begin their tour, they can enable narration and choose from selectable narration voices. During the tour, users can select interactive points of interest within the 3D model to learn about architectural styles, flora and fauna, or geological features. The system also tests knowledge gained from the tour through quizzes, with correct answers earning charging credits. For vehicles equipped with augmented reality (AR) capabilities, passengers can overlay historical images onto the current landscape to witness what the area looked like at different historical points in time.

[0069] In one embodiment, the system transforms the vehicle's interior into a highly productive workspace during charging. Occupants can access customized high-productivity applications and tools seamlessly integrated into the vehicle's infotainment system. Tools include popular business software such as word processors, spreadsheets, and presentation software, allowing users to work on documents, presentations, and spreadsheets while waiting for the vehicle to charge. Furthermore, collaborative tools such as video conferencing software, project management platforms, and shared document editors facilitate real-time collaboration with colleagues or clients, allowing occupants to conduct virtual meetings, brainstorming sessions, or project reviews in the comfort of their vehicle. Additionally, the system offers dedicated high-productivity applications tailored to specific industries or professional fields. For example, architecture, engineering, or graphic design professionals can utilize CAD (computer-aided design) software, graphic editing tools, and 3D modeling applications, allowing them to work on designs, sketches, and renderings while in the vehicle. Similarly, entrepreneurs, freelancers, or small business owners can leverage accounting software, invoicing tools, or business management platforms to manage finances, track expenses, or monitor business performance from the convenience of their vehicle. High-productivity tools are seamlessly integrated with the vehicle's navigation system, calendar, and personal assistant features. Crew members can access contextual information, set reminders, or schedule appointments without leaving the high-productivity environment. Furthermore, the system makes full use of voice commands and gesture control, allowing users to perform tasks hands-free.

[0070] In one embodiment, the system enhances the vehicle charging experience by intelligently selecting and transmitting content to the vehicle based on the remaining charging time. The system determines the remaining time until the vehicle's charging process is complete. This determination is facilitated by monitoring the charging progress via the vehicle's charging system. Once the remaining time is established, the method selects and transmits relevant content to the vehicle based on this remaining time. The content selection process considers various factors, such as the preferences and interests of the vehicle occupants. This information is collected through interaction with an app installed in the vehicle, which gathers data on previous content usage, current interests, age, occupation, and other relevant demographics. Based on the collected information, the system selects appropriate video, audio, or game content to share with the occupants during the charging session. Furthermore, the method involves identifying actions performed by the occupants while using the app, particularly in interactive multimedia sessions like games. These actions include choices made during gameplay, such as jumping or fast movement. In response to these actions, the method enables various vehicle functions to enhance the occupant experience. For example, fast movement in a game can trigger an increase in airflow speed, ensuring the occupant feels a rush of air. Similarly, actions like hitting or kicking in a game can induce vibrations or seat movement to simulate the intensity of the game within the vehicle. Furthermore, the method considers scenarios where a game session associated with the application ends prematurely due to the completion of charging processing. The system determines not to initiate another game session based on the updated remaining time. Instead, it can fill the remaining charging time with alternative content, such as streaming news headlines or other short-form content. Additionally, if the game session is not completed, the method ensures that the game session data is forwarded to the user's device for future access. This allows occupants to resume the game on their devices, making full use of cloud server applications that store game archives.

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

[0072] It is important to note that, from Figure 1A , Figure 2C , Figure 2D , Figure 2E and Figure 2FAll resulting flowcharts and corresponding processes can be part of the same process or can share subprocesses with each other, thus allowing these diagrams to 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 are associated with the same physical system and can be used individually or interchangeably.

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

[0074] Figure 2A A vehicle network diagram 200 according to an example embodiment is illustrated. The network includes components, including a vehicle 202 having a processor 204 and a vehicle 202' having 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 occur directly, via private and / or public networks (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 be present. One or more of the applications, features, steps, solutions, etc., described and / or depicted herein may be utilized and / or provided by this component.

[0075] Figure 2B Another vehicle network diagram 210 according to an example embodiment is illustrated. The network includes components including a vehicle 202 having a processor 204 and a vehicle 202' having 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 occur directly, via private and / or public networks (not shown), or via other vehicles and components including one or more of 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 and 204' can also communicate with components including one or more of processors, memory, and software.

[0076] Although depicted as a single vehicle, processor, and element, multiple vehicles, processors, and elements may exist. Information or communication may occur and / or originate from any of processors 204, 204', and element 230. For example, mobile phone 220 may provide information to processor 204, which may activate vehicle 202 to take action; it may further provide such information or additional information to processor 204', which may activate vehicle 202' to take action; and it may further provide such 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.

[0077] Figure 2C A further vehicle network diagram 240 according to an example embodiment is illustrated. The network includes elements including a vehicle 202, a processor 204, and a non-transitory computer-readable medium 242C. The processor 204 is communicatively coupled to the non-transitory 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.

[0078] The processor 204 performs one or more of the following: in 244C, determining the remaining time until the vehicle's charging is complete, and in 246C, transmitting content to the vehicle based on the remaining time.

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

[0080] The processor 204 performs one or more of the following: in 244D, it identifies an application associated with the vehicle occupant's profile and initiates the application while the vehicle is charging and the remaining time is within the duration of the application's usage; in 245D, it identifies one or more actions performed by the occupant while using the application and enables one or more vehicle functions in response to the one or more actions identified in the application; in 246D, one or more vehicle functions include seat movement, changes in air ventilation speed or temperature, changes in lighting control, and changes in the air injector; in 247D, the content transmitted is streaming content of a game associated with the vehicle occupant; in 248D, it determines that the game session associated with the application has prematurely ended at the updated remaining time and determines not to initiate another game session based on the updated remaining time; in 249D, it determines that charging is complete, determines that the game session associated with the application has not ended, and forwards the game session data to the user device.

[0081] 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 computing devices or server computers, etc., 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 other 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 can be a vehicle, a server, or any device with a processor and memory.

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

[0083] 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, executed at a later time, etc.

[0084] Figure 2E A flowchart 260 according to an example embodiment is illustrated. (Reference) Figure 2E This solution includes one or more of the following: determining the remaining time until the vehicle is fully charged in 244E, and transmitting content to the vehicle based on that remaining time in 246E.

[0085] Figure 2F Another flowchart 270 according to an example embodiment is illustrated. (Reference) Figure 2F This solution includes one or more of the following: identifying an application associated with a vehicle occupant's profile in 244F, and launching the application while the vehicle is charging and the remaining time is within the duration of the application's usage; identifying one or more actions performed by the occupant while using the application in 245F, and enabling one or more vehicle functions in response to the one or more actions identified in the application; one or more vehicle functions in 246F including seat movement, changes in air ventilation speed or temperature, changes in lighting control, and changes in the air injector; the content transmitted in 247F is streaming content of a game associated with the vehicle occupant; determining in 248F that the game session associated with the application has prematurely ended at the updated remaining time, and determining not to launch another game session based on the updated remaining time; determining in 249F that charging is complete, determining that the game session associated with the application has not ended, and forwarding the game session data to the user device.

[0086] Technological advancements typically build upon predecessor technologies; this is certainly true of artificial intelligence (AI) models. AI classification systems describe the stages of AI development. The initial classification was called "reactive machines," followed by today's AI classification, "limited-memory machines" (also known as "narrow AI"), then progressing to "theory of mind" (also known as "general AI"), and finally reaching the AI ​​classification "self-aware" (also known as "super AI"). Today's limited-memory machines are an evolving set of AI models built upon their predecessor, the reactive machine. Reactive machines simulate human responses to stimuli; however, their capabilities are limited because they typically cannot learn from previous experiences. Once an AI model demonstrates learning capabilities, its classification is elevated to limited-memory machines. In this current classification, AI models learn from massive 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 categorized 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 that have not yet developed characteristics of machines with limited memory. Generative AI models combine technologies from machines with limited memory, incorporating ML and DL to form the foundational building blocks of future AI models. For example, the 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 fundamental principles of generative AI. Furthermore, as AI models evolve into the "self-aware" category, they will be able to understand and evoke the emotions of the entities with which they interact, possessing their own emotions, beliefs, and needs—all relying on the fundamental principle of generative AI: learning from experience to generate and derive conclusions about themselves and their surroundings. Generative AI models are a core component of future artificial intelligence models. As discussed in this article, generative AI refers both to generative AI models of today and to AI models of the future.

[0087] Figure 3A The diagram 300A illustrates an AI / ML network supporting AI-assisted decision-making for vehicles or occupants. 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 also be employed in 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 algorithms can be used.

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

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

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

[0091] 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 transmit data to a database 320 that stores data about the vehicle and its occupants. In some embodiments, these sensors 312 transmit data to one or more decision subsystems 316 within vehicle node 310 to assist in decision-making.

[0092] 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 within vehicle node 310 to assist in decision-making.

[0093] Vehicle node 310 may include one or more decision subsystems 316, which drive decision processing surrounding, but not limited to, vehicle control, temperature control, charging control, etc. In some embodiments, decision subsystem 316 collects data from one or more sensors 312 to assist decision processing. In some embodiments, decision subsystem 316 may collect data from one or more UIs 314 to assist decision processing. In some embodiments, decision subsystem 316 may provide feedback to UI 314.

[0094] The decision subsystem 316 in vehicle node 310 can use the AI / ML production system 330 to assist 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, and UI prompts. 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 ​​production system resides in vehicle node 310.

[0095] 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 and executes on a 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.

[0096] 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 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.

[0097] Figure 3BThe illustration depicts a process 300B for developing one or more AI / ML models that support AI-assisted vehicle or occupant decision points. 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 imported 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.

[0098] Once the required data has been extracted 342, it must be prepared 344 for model training. In some embodiments, this step involves performing statistical tests on the data to examine its degree of reflection of real-world events, its distribution, data diversity in the dataset, etc. In some embodiments, the results of the statistical tests may lead to the application of one or more data transformations to normalize one or more values ​​in the dataset. In some embodiments, this step includes cleaning data that is 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 a manual process or an automated process using one or more of the elements or functions described or depicted herein.

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

[0100] The dataset output from feature extraction step 346 is split into a training dataset and a validation dataset. 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.

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

[0102] AI / ML model 332 is evaluated 352 in a pre-release (staging) 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 unseen validation datasets are used. In some embodiments, the pre-release environment is part of the AI / ML development system 340. In other embodiments, the pre-release environment is managed independently of the AI / ML development system 340. Once 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 before, in some embodiments, model evaluation step 352 is either handled manually or automatically using one or more of the elements or functions described or depicted herein.

[0103] 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, the AI / ML production system 330 provides feedback data on the AI / ML model 332 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 repeat steps 342-354 to update the AI / ML model 332 using updated data from one or more data sources.

[0104] Figure 3C The illustration depicts a processing unit 300C used to utilize an AI / ML model that supports AI-assisted vehicle or occupant decision-making points. As previously stated, the AI ​​model illustrated herein utilizes processing that reflects ML as a specific branch of AI, but this solution is not limited to ML, nor is it limited to any AI algorithm or combination of algorithms.

[0105] refer to Figure 3CThe decision subsystem 316 in vehicle node 310 can use the AI / ML production system 330 to assist 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, the request may include an identifier of the 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, the request includes a data payload (e.g., data to be input into the model during execution). 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 some embodiments, one or more components or nodes 320, 330, 340, or 360 may be located within vehicle node 310.

[0106] Upon receiving API 334, AI / ML server process 336 may need to transform the data payload or a portion thereof into valid feature values ​​for AI / ML model 332. Data transformation may include, but is not limited to, combining data values, normalizing data values, and enriching the incoming data using data from other data sources. Once any required data transformation occurs, AI / ML server process 336 executes the appropriate AI / ML model 332 using the transformed input data. After receiving the execution result, AI / ML server process 336 responds to the API caller, decision subsystem 316, acting as the vehicle node 310. In some embodiments, the response may cause UI 314 in vehicle node 310 to update. In some embodiments, the response includes a request identifier that decision subsystem 316 can later use to provide feedback on the performance of AI / ML model 332. Additionally, in some embodiments, AI / ML server process 336 may log immediate performance feedback to model feedback log 338. In some embodiments, model execution failure is the cause of the immediate feedback.

[0107] In some embodiments, API 334 includes an interface for providing feedback to AI / ML model 332 after the AI / ML model 332's 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's results. For example, if AI / ML model 332 provides an estimated arrival time of 20 minutes, but the actual travel time is 24 minutes, this can be indicated. In some embodiments, the feedback interface includes an identifier for 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 this model feedback log 338 is provided to model performance monitoring 356 in AI / ML development system 340. In one embodiment, this log data is streamed to AI / ML development system 340. In some embodiments, the log data is provided upon request.

[0108] The AI / ML processing described herein can utilize multiple steps / features including one or more of the following: determining the remaining time until the vehicle's charging is complete; transmitting content to the vehicle based on the remaining time; identifying an application associated with the vehicle's occupant profile and initiating the application while the vehicle is charging, provided the remaining time falls within the duration of the application's usage; identifying one or more actions performed by the occupant while using the application and enabling one or more vehicle functions in response to the identified actions, including seat movement, changes in air ventilation speed or temperature, changes in lighting control, and changes in the air injector, wherein the transmitted content is streaming content of a game associated with the vehicle's occupant; determining that the game session associated with the application has prematurely ended at the updated remaining time and determining not to initiate another game session based on the updated remaining time; determining that charging is complete; determining that the game session associated with the application has not completed; and forwarding the game session data to the user device.

[0109] Data associated with any of these steps / features, and any other features or functions described or depicted herein, AI / ML Production System 330 and Figure 3C One or more of the other elements depicted herein can be used to process this data in pre-transformation and / or post-transformation processes. Data associated with this processing can be used by vehicle node 310. In one embodiment, data associated with this processing can be used with a charging station / charging point, server, wireless device, and / or any processor described or depicted herein.

[0110] Figure 3DThe illustration depicts the process 300D of designing a new machine learning model via a system user interface 370 according to an example embodiment. As an example, the model can be output as part of an AI / ML development system 340. (Reference) Figure 3D Users can use the input mechanism in menu 372 of user interface 370 to add pieces / components to the model being developed in workspace 374 of user interface 370.

[0111] 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 connecting them using edges or other elements 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 example, a user can connect node 376 to another node in the graph via edge 378, thus creating dependencies within the graph. When the user is finished, they can save the model for subsequent training / testing.

[0112] In another example, the name of an 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. A pop-up window within the browser or workspace 374 can be overlaid where the object is visible, and this pop-up window includes an option to navigate via a set of rules to the identified webpage corresponding to the candidate object.

[0113] Figure 3E The illustration depicts a process 300E of 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 of tests, training results, etc. Object storage device 390 may also store any other kind 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 later extracted 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.

[0114] Unlike file systems that divide files into blocks stored on disk, object storage device 390 treats objects as discrete units of data stored in a structurally flat data environment. Here, object storage devices may not use folders, directories, or complex hierarchical structures. Instead, each object can be a simple, self-contained repository that includes data, metadata, and a unique identifier that client applications can use to locate and access the object. In this case, metadata is more descriptive than a file-based approach. Metadata can be customized using additional context, which can later be extracted and used for other purposes, such as data analysis.

[0115] 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). Client applications can use API 384 to query the metadata of objects to locate the desired object (data) from anywhere on any device via the Internet. API 384 can use HTTP commands such as "PUT" or "POST" to upload objects, "GET" to retrieve objects, "DELETE" to remove objects, and so on.

[0116] Object storage device 390 can 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 can submit commands, such as HTTP commands, containing the identifier, payload, etc., of object 392. Object storage device 390 can store the actions and results described herein, including associating two or more ranked asset lists with each other based on a correlation between variables used by the two or more ranked asset lists having a correlation above a predetermined threshold.

[0117] Figure 4AFigure 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 in turn may be coupled to one or more vehicles 408B. This configuration allows for the distribution of electricity / power received from vehicle 402B. Vehicle 402B can also interact with one or more other vehicles 408B, such as via V2V technology, cellular communication, Wi-Fi, etc. Vehicle 402B can also wirelessly and / or wiredly interact with other vehicles 408B, one or more charging stations 406B, and / or with one or more power grids 404B. In one example, vehicle 402B is routed (or routes itself) safely and efficiently to one or more power grids 404B, one or more charging stations 406B, or one or more other vehicles 408B. Using one or more embodiments of this solution, vehicle 402B can supply energy to one or more of the elements depicted herein in various advantageous manners as described and / or illustrated herein. Additionally, vehicle safety and efficiency can be increased, and a positive environmental impact can be achieved as described and / or illustrated herein.

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

[0119] In one example, charging station 406B manages the amount of energy transferred from vehicle 402B such that vehicle 402B has sufficient remaining charge to reach its destination. In one example, a certain amount of energy is wirelessly guided between vehicles 408B using a wireless connection, where the vehicles may all be in motion. In one embodiment, wireless charging may be performed via a stationary charger and vehicle batteries aligned with each other (such as charging pads in a garage or parking space). In one example, an idle vehicle (such as vehicle 402B, which may be an autonomous vehicle) 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, remaining energy is collected from at least one other vehicle 408B using a mobile energy storage unit (not shown) and the stored remaining energy is transferred to charging station 406B. In one example, several factors determine the amount of energy transferred to charging station 406B, such as distance, time, and traffic conditions, road conditions, environmental / weather conditions, vehicle condition (weight, etc.), the schedules of one or more occupants using the vehicle, the schedules of potential one or more occupants 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.

[0120] In one embodiment, a location (not shown), such as a building, residence, etc., is communicatively coupled to one or more of a power grid 404B, a vehicle 402B, and / or one or more charging stations 406B. Depending on external conditions such as weather, the current rate flowing to that location, vehicle 402B, or one or more other vehicles 408B is modified. For example, when the external temperature is extremely hot or cold, increasing the likelihood of a power outage, the current flowing to the connected vehicles 402B / 408B is slowed to help minimize the possibility of a power outage.

[0121] 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 assist in supplying power to and / or reducing power consumption of the grid 404B when grid pressure is excessive. Bidirectional vehicles participate in bidirectional charging, receiving and charging themselves while also transferring energy from the vehicle to the grid 404B, also known as “V2G”. In bidirectional charging, electricity flows in both directions: into and out of 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. Energy is converted from DC to AC by a converter (also known as a bidirectional charger) typically located in the charging station 406B. Additionally, as per [reference to...] Figure 4B The solution described and depicted can be used in this and other networks and / or systems.

[0122] Figure 4B Figure 400B illustrates the interconnections between different components. This solution can be wholly 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 of which are communicatively coupled to and communicate 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 residences 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, may also interoperate with this solution. Smartphones 412C, laptops 420C, microphones 440C, and other devices may connect to one or more of networked 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 use computing devices 424C. One or more service providers 416C may include dealerships, towing services, collision repair centers, or other repair shops. One or more service providers 416C may use computing devices 418C. These various computing devices may be directly and / or communicatively coupled to each other, such as via wired networks, wireless networks, blockchain networks, etc. In one example, microphone 440C may be used as a virtual assistant. In one example, one or more traffic infrastructure 426C may include one or more traffic lights, one or more sensors (including one or more cameras, vehicle speed sensors, or traffic sensors), and / or other traffic infrastructure. One or more traffic infrastructure 426C may use computing device 428C.

[0123] In one embodiment, whenever charge is given 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 that is communicatively coupled to the vehicle, the charging station, and the power grid.

[0124] 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, sport utility vehicle (SUV), truck, bus, van, or other vehicle powered by an engine or battery or fuel cell. For example, vehicle 404C / 408C can be an electric vehicle, hybrid vehicle, hydrogen fuel cell vehicle, plug-in hybrid vehicle, or any other type of vehicle equipped with a fuel cell stack, motor, and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, ships, and any other form of transportation capable of transporting people. Vehicle 404C / 408C can be semi-autonomous or autonomous. For example, vehicle 404C / 408C can self-operate and navigate without human input. Autonomous vehicles can have and use one or more sensors and / or navigation units from the primary driver. All data described or depicted herein can be obtained from... Figure 4B One or more of the components in the system are used for storage, analysis, processing, and / or forwarding.

[0125] Figure 4C This is another block diagram illustrating the interconnections between different components in an example 400C. A vehicle 412D is presented, and it includes ECUs 410D, 408D, and a head unit (also known as an infotainment system) 406D. An ECU is an embedded system in the automotive electronic system that controls one or more of the electrical systems or subsystems in the vehicle. ECUs may include, but are not limited to, the 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 processor / sensor (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 head unit 406D may contain its own security policy. The security policy defines the permitted 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.

[0126] ECUs 410D, 408D, and head unit 406D may each include a custom safety function element 414D that defines authorized processes and the contexts in which these processes are permitted to run. Context-based authorization, used to determine the validity of a process's execution, allows the ECU to maintain safe operation and prevent 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 automotive ECU can use various contexts to determine whether a process is operating within its permitted boundaries, such as proximity context, nearby objects, distance to the approaching object, speed, and trajectory relative to other moving objects; and operational contexts, such as whether the vehicle is moving or parked, the vehicle's current speed, and indications of transmission status; user-related contexts, such as devices connected to the vehicle via wireless protocols, use of the infotainment system, cruise control, parking assistance, and driver assistance; location-based contexts; and / or other contexts.

[0127] refer to Figure 4D An operating environment 400D for a connected vehicle is illustrated according to some embodiments. As shown, vehicle 410E includes a CAN bus 408E connecting vehicle components 412E-426E. Other components may be connected to the CAN bus and are not shown herein. Components connected to the CAN bus that are shown include sensor set 412E, electronic control unit 414E, autonomous features or advanced driver assistance systems (ADAS) 416E, and navigation system 418E. In some embodiments, vehicle 410E includes processor 420E, memory 422E, communication unit 424E, and electronic display 426E.

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

[0129] Memory 422E is a non-transitory memory that stores instructions or data that can be accessed and executed by processor 420E. These 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 another type of 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, optical 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 permanently storing information. A portion of memory 422E may be reserved for use as a buffer or virtual random access memory (virtual RAM). Vehicle 410E may include one or more memories 422E without departing from the current solution.

[0130] The memory 422E of vehicle 410E can store one or more of the following types of data: navigation route data 418E and autonomous feature data 416E. In some embodiments, memory 422E stores data that may be needed for the functions provided by navigation application 418E.

[0131] 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 directions) 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.

[0132] ECU 414E controls the operation of multiple 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 a journey controlled by ADAS system 416E. In this way, navigation system 418E can control whether ADAS system 416E is activated or enabled, allowing it to be activated for a given navigation route.

[0133] Sensor set 412E may include any sensor in vehicle 410E that generates sensor data. For example, sensor set 412E may include short-range and long-range sensors. In some embodiments, sensor set 412E of vehicle 410E may include one or more of the following vehicle sensors: camera, light detection and ranging (LiDAR) sensor, ultrasonic sensor, automotive 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 sensor, defect detector, Hall effect sensor, parking sensor, radar speed gun, speedometer, speed sensor, tire pressure monitoring sensor, torque sensor, transmission oil temperature sensor, turbo speed sensor (TSS), variable reluctance sensor, vehicle speed sensor (VSS), water sensor, wheel speed sensor, global positioning system (GPS) sensor, mapping function, and any other type of automotive sensor. The navigation system 418E can store sensor data in the memory 422E.

[0134] Communication unit 424E transmits and receives data with network 402E or other communication channels. 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.

[0135] 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 the area where other vehicles 406E are located based on the sensed radar information; 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 the GPS information of the target vehicle based on the calculated probability.

[0136] To ensure adequate vehicle security, unauthorized physical access and unauthorized remote access (e.g., cyber threats) must be prevented. 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 with the vehicle.

[0137] An ECU (Electronic Control Unit) is a node within a vehicle that controls tasks ranging from activating windshield wipers to functions like anti-lock braking systems. ECUs are often interconnected via the vehicle's central network, which may be referred to as a Controller Area Network (CAN). Existing technological features such as autonomous driving heavily rely on the implementation of new, complex ECUs, such as ADAS (Advanced Driver Assistance Systems) and sensors. While these new technologies help improve vehicle safety and the driving experience, they also increase the number of units communicating between the vehicle's interior and exterior, making it more vulnerable to attack. Below are some examples of protecting vehicles from physical and remote intrusion.

[0138] 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 the need for a host computer. The CAN bus implements a message-based protocol (e.g., 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.

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

[0140] To protect the CAN bus from cyber threats, various security protocols can be implemented. For example, the CAN bus can be divided into smaller sub-CANs using sub-networks (e.g., sub-networks A and B, etc.), restricting an attacker's ability to remotely access the vehicle. In one embodiment, a firewall (or gateway, etc.) can be added to prevent messages from crossing the CAN bus between sub-networks. If an attacker gains access to one sub-network, they will not have access to the entire network. To further secure the sub-networks, in one example, the most critical ECUs are not placed on the same sub-network.

[0141] 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 benefit of connecting a vehicle to a data source such as the Internet is that information from the vehicle can be transmitted over the network to a remote location for analysis. Examples of vehicle information include GPS, on-board diagnostics, tire pressure, etc. These communication systems are often referred to as telematics because they involve a combination of telecommunications and information technology. Furthermore, the solution described and depicted herein can be used with this and other networks and / or systems, including those described and depicted herein.

[0142] Figure 4E The illustration shows an example 400E of vehicles 402I and 408I performing secure V2V communication using a security certificate, according to an example embodiment. (Reference) Figure 4E Vehicles 402I and 408I can communicate via V2V communication through short-range networks, cellular networks, etc. Before sending a message, vehicles 402I and 408I can sign the message using appropriate public key certificates. 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.

[0143] After 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, then 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. Additionally, as regarding... 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.

[0144] In some embodiments, the computer may include a security processor. Specifically, the security processor can perform authorization, authentication, and cryptographic techniques (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 a cryptographic technique module. The security processor can be implemented within the vehicle's computer and can communicate with other vehicle components (e.g., 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 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 the vehicle's computer via wired attachments.

[0145] 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 specific 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 expects to change vehicle settings or modify technical details of the vehicle via the in-vehicle console or GUI or via attached / connected devices, the authorization module can require the user to verify themselves in some way before making such changes. For example, the authorization module can request a username, password, PIN code, biometric scan, predefined line drawings, or gestures, etc. In response, the authorization module can determine whether the user has the necessary permissions (access, etc.) requested.

[0146] 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 transmit a bit signature algorithm to the ECUs on the CAN network. The ECUs can use this algorithm to insert authentication bits into the CAN field of a CAN frame. All ECUs on the CAN network typically receive each CAN frame. Each time a new CAN frame is generated by one of the ECUs, 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.

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

[0148] Figure 5A The illustration shows an example vehicle configuration 500A for managing database transactions associated with a vehicle, according to an example embodiment. Reference Figure 5A When a specific vehicle 525A engages in a transaction (e.g., vehicle service, dealership transaction, delivery / pickup, transportation service, etc.), the vehicle can receive assets 510A and / or release / transfer assets 512A according to one or more transactions. A vehicle processor 526A resides in the vehicle 525A, and communication exists between the vehicle processor 526A, the database 530A, and the transaction module 520A. The transaction module 520A can record information such as assets, participants, amounts, service descriptions, dates, times, locations, results, notifications, and unexpected events. These transactions in the transaction module 520A can be replicated to the database 530A. The database 530A can be one of the following: an SQL database, a relational database management system (RDBMS), a relational database, a non-relational database, a blockchain, or a distributed ledger. It can be located on the vehicle, outside the vehicle, directly accessible and / or accessed via a network, or accessible by the vehicle itself.

[0149] In one embodiment, when a vehicle reaches a point where it needs to share a service with another vehicle, it can engage with that vehicle to perform various actions such as sharing, transferring, or requesting a service call. For example, the vehicle may need to charge its battery, and / or may have a tire problem, and may be on its way to pick up a package for delivery. A vehicle processor resides in the vehicle, and communication exists between the vehicle processor, a first database, and a transaction module. The vehicle can notify another vehicle located in its network and operating on its blockchain member service. A vehicle processor resides in another vehicle, and communication exists between that vehicle processor, a second database, the vehicle processor, and the transaction module. The other vehicle can then request to receive information via wireless communication to perform a package retrieval from the vehicle and / or from a server (not shown). Transactions are recorded in the transaction modules of both vehicles. Credit is transferred from one vehicle to another, and the record of the service transfer is recorded in the first database, assuming the blockchains are different from each other, or recorded in the same blockchain used by all members. The first database can be one of an SQL database, RDBMS, relational database, non-relational database, blockchain, or distributed ledger, and can be located on the vehicle, outside the vehicle, and can be directly accessed and / or accessed via a network.

[0150] Figure 5B The diagram illustrates a blockchain architecture configuration 500B according to an example embodiment. (Reference) Figure 5B The blockchain architecture 500B may include certain blockchain elements, such as a group of blockchain member nodes 502B-505B as part of blockchain group 510B. In one example embodiment, the permissioned blockchain is not accessible to all parties, but only to those members with permitted access rights to the blockchain data. Blockchain nodes participate in many activities, such as blockchain entry addition and verification processes (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 attempt to write to the immutable blockchain ledger stored in the blockchain, and copies of this ledger may also be stored on the underlying physical infrastructure.

[0151] When a blockchain transaction 520B is received and approved by the consensus model defined by the member nodes, the transaction is stored in the computer's memory. The approved transaction 526B is stored in the current block of the blockchain and submitted to the blockchain via a submission process that includes hashing the data content of the transactions in the current block and referencing previous hashes from previous blocks. Within the blockchain, one or more smart contracts 530B can exist, whose definitions include the terms of transaction protocols and actions in the smart contract executable application code 532B, such as registered recipients, vehicle characteristics, requests, permissions, sensor thresholds, etc. This code can be configured to identify whether requesting entities are registered to receive vehicle services, which service characteristics they are entitled to / required 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 a parameter (such as the vehicle's charge level) can be identified as being above / below a specific threshold for a specific time period. The result might 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.) so that the service can be identified and stored for reference. The collected vehicle sensor data can be based on the type of sensor data used to collect information about the vehicle's condition. Sensor data can also form the basis of vehicle event data 534B, such as the location(s) to be traveled, average speed, maximum speed, acceleration rate, whether there has been any collision, whether the expected route has been taken, the next destination, whether safety measures are in place, whether the vehicle has sufficient charge / fuel, etc. All this information can serve as the basis for smart contract terms 530B and then be stored in the blockchain. For example, sensor thresholds stored in the smart contract can be used as the basis for determining whether a detected service is necessary and when and where the service should be performed.

[0152] In one embodiment, an example of blockchain logic includes a blockchain application interface, which serves as an application programming interface (API) or plug-in application linked to computing devices and execution platforms for specific transactions. The blockchain configuration may include one or more applications that link to the API to access and execute stored program / application code (e.g., smart contract executables, smart contracts, etc.) that can be created based on 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.

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

[0154] A blockchain platform can include blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and various layers of underlying physical computer infrastructure that can be used to receive and store new entries and provide access to auditors seeking access to data entries. The blockchain can expose interfaces that provide access to the processing code and the virtual execution environment required to interface with the physical infrastructure. Cryptographic trust services can be used to verify entries such as asset exchange entries and keep information confidential.

[0155] Figure 5A and Figure 5B The blockchain architecture configuration can process and execute program / application code through one or more interfaces and services exposed by the blockchain platform. As a non-limiting example, smart contracts can be created to execute alerts, updates, and / or other notifications based on changes, updates, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and the use of the ledger. For example, this information may include a new entry, which can be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. The result may include deciding to reject or approve the new entry based on criteria defined in the smart contract and / or the consensus of the peers. Any data or information described herein can be retrieved using physical infrastructure.

[0156] Within the executable code of a smart contract, smart contracts can be created using high-level applications and programming languages ​​and then written into blocks on a blockchain. Smart contracts can 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 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 one or more trusted modifications to the state of the digital blockchain ledger. The 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.

[0157] 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. The 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 provisioned execution environment and is then deleted once the data required by the blockchain is identified.

[0158] Smart contract executable code can include a code interpretation of the smart contract, as well as 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 consensus processing. The smart contract executable code receives hashes and retrieves hashes from the blockchain 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, then 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.

[0159] Figure 5C The illustration depicts a blockchain configuration for storing blockchain transaction data according to an example embodiment. (Reference) Figure 5C Example configuration 500C provides information sharing with the distributed ledger (i.e., blockchain) 568C for the vehicle 562C, user equipment 564C, and server 566C. The server can represent a service provider entity that, in the event that a known and established user profile is attempting to lease a vehicle with an established rating profile, queries the vehicle service provider to share user profile rating information. Server 566C may be receiving and processing data related to vehicle service requests. As 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 570C is stored for each transaction, such as access events, subsequent updates to the vehicle service status, event updates, etc. The transaction may include the parties, requirements (e.g., age 18, eligible candidates, valid driver's license, etc.), compensation level, distance traveled during the event, recipient of registration to allow access to the event and preside over vehicle service, permissions / permissions, sensor data retrieved during vehicle event operations, recording details of the next service event and operations to identify the condition of the vehicle, and thresholds for determining whether the service event has been completed and whether the condition of the vehicle has changed.

[0160] Figure 5D The illustration shows blockchain blocks that can be added to a distributed ledger according to an example embodiment, and the contents of block structures 582A to 582n. (Reference) Figure 5D A client (not shown) can submit an entry to a blockchain node to implement an activity on the blockchain. As an example, the client could act on behalf of a requester (such as a device, individual, or entity) to propose the application of an entry to 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 may exist in a blockchain network, including endorsing peers that simulate and endorse entries proposed by clients, and committing peers that verify endorsements, validate entries, and submit them to the distributed ledger. In this example, a blockchain node could act as an endorser node, a committer node, or both.

[0161] 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 for which it is a member. This blockchain is an entry log structured as hashed, linked blocks, where each block contains a sequence of N entries. Blocks can include various components, such as... Figure 5D The components shown are linked. Blocks can be linked by adding a hash of the previous block's header to the current block's 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 arrived before it. This blockchain can be stored on a peer-to-peer file system (local or attached storage) that supports only attached blockchain workloads.

[0162] The current state of a blockchain and distributed ledger can be stored in a state database. Here, the current state data represents the latest value of all keys ever contained 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 extremely efficient, the latest values ​​of all keys are stored in the state database. The state database can include an indexed view of the blockchain's entry log, so it can be regenerated from the chain at any time. The state database can be automatically restored after a peer starts but before accepting entries (or generated when needed).

[0163] Endorsing nodes receive entries from clients and endorse them based on the mock results. The endorsing node holds the smart contract that proposed the mock entry. When an endorsing node endorses an entry, it creates an entry endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the mock entry. The method of endorsing entries depends on the endorsement policy, which can be specified in 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 client application forwards the endorsed entries to a sorting service.

[0164] The ordering service accepts endorsed entries, sorts them into blocks, and delivers these blocks to submitting 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 node is the submitting peer, which has 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 a shared ledger. Instead, it accepts endorsed entries and specifies the order in which those entries are submitted to the distributed ledger. The architecture of the blockchain network can be designed so that the specific implementation of "ordering" is a pluggable component.

[0165] Entries are written to the distributed ledger in a consistent order. Establishing the order of entries ensures that updates to the state database are valid when they are committed to the network. Unlike cryptocurrency blockchain systems where ordering is achieved through solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger can choose the ordering mechanism best suited to the network.

[0166] refer to Figure 5DBlock 582A (also known 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 depicted, 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 the block header 584A and the block metadata 588A may be smaller than the transaction-specific data 586A that stores entry data; however, this is not required. 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 hashes of the headers of previous blocks. Block header 584A may also include a unique block number, a hash of block data 590A of the current block 582A, etc. The block number of block 582A can be unique and assigned in an ascending / continuous order starting from zero. The first block in the blockchain can be called the genesis block, which includes information about the blockchain, its members, and the data stored within it.

[0167] 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 functionality), 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, key list, Merkel tree query digest, etc. Entry data can be stored for each of N entries.

[0168] In some embodiments, block data 590A may also store transaction-specific data 586A, which adds additional information to the blockchain of hash-linked blocks in the blockchain. Thus, data 586A can be stored in the immutable log of blocks on a 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, the last persistent offset of the sorting service that sorts the blocks, etc. The signature, the last configured block, and the 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.

[0169] Other blocks 582B to 582B in the blockchain n It also has a header, filename, and value. However, unlike the first block 582A, the headers in the other blocks are 584A to 584. n Each block in the remaining blocks includes the hash value of the preceding block. The hash value of the 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 of the remaining blocks, a block-by-block tracing from the Nth block to the genesis block (and the associated original file) can be performed, as indicated by arrow 592, to establish an auditable and immutable chain of custody.

[0170] Figure 5E The illustration shows the process 500E of adding a new block to the distributed ledger 520E according to an example embodiment, and... Figure 5D The illustration shows an example embodiment. Figure 5E The content of the new data block structure 530E of the 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 perform an activity on blockchain 522E. As an example, the client can be an application that submits a transaction to the blockchain on behalf of a requester (such as a device, person, or entity). 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 may exist in the blockchain network, including endorsement peers that simulate and endorse transactions submitted by clients, and submission peers that verify endorsements, validate transactions, and submit transactions to the distributed ledger 520E. In this example, blockchain nodes 511E, 512E, and 513E can perform the roles of endorsement node, submission node, or both.

[0171] 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 for which it is a member. Blockchain 522E is a transaction log structured as a hashed chain of blocks, where each block contains a sequence of N transactions. A chain of blocks is generated by appending the hash of the previous block's header to the current block's 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, thus 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 only attached blockchain workloads.

[0172] 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 contained 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 extremely 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, so it can be regenerated from the chain at any time. State database 524E can be automatically restored after peer initiation but before transactions are accepted (or generated when needed).

[0173] Endorsing nodes receive transactions from clients and endorse them based on the simulation results. The endorsing node holds a smart contract containing the simulated 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 indicating its endorsement of 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 client application forwards the endorsed transaction to the ordering service 510E.

[0174] The ordering service 510E accepts endorsed transactions, orders them into blocks, and delivers these blocks to submitting peers. For example, the ordering service 510E can initiate a new block when a transaction threshold is reached, a timer times out, or another condition is met. Figure 5E In the example, blockchain node 512E is the submitting peer, which 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 therein, and so on.

[0175] The ordering service 510E can consist of a cluster of orderers. The ordering service 510E does not process transactions, smart contracts, or maintain a shared ledger. Instead, the 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.

[0176] Transactions are written to the distributed ledger 520E in a consistent order. Establishing this order ensures that updates to the state database 524E are valid when they are submitted to the network. Unlike cryptocurrency blockchain systems where ordering is achieved 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.

[0177] When the sorting service 510E initializes a new data block 530E, this new data block 530E can be broadcast to submitting peers (e.g., blockchain nodes 511E, 512E, and 513E). In response, each submitting peer verifies the transactions within the new data block 530E to ensure that the read and write sets still match the current world state in the state database 524E. Specifically, the submitting peers can determine whether the read data present when the endorsing node simulates a transaction is the same as the current world state in the state database 524E. After the submitting 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-write sets. If a transaction fails—that is, if the submitting peers find that the read-write sets do not match the current world state in the state database 524E—the transaction 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.

[0178] refer to Figure 5F 500F, a new data block 530 (also called a data block) stored on 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 recognized that... Figure 5F The various depictions of blocks and their contents shown (such as new data block 530 and its contents) are merely examples and are not intended to limit the scope of the exemplary embodiments. New data block 530 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within block data 550. New data block 530 may also include (e.g., ...) transactions within the block header 540. Figure 5E The block header 540 can include a link to previous blocks (on blockchain 522E). Specifically, the block header 540 may include a hash of the headers of previous blocks. 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 can be unique and can be assigned in various orders, such as an ascending / continuous order starting from zero.

[0179] Block data 550 can store transaction information for each transaction recorded within the new data block 530. For example, transaction data may include the transaction type, version, timestamp, and channel ID of the distributed ledger 520E. Figure 5EThe chaincode can be stored for one or more of the following: transaction ID, period, 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 event, 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, key list, Merkel tree query digest, etc. Transaction data can be stored for each of N transactions.

[0180] In one embodiment of this solution, blockchain data 563 may include data containing one or more of the following: determining the remaining time until the vehicle is fully charged; and transmitting content to the vehicle based on the remaining time.

[0181] Although Figure 5F In this context, blockchain data 563 is described as being in block data 550, but it could also be located in the block header 540 or block metadata 560.

[0182] Block metadata 560 can store multiple fields of metadata (e.g., as byte arrays). Metadata fields may include the 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 the last persisted offset of the sorting service that sorts the blocks, etc. The signature, the last configured block, and the sorter metadata can be provided by... Figure 5E The sorting service was added in 510E. At the same time, the block submitters (such as...) Figure 5E Blockchain nodes (512E) can add validity / invalidity information based on endorsement policies, read / write set verification, etc. Transaction filters can include byte arrays of size equal to the number of transactions in the block data and verification codes that identify whether a transaction is valid / invalid.

[0183] The above embodiments can be implemented in hardware, with a computer program executed by a processor, with firmware, or with a combination thereof. The computer program can be implemented 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, optical disc read-only memory (“CD-ROM”), or any other form of storage medium known in the art.

[0184] 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 with 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 The illustration shows an example computer system architecture 600, which can be represented or integrated into any of the components mentioned above.

[0185] Figure 6 The illustration depicts a computing environment according to an example embodiment. Figure 6 This is not intended to imply any limitation on the use or scope of 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, computing system 601 can operate within a variety of other general-purpose or special-purpose computing system environments or configurations.

[0186] The computing system 601 can 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 above systems or devices, 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 performance of the computer-implemented method can be distributed across multiple computers and multiple locations. However, in this description of the computing environment 600, for the sake of simplicity, the detailed discussion will focus on a single computer, specifically the computing system 601.

[0187] The computing system 601 can be located in the cloud, even if it is in Figure 6 The computing system 601 is not shown in the cloud. On the other hand, the computing system 601 is not necessarily located in the cloud unless explicitly indicated otherwise. The computing system 601 can be described in the general context of computer system executable instructions (such as program modules) executed by the computing system 601. Generally, program modules can include routines, programs, objects, components, logic, data structures, etc., that perform tasks or implement certain abstract data types. Figure 6 As shown, the computing system 601 in the computing environment 600 is illustrated in the form of a general-purpose computing device. Components of the computing 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 processing unit 602.

[0188] Processing unit 602 includes one or more computer processors of any type now known or to be developed in the future. 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 a type of memory that may be located within the processor chip package(s) or may be located "off-chip," such as... Figure 6 As illustrated 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.

[0189] Network adapter 603 enables computing system 601 to connect to 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 packing and / or unpacking data for communication network transmission. 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 radio standards.

[0190] Computing system 601 may include 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"). One or more data interfaces may connect it to bus 620. In embodiments where computing system 601 requires a large amount of storage (e.g., where computing system 601 stores and manages a large database locally), this storage may be provided by storage device 610 designed for storing massive amounts of data (such as a storage area network (SAN) shared by multiple geographically distributed computers).

[0191] Operating system 611 is software that manages the hardware resources of computing system 601 and provides general services to computer programs. Operating system 611 can take several forms, such as various known proprietary operating systems or operating systems using open-source portable operating system interface types with kernels.

[0192] Bus 620 represents one or more of several types of bus architectures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using various bus architectures. As an example and without limitation, such architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus. Bus 620 is a signal transmission path that allows various components of computing system 601 to communicate with each other.

[0193] Memory 630 is any volatile memory now known or developed in the future. Examples include dynamic random access memory (RAM 631) or static RAM 631. Typically, volatile memory is characterized by random access, but this characteristic is not essential unless explicitly indicated otherwise. In computing system 601, memory 630 is located in a single package and within computing system 601, but alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally relative to computing system 601. As an example, memory 630 may be provided for reading and writing from non-removable non-volatile magnetic media (shown as storage device 610 and commonly referred to as a "hard disk"). 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 computing 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 from processing unit 602 to speed up processing time. Computing 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 the Basic Input / Output System (BIOS) and information required to boot operating system 611.

[0194] The computing system 601 can also communicate with one or more peripheral devices 641 via an input / output (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 the computing system 601; and / or any device that enables the computing system 601 to communicate with one or more other computing devices (e.g., a network interface card, modem, etc.). This communication can be performed via the I / O interface 640. As illustrated, the I / O interface 640 communicates with other components of the computing system 601 via a bus 620.

[0195] Network 650 is any computer network capable of receiving and / or transmitting 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 fibers, wireless transmission devices, routers, firewalls, switches, gateway computers, and edge servers, as well as network infrastructure now known or to be developed in the future. Computing system 601 is connected to network 650 via network adapter 603 and bus 620.

[0196] User equipment 651 is any computer system used and controlled by an end user when connected to computing system 601. For example, assuming that computing system 601 is designed to provide advice to an end user, this advice can typically be transmitted from network adapter 603 of computing system 601 to user equipment 651 via network 650, allowing user equipment 651 to display or otherwise present the advice to the end user. User equipment can be a wide variety of devices, including personal computers (PCs), laptops, tablets, handheld devices, mobile phones, etc.

[0197] Remote server 660 is any computer that provides at least some data and / or functionality to computing system 601 via network 650 (e.g., WAN, Virtual Private Network (VPN), private cloud, or via the Internet). These networks 650 may communicate with a LAN to contact users. The user interface may include a web browser or an application that facilitates communication between the user and remote data. Such applications are referred to as “thin” desktops or “thin clients.” Thin clients are typically incorporated into software programs that emulate desktop sessions. 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 installed locally on remote server 660, other remote servers 660, user device 651, or computing system 601.

[0198] Public cloud 670 is a provisionable computing system resource, including data storage and computing power, that does not require direct user management. Public cloud 670 is typically distributed, with data centers located in multiple locations to ensure availability and performance. Computing resources on the public cloud (670) are shared among multiple tenants through virtual computing environments, including virtual machines 671, databases 672, containers 673, and other resources. Containers 673 are isolated, lightweight software used to run applications on the host operating system 611. Containers 673 are built on top of the host operating system kernel and contain only applications and some lightweight operating system APIs and services. In contrast, virtual machines 671 are a software layer that includes the complete operating system 611 and kernel. Virtual machines 671 are built on top of a hypervisor emulation layer, which is designed to abstract the host computer's hardware from the operating software environment. Public cloud 670 typically provides managed databases 672, thus abstracting away high-level database management activities. It should also be understood that... Figure 6 One or more of the elements described or depicted herein may perform one or more of the actions, functions, or features described or depicted herein.

[0199] Although exemplary embodiments of at least one of the systems, methods, and non-transitory computer-readable media have been illustrated 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 many rearrangements, modifications, and substitutions set forth and defined in the following claims. For example, the capabilities of the systems in the various figures may be executed by one or more of the modules or components described herein or in a distributed architecture, and may include transmitters, receivers, or a pair of both. For example, all or part of the functions performed by the various modules may be performed by one or more of these modules. In addition, the functions described herein may be performed at different times and in relation to various events, either internal or external to the modules or components. Moreover, information transmitted between the modules may be transmitted via at least one of the following: data networks, the Internet, voice networks, Internet Protocol networks, wireless devices, wired devices, and / or via multiple protocols. Furthermore, messages transmitted or received by any module may be transmitted or received directly and / or via one or more other modules.

[0200] Those skilled in the art will recognize 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 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.

[0201] 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-designed very large-scale integrated (VLSI) circuits or gate arrays, such as off-the-shelf semiconductors of logic chips, transistors, or other discrete components. Modules can also be implemented in programmable hardware devices, such as field-programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

[0202] Modules can also be implemented at least partially in software so that they can be 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 files of the identified modules do not need to be physically located together, but can include different instructions stored in different locations that, when logically connected, encompass the module and implement the module's stated purpose. Additionally, modules can be stored on a computer-readable medium, which can be, for example, a hard disk drive, a flash memory device, random access memory (RAM), magnetic tape, or any other such medium for storing data.

[0203] In practice, a module of executable code can be a single instruction or many instructions, and can even be distributed across several different code segments, different programs, and across several memory devices. Similarly, operational data can be identified and illustrated within the module herein, and can be implemented in any suitable form and organized within any suitable type of data structure. Operational data can be collected as a single dataset, or can be distributed across different locations including different storage devices, and can exist at least in part solely as electronic signals on a system or network.

[0204] 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.

[0205] It will be readily understood by those skilled in the art that the above can be practiced using steps in a different order and / or using hardware components in a configuration different from the disclosed configuration. Therefore, while this application has been described based on these preferred embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be readily apparent.

[0206] While 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 the full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.).

Claims

1. A method comprising: Determine the remaining time until the vehicle is fully charged; as well as Content is transmitted to the vehicle based on the remaining time.

2. The method of claim 1, comprising: Applications that identify the association between vehicle occupant profiles; as well as The application is launched while the vehicle is charging, during the remaining time of the application's usage duration.

3. The method of claim 1, comprising: Identify one or more actions performed by the occupant while using the application; as well as One or more vehicle functions are enabled in response to one or more actions identified in the application.

4. The method of claim 3, wherein the one or more vehicle functions include chair movement, changes in air ventilation speed or temperature, changes in lighting control, and changes in the air injector.

5. The method of claim 1, wherein the transmitted content is streaming content of a game associated with the occupants of the vehicle.

6. The method of claim 2, comprising: It was determined that the game session associated with the application ended prematurely within the remaining time after the update; as well as Based on the remaining time after the update, it is determined not to initiate another game session.

7. The method of claim 2, comprising: Confirm charging is complete; The game session associated with the application was not completed; as well as Forward game session data to the user's device.

8. A system including a memory and a processor, wherein the processor is configured to: Determine the remaining time until the vehicle's charging is complete; and Content is transmitted to the vehicle based on the remaining time.

9. The system of claim 8, wherein the processor is further configured to: Applications that identify the association between vehicle occupant profiles; and The application is launched while the vehicle is charging, during the remaining time of the application's usage duration.

10. The system of claim 8, wherein the processor is further configured to: Identify one or more actions performed by the occupant while using the application; and One or more vehicle functions are enabled in response to one or more actions identified in the application.

11. The system of claim 10, wherein the one or more vehicle functions include chair movement, changes in air ventilation speed or temperature, changes in lighting control, and changes in the air injector.

12. The system of claim 8, wherein the transmitted content is streaming content of a game associated with the occupants of the vehicle.

13. The system of claim 9, wherein the processor is further configured to: It was determined that the game session associated with the application ended prematurely within the remaining time after the update; and Based on the remaining time after the update, it is determined not to initiate another game session.

14. The system of claim 9, wherein the processor is further configured to: Confirm charging is complete; It was determined that the game session associated with the application had not been completed; and Forward game session data to the user's device.

15. A non-transitory computer-readable medium configured to store instructions, which, when executed, cause a processor to perform: Determine the remaining time until the vehicle's charging is complete; and Content is transmitted to the vehicle based on the remaining time.

16. The non-transitory computer-readable medium of claim 15, wherein the processor is further configured to perform: Applications that identify the association between vehicle occupant profiles; and The application is launched while the vehicle is charging, during the remaining time of the application's usage duration.

17. The non-transitory computer-readable medium of claim 15, wherein the processor is further configured to perform: Identify one or more actions performed by the occupant while using the application; and One or more vehicle functions are enabled in response to one or more actions identified in the application.

18. The non-transitory computer-readable medium of claim 17, wherein the one or more vehicle functions include chair movement, changes in air ventilation speed or temperature, changes in lighting control, and changes in the air injector.

19. The non-transitory computer-readable medium of claim 15, wherein the transmitted content is streaming content of a game associated with the occupants of a vehicle.

20. The non-transitory computer-readable medium of claim 16, wherein the processor is further configured to perform: It was determined that the game session associated with the application ended prematurely within the remaining time after the update; and Based on the remaining time after the update, it is determined not to initiate another game session.

Images