Content distribution based on energy-supplying vehicle

Abstract

To provide a method including providing content to a device on the basis of the amount of energy supplied when a vehicle is detected to be connected to a charging point.SOLUTION: An example of operation includes at least one of: detecting that a vehicle is connected to a charging point; transmitting, to a device associated with the vehicle, a request for the vehicle to supply energy to the charging point; and providing content to the device on the basis of the amount of energy supplied in response to the request.SELECTED DRAWING: Figure 1A

Description

[Technical Field]

[0001] Vehicles or transportation vehicles, such as automobiles, motorcycles, trucks, airplanes, trains, etc., generally provide transportation needs for passengers and / or goods in a variety of ways. Vehicle-related functionality may be identified and utilized by a variety of computing devices, such as smartphones and computers located on and / or outside the vehicle. Summary of the Invention

[0002] One embodiment provides a method comprising one or more of detecting that a vehicle is connected to a charging point, the vehicle sending a request to a device associated with the vehicle to supply energy to the charging point, and in response providing content to the device based on the amount of energy supplied.

[0003] Another embodiment provides a system comprising a memory and a processor coupled to the memory, the processor configured to enable one or more of: detecting that a vehicle is connected to a charging point; transmitting a supply to a device associated with the vehicle for the vehicle to supply energy to the charging point; and in response, providing content to the device based on the amount of energy supplied.

[0004] A further embodiment provides a computer-readable storage medium having stored thereon instructions that, when executed by a processor, cause the processor to perform one or more of: detecting that a vehicle is connected to a charging point; sending a request to a device associated with the vehicle for the vehicle to supply energy to the charging point; and in response, providing content to the device based on the amount of energy supplied. [Brief explanation of the drawings]

[0005] [Figure 1A]FIG. 1A illustrates a process for a user device to pair with a vehicle, according to an embodiment. [Figure 1B] FIG. 1B illustrates a process by which a user device receives content and a charging station determines if power is needed, according to an embodiment. [Figure 1C] FIG. 1C illustrates a process by which a server determines how much power is stored in a vehicle associated with a user device, according to an embodiment. [Figure 1D] FIG. 1D illustrates a process for pausing content displayed on a user device and requesting that a vehicle associated with the user device perform an energy transfer operation, according to an embodiment. [Figure 1E] FIG. 1E illustrates a process for resuming paused content on a vehicle's display device in response to the vehicle performing an energy transfer operation, according to an embodiment. [Figure 2A] FIG. 2A illustrates a vehicle network diagram, according to an embodiment. [Figure 2B] FIG. 2B illustrates another vehicle network diagram, according to an embodiment. [Figure 2C] FIG. 2C illustrates yet another vehicle network diagram, according to an embodiment. [Figure 2D] FIG. 2D illustrates a further vehicle network diagram, according to an embodiment. [Figure 2E] FIG. 2E shows a flow diagram according to an embodiment. [Figure 2F] FIG. 2F illustrates another flow diagram, according to an embodiment. [Figure 2G] FIG. 2G illustrates yet another flow diagram, according to an embodiment. [Figure 2H] FIG. 2H illustrates yet another flow diagram according to an embodiment. [Figure 3A] FIG. 3A illustrates an artificial intelligence (AI) / machine learning (ML) network diagram for integrating an artificial intelligence (AI) model into any decision-making point in an embodiment. [Figure 3B]FIG. 3B illustrates the process of developing artificial intelligence (AI) / machine learning (ML) to support AI-assisted vehicle or occupant decision points. [Figure 3C] FIG. 3C illustrates a process that utilizes artificial intelligence (AI) / machine learning (ML) to support AI-assisted vehicle or occupant decision points. [Figure 3D] FIG. 3D illustrates a machine learning network, according to an embodiment. [Figure 3E] FIG. 3E illustrates a machine learning network, according to an embodiment. [Figure 4A] FIG. 4A shows a diagram illustrating the electrification of one or more elements, according to an embodiment. [Figure 4B] FIG. 4B shows a diagram depicting the interconnections between different elements, according to an embodiment. [Figure 4C] FIG. 4C shows a further diagram depicting the interconnections between different elements, according to an embodiment. [Figure 4D] FIG. 4D shows a further diagram depicting interconnections between elements, according to an embodiment. [Figure 4E] FIG. 4E shows a further diagram illustrating an example vehicle performing secure vehicle-to-vehicle (V2V) communication using security certificates, according to an embodiment. [Figure 5A] FIG. 5A illustrates an example vehicle configuration for managing database transactions related to a vehicle, according to an embodiment. [Figure 5B] FIG. 5B illustrates an example blockchain group, according to an embodiment. [Figure 5C] FIG. 5C illustrates an example interaction between an element and a blockchain, according to an embodiment. [Figure 5D] FIG. 5D illustrates an example of data block interaction, according to an embodiment. [Figure 5E] FIG. 5E illustrates a blockchain network diagram, according to an embodiment. [Figure 5F] FIG. 5F illustrates an example new data block, according to an embodiment. [Figure 6] FIG. 6 illustrates an example system that supports one or more of the embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0006] It will be readily understood that the components of this field, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of at least one embodiment of a method, apparatus, computer-readable storage medium, and system, as illustrated in the accompanying figures, is not intended to limit the scope of the present application but is merely representative of selected embodiments. The 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 medium.

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

[0008] Features, structures, or characteristics described herein may be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the use of "exemplary embodiment," "some embodiments," "first embodiment," or other similar phrases refers to the fact that a particular feature, structure, or characteristic described in connection with one or more embodiments may also be included in one or more other embodiments described or depicted herein. Thus, one or more embodiments described or depicted throughout this specification may all refer to the same embodiment. Thus, these embodiments may operate in conjunction with any of the other embodiments and are not necessarily functionally distinct, and described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. Although described in a particular manner, it is merely illustrative, and multiple feature(s), elements, and step(s) described herein are not exclusive and may be utilized together in various combinations unless expressly indicated otherwise herein. In the figures, any connections between elements may enable unidirectional and / or bidirectional communication, even if the depicted connections are unidirectional or bidirectional, such as with arrows.

[0009] In this field solution, vehicles may include one or more of a car, a truck, an internal combustion engine (ICE) vehicle, a battery electric vehicle (BEV), a fuel cell vehicle, any vehicle that utilizes renewable resources, a hybrid vehicle, an e-Palette, a bus, a motorcycle, a scooter, a bicycle, a boat, a recreational vehicle, an airplane, a drone, an unmanned aerial vehicle (UAV), and any object that may be used to transport people and / or goods from one location to another.

[0010] Additionally, although the term "message" may be used in describing the embodiments, other types of network data may also be used, such as packets, frames, datagrams, etc. Additionally, although the exemplary embodiments may depict particular types of messages and signals, they are not limited to particular types of messages and signals.

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

[0012] Within communication infrastructure, a distributed database is a distributed storage system that includes multiple nodes communicating with each other. Blockchains are an example of a distributed database and include a write-once, immutable data structure (i.e., a distributed ledger) that can maintain records across untrusted parties. Herein, the untrusted parties are referred to as peer nodes. Each peer maintains a copy of the database record, and no single peer can modify it without consensus among the distributed peers. For example, peers can execute a consensus protocol to validate storage entries in the blockchain, group them into blocks, and build a hash chain through the blocks. This process forms a ledger by ordering the storage entries as necessary for consistency. Public and permissionless blockchains allow anyone to participate without specific identity. Public blockchains can include cryptocurrencies and use consensus based on various protocols, such as proof-of-work (PoW). Conversely, permissioned blockchain databases can secure interactions between groups of entities that share a common goal but do not fully trust each other, such as businesses exchanging funds, goods, or information. This solution can function in permissioned and / or permissionless blockchain settings.

[0013] Smart contracts are trusted distributed applications that leverage the tamper-proof properties of a shared or distributed ledger (sometimes in the form of a blockchain) and a basic agreement among member nodes called an endorsement or endorsement policy. Blockchain entries are typically "endorsed" before being committed to the blockchain, and entries that are not endorsed are ignored. In a typical endorsement policy, the executable code of a smart contract can specify endorsers for an entry in the form of a set of peer nodes required for endorsement. When a client submits an entry to a peer specified in the endorsement policy, the entry manager runs to validate the entry. After validation, the entry enters an ordering phase, where a consensus protocol produces an ordered sequence of endorsed entries grouped into blocks.

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

[0015] A ledger is a sequenced, tamper-resistant record of all state transitions of a blockchain. A state transition may result from an invocation (i.e., an entry) of smart contract executable code submitted by a participating party (e.g., client node, order node, endorser node, peer node). An entry may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as create, update, or delete. A ledger contains a blockchain (also called a chain), where blocks store immutable, sequential records. A ledger also contains a state database, which maintains the current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel it is a member of.

[0016] A chain is an entry log structured as hash-linked blocks, each containing a sequence of N entries. A block's header contains the hash of the block's entries and the hash of the previous block's header. In this way, all entries on the ledger are ordered and cryptographically linked. Therefore, ledger data cannot be tampered with without unlinking the hashes. The hash of the most recently added block on the blockchain represents all entries on the chain before it, ensuring that all peer nodes are in a consistent and trusted state. Chains can be stored on peer nodes' file systems (local, attached storage, cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0017] The current state of the immutable ledger represents the latest values ​​of all keys contained in the chain's entry log. The current state may be called the world state, as it represents the most recent key values ​​known to the channel. Smart contract executable calls execute entries against the ledger's current state data. To streamline smart contract executable interactions, the latest values ​​of keys can be stored in a state database. The state database may 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 is automatically restored (or generated on demand) when a peer node starts up or before an entry is accepted.

[0018] Blockchain differs from traditional databases in that it does not have a central storage, but a distributed, immutable, and secure storage, and nodes must share changes to records in the storage. Properties inherent in blockchain and that aid in its implementation include, but are not limited to, immutable ledger, smart contracts, security, privacy, decentralization, consensus, authorization, and accessibility.

[0019] Exemplary embodiments provide services to a particular vehicle and / or a user profile applied to the vehicle. For example, a user may be the owner of the vehicle or the operator of a vehicle owned by another person. A vehicle may require service at regular intervals, and the need for service may require authorization before service is permitted. A service center may also provide service to vehicles in a nearby area based on the vehicle's current route plan and the relative level of service demand (e.g., immediate, severe, medium, minor, etc.). Vehicle needs may be monitored via one or more vehicle and / or roadway sensors or cameras, which report sensed data to a central controller computing device within the vehicle and / or remote from the vehicle. This data is forwarded to a management server for review and action. Sensors may be located within the vehicle, on the vehicle's exterior, on fixed objects remote from the vehicle, or on another vehicle in close proximity to the vehicle. Sensors may also be associated with vehicle speed, vehicle braking, vehicle acceleration, fuel level, need for service, vehicle gear shifting, vehicle steering, etc. The sensors described herein may also be devices such as wireless devices within the vehicle and / or in close proximity to the vehicle. Additionally, sensor information can be used to identify whether the vehicle is being operated safely and whether the occupant has engaged in an unexpected vehicle condition, such as during a period of access and / or use of the vehicle. Vehicle information collected before, during, and / or after vehicle operation may be identified and stored in transactions on a shared / distributed ledger, which may be generated and committed to the immutable ledger in a "decentralized" manner, such as via a group of blockchain members, as determined by a permissioned consortium.

[0020] Each party (i.e., owner, user, company, agency, etc.) may want to limit the exposure of personal information, and therefore can use blockchain and its immutability to manage permissions for each specific user-vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when service is required, identify collision and / or degradation events, identify safety concern events, identify the parties involved in the event, and provide distribution to registered entities seeking access to such vehicle event data. They can also identify outcomes and share the required information among registered companies and / or individuals based on a consensus approach involving blockchain. Such an approach may not be possible to implement with traditional centralized databases.

[0021] The various navigation systems in this field solution may utilize software, arrays of sensors, as well as machine learning capabilities, Light detection and ranging (Lidar) projectors, radar, ultrasonic sensors, etc. to create maps of the terrain and roads that the vehicle can use for navigation and other purposes. In some embodiments, Global Positioning Systems (GPS), maps, cameras, sensors, etc. may also be used by autonomous vehicles in place of Lidar.

[0022] The solution in question, in certain embodiments, includes authorizing a vehicle for service via an automated, expedited authentication scheme. For example, driving to a charging station or fuel pump may be performed by the vehicle operator or the autonomous vehicle, and authorization to charge or receive fuel may be performed without delay, contingent on authorization being received by the service and / or charging station. The vehicle may provide a communication signal providing an identification of the vehicle with a currently active profile linked to an account authorized to accept the service, which can later be remedied by compensation. Additional means may be used to provide further authentication, such as another identifier being wirelessly transmitted from the user's device to the service center to replace or supplement the initial authentication effort between the vehicle and the service center with an additional authentication effort.

[0023] The shared and received data may be stored in a single database (e.g., a database server), typically in one specific location, with the data held in that database. This location is often a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a centralized database can typically be accessed from multiple different locations. A centralized database is easier to manage, maintain, and control, and is particularly well-suited for security purposes because it is centralized in one location. In a centralized database, all data resides in a single location, minimizing data redundancy and ensuring that a particular data set has only one main record. Blockchain may be used to store vehicle-related data and transactions.

[0024] Any of the operations described herein may be performed by one or more processors (e.g., microprocessors, sensors, electronic control units (ECUs), head units), with or without memory, which may be located on-board the vehicle and / or off-board the vehicle (e.g., servers, computers, mobile / wireless devices). The one or more processors may communicate with other memory and / or other processors on-board or located in other vehicles to utilize data transmitted by and / or to the vehicle. The one or more processors and other processors may transmit data, receive data, and utilize this data to perform one or more of the operations described or depicted herein.

[0025] Vehicle-to-grid (V2G) technology allows electric vehicles (EVs) to not only extract electricity from the grid for charging but also return it to the grid, homes, and businesses. This two-way energy transfer offers several potential benefits. For example, EVs can help balance the grid load by returning electricity during peak demand periods. This is especially important as the grid becomes increasingly dependent on renewable energy, which is often intermittent. EVs can help stabilize the grid by charging during times of excess supply, such as high winds or intense sunshine, and providing energy during shortages. During power outages or natural disasters, V2G-enabled EVs can serve as temporary energy sources for homes and critical infrastructure. This could be lifesaving during prolonged power outages. By providing storage capacity and demand flexibility, V2G can promote the widespread adoption of renewable energy. EV batteries can effectively increase the efficiency and reliability of the renewable energy ecosystem by storing excess renewable energy that would otherwise be wasted and supplying it during times of low production. Optimizing the use of renewable energy has the added benefit of contributing to reducing carbon emissions across the energy sector.

[0026] An exemplary embodiment relates to a process by which a vehicle occupant / owner can request that a charge stored in the vehicle's secondary battery be provided to a charging point, where the charging point may enable bidirectional energy transfer so that the secondary battery can return / provide energy to the charging point. The occupant may "pair" their user device to the vehicle in a pairing operation. The pairing creates a user profile for the user that is stored on both the vehicle and the user device. The user profile may include an identifier for the vehicle, identifiers for content delivery software applications used by and / or installed on the user device, content delivery software applications installed on the vehicle, etc. After the pairing operation, the user may power off the vehicle and leave the vehicle together with the user device.

[0027] According to various embodiments, the charge point or a server associated with the charge point may provide content to the user on the user device. The content may include video games, movies, music, etc. The server may deliver the content to the user device while the user is outside the vehicle. In some embodiments, the charge point may have vehicle-to-grid (V2G) capabilities that allow the charge point to provide energy to a rechargeable battery and also receive energy transfers from the rechargeable battery. The charge point may query the grid or may determine that power is needed by the charge point.

[0028] In an exemplary embodiment, when a charge point determines that it needs power, it may notify a server that provides content to the user device of the need for electrical energy. In response, the server may pause the content on the user device and request that the user drive the vehicle to the charge point to transfer energy back to the charge point. Pausing the content may stop playback of a video game, movie, music, etc. In some cases, the pause may require user consent. Once the user drives the vehicle to the charge point and performs an energy transfer from the vehicle's battery to the charge point, the charge point may notify a content server. In response, the content server may resume the content (previously paused on the user device) and play the content on a display device in the vehicle, such as an infotainment system, an embedded display, etc. As another example, the paused content may be output on a user interface of the charge point, the user device, etc.

[0029] In some embodiments, a passenger may be offered an incentive to participate in V2G energy transfer in exchange for digital content. The scenario begins with a passenger not in the vehicle. This person parks the vehicle and is elsewhere, such as at home, in the office, or in a public place. While not in the vehicle, the user may engage with content and consume digital content on a user device, such as a smartphone, tablet, or computer. For example, the user may watch videos, listen to music, read a book, or perform other activities that involve consuming digital content. This is beneficial in situations where the power grid requires additional power, perhaps during peak demand or power shortages. The content on the user's device remains paused until the on-the-fly solution confirms that the vehicle has connected to a charging point and successfully initiated energy delivery to the power grid. Once confirmed, content playback or consumption resumes and the user is informed that the process is ongoing.

[0030] In one embodiment, the energy provider may be associated with a content server and may receive stored energy from the vehicle during peak usage periods, weather-related events, etc. In some embodiments, the server and / or charging point may determine whether the vehicle's rechargeable battery contains a greater amount of energy than a threshold and send a notification, such as via a mobile device, to a person associated with the vehicle. The notification may include the location of the nearest connection point, allowing the vehicle to supply energy to the power grid. In some embodiments, a request to connect the vehicle to a charging point is sent to a device associated with the occupant. In some embodiments, upon connecting to the charging point and supplying energy to the charging point, enhanced content is provided to the vehicle. In some embodiments, the content resumed in the vehicle may be enhanced with additional content, additional features, extended playtime, additional game features that would normally require purchase, etc. In this manner, the enhanced content may be content that is not normally available.

[0031] 1A illustrates a process 100A of a user device 110 pairing with a vehicle 120, according to an example embodiment. Referring to FIG. 1A, the user device 110 is associated with an occupant of the vehicle 120, such as the vehicle owner, a vehicle lessee, a secondary user of the vehicle, etc. The user device 110 may include a wireless communication interface, such as Bluetooth®, Wi-Fi®, etc., which may be used to pair with one or more of a vehicle computer 122, a display system 124 (e.g., an infotainment system, etc.) installed within the vehicle 120, etc.

[0032] A pairing operation may include a user of user device 110 bringing user device 110 within a predetermined proximity range of vehicle 120, e.g., inside vehicle 120. For example, in the example of FIG. 1A , user device 110 may pair with display system 124. To perform the pairing operation, the user may press a user interface on user device 110 and / or a user interface on display system 124 to trigger a discovery and authentication process between the user device and display system 124. In some embodiments, display system 124 may generate a user profile for the user of user device 110, including the phone number or other contact information for user device 110, identifiers of content applications available on user device 110, identifiers of any content applications available on display system 124, access credentials for the user of user device 110 to access content from the content applications, etc. The user profile may be stored in storage of display system 124.

[0033] 1B illustrates a process 100B in which a user device 110 receives content and a charging station 140 determines that power is needed, according to an exemplary embodiment. Referring to FIG. 1B, a user of the user device 110 can consume content, such as video games, music, literature, movies, and the like, from a content providing server 130, which may host a content providing software application. Here, the content providing server 130 can play or otherwise output the content to a user interface 112 of the user device 110 over a computer network, such as the Internet.

[0034] Meanwhile, charging station 140 may be connected to power grid 150 and may decide to provide power to power grid 150, for example, when the power grid is experiencing a power outage or when an emergency occurs, such as a weather event, earthquake, or high wave. Charging station 140 may repeatedly analyze power grid 150 to identify situations in which a power transfer would be beneficial to power grid 150. In response to determining that a power transfer would be beneficial, charging station 140 may notify content providing server 130. As another example, a server associated with an energy provider of power grid 150 may identify when a power transfer would be beneficial and identify charging stations 140 available to receive energy. In this example, the server may correspond to content providing server 130.

[0035] In response to the content providing server 130 determining the need to transfer power to the charging station 140, the content providing server 130 may analyze the vehicle 120 of the user receiving content from the content providing server 130. For example, FIG. 1C illustrates a process 100C in which the content providing server 130 determines how much power is stored in the vehicle 120 associated with the user device 110 according to an exemplary embodiment. For example, the content providing server may send a communication to the vehicle computer 122 or the display system 124 requesting the current charge level of the rechargeable battery of the vehicle 120. In response, the vehicle computer 122 or the display system 124 may provide the current charge level of the rechargeable battery to the content providing server 130. The content providing server may compare the current charge level of the vehicle's secondary battery with a threshold value (e.g., 50%, 70%, 80%, etc.). If the current charge level is above the threshold, the content providing server 130 may decide to request the user / occupant of the vehicle 120 to take the vehicle 120 to a location for charging.

[0036] 1D illustrates a process 100D for pausing content displayed on a user device 110 and requesting a vehicle 120 associated with the user device 110 to perform an energy transfer operation, according to an exemplary embodiment. Referring to FIG. 1D , the user device 110 is currently receiving content from a content providing server 130. The content providing server 130 may pause the content, e.g., stop playback of the content on the user device 110, and record a timestamp of the pause. Furthermore, the content providing server 130 may send instructions to the user interface 112 of the user device 110 requesting that the user drive the vehicle to the nearest available charging station for bidirectional energy transfer. In this example, the nearest charging station is charging station 140 shown in the example of FIG. 1B. In some embodiments, the pausing of the content can continue until the user drives vehicle 120 to charging station 140. At this point, the user may press an input on user device 110 to agree to the pause and energy transfer to charging station 140. In this example, the user may receive compensation or some other benefit for agreeing to the energy transfer operation. With the content paused, the user may get into vehicle 120 and drive to charging station 140.

[0037] 1E illustrates a process 100E for resuming paused content on display system 124 of vehicle 120 in response to the vehicle performing an energy transfer operation, according to an exemplary embodiment. Referring to FIG. 1E, a user can initiate a charging operation by taking vehicle 120 to charging station 140 and connecting charging port 144 of charging station 140 to charging connector 126 of the vehicle. Charging port 144 may be attached to charging station 140 via cable 142, where charging port 144, cable 142, and charging station 140 enable bidirectional energy transfer. Thus, the user can select to power charging station 140 from a rechargeable battery of vehicle 120.

[0038] When the charging operation is initiated, charging station 140 may notify content providing server 130 of the energy transfer operation. In response, content providing server 130 may resume the previously paused content. Here, the content may be resumed on display system 124 in vehicle 120. The content may be resumed from the point at which the content was paused based on a previously recorded timestamp. As another example, the content may be enhanced with additional content, different content, better content, etc. As another example, the content may be resumed on another device, such as another display system in vehicle 120, a user interface of charging station 140, or user device 110.

[0039] In one embodiment, the system determines the most efficient time for energy transfer and pauses content consumption while prompting the user to connect to a charging point. The system includes an advanced communications system that interfaces with the smart power grid to determine the optimal time for energy transfer. The system evaluates the overall demand on the power grid, the availability of renewable energy sources (such as solar and wind power), and peak and off-peak times. When a user is consuming content on a personal device and the vehicle is near a charging point, the system determines the optimal time for energy transfer to the power grid. For example, when solar power is at high capacity (such as midday), the power grid may benefit from additional energy storage. In such a scenario, the vehicle's system intelligently pauses content on the user's device and prompts the user to connect the vehicle to a charging station. This prompt can take the form of a notification displayed on both the user's device and the vehicle's infotainment system, explaining the benefits of charging at this time, such as faster charging speeds and financial incentives to support grid stability. Once the vehicle connects to a charging point and begins drawing energy from the grid, content consumed on the user's device is seamlessly transferred and resumes on the vehicle's display system. The transition is designed to be smooth and intuitive, allowing users to continue enjoying their content without significant interruption. Additionally, the system uses predictive algorithms that learn from the user's schedule and charging habits to provide personalized recommendations for the most efficient charging times. Users can also configure how aggressively the system prioritizes the needs of the smart grid over content consumption, allowing them to balance personal convenience with energy efficiency.

[0040] In one embodiment, the system integrates augmented reality (AR) technology into the vehicle's content consumption experience while the vehicle is transferring energy at a charging station. The system enhances the user experience by overlaying digital content over the physical world, creating a unique, immersive environment within the vehicle. When a user's vehicle is connected to a charging station and the energy transfer process begins, a display system activates the AR functionality. The system is comprised of advanced AR technology, including projectors, cameras, and sensors built into the vehicle. These components work together to overlay digital images and information onto interior surfaces, such as the dashboard, windows, and even the windshield. For example, if a user watched a documentary about marine life on their device before connecting to a charging point, the in-car AR system can continue this content in a more immersive format. Images of ocean scenes, marine life, and related data can be projected onto interior surfaces, creating an underwater experience. The system also utilizes sound effects and haptic feedback in the seats to further enhance the experience and mimic the feeling of being in the depicted environment. The AR content is context-aware and adapts based on the user's interactions and movements within the vehicle. When a user looks at a specific area where a digital fish is projected, the fish reacts by moving away or towards them. Furthermore, the system can personalize based on the user's preferences and history. It learns over time what kind of content the user enjoys and tailors the AR experience accordingly. For example, a user interested in space exploration might see the interior of their car transformed into a representation of the solar system, with planets and stars moving around. The system ensures that the AR projection does not obstruct the driver's view or necessary operations. Furthermore, while the vehicle is moving, the AR experience is restricted to the passenger area only.

[0041] In one embodiment, the system curates personalized content based on a user's preferences and travel patterns. Using a combination of data analytics, machine learning, and user input, the system learns and adapts to a user's content preferences, travel habits, and typical charging schedule by building a comprehensive profile of their tastes and routines. This profile includes the types of content the user enjoys (e.g., specific genres of music, podcasts, audiobooks, video content), average travel time, and typical charging behavior (e.g., preferred charging times and locations). The vehicle's intelligent systems actively monitor the user's content consumption patterns while on the road, taking into account what the user likes to watch or listen to at different times of the day, on specific days of the week, or while driving to specific locations. For example, a user may prefer upbeat music during their morning commute, but opt ​​for podcasts or audiobooks on longer drives. Leveraging this data, the system creates a personalized content playlist tailored to the user's expected charging time. For example, if a user spends approximately 30 minutes at a charging station, the system suggests content tailored to this time frame. This could be a 30-minute episode of a favorite podcast, a short documentary, or a playlist of songs. When a vehicle is plugged in at a charging station, curated content automatically begins playing on the vehicle's display system. The system adapts content suggestions based on real-time data, such as the battery's current charge state and expected charging time, to ensure content playback times match the charging time as closely as possible. The system also includes the ability to save and resume specific portions of content if charging ends sooner than expected or if you need to pause for any reason. It can also sync with the user's devices, so if they start watching on their smartphone or tablet and begin charging, they can seamlessly continue watching on the car's system.

[0042] In one embodiment, the system delivers educational content as a vehicle delivers energy to a charging point. The vehicle's infotainment system is loaded with a suite of educational content, ranging from documentaries to interactive modules, e-learning courses, and educational games. The content is carefully curated, covering a wide range of topics, including sustainable living, environmental science, the technologies behind electric vehicles, renewable energy, and even history, science, and languages. When a vehicle is connected to a charging station, the system recognizes the start of the charging process and presents the user with a selection of educational content. The selection can be personalized based on the user's previous interactions, learning preferences, and interests. For example, if a user expresses an interest in sustainable technologies, the system might suggest a documentary on the latest advances in renewable energy or an interactive module on how electric vehicles contribute to environmental sustainability. The system includes quizzes, interactive infographics, and hands-on virtual experiments that users can participate in using the vehicle's touchscreen interface or voice commands. For example, after watching a short documentary on solar energy, a user might be presented with an interactive quiz to test their understanding of the content. The system is integrated with an online education platform, allowing users to continue taking courses or explore new subjects. The vehicle's system syncs with the user's online education profile, tracks progress, and suggests relevant content to complement their learning journey. The system also saves and bookmarks content for the user, allowing them to resume learning later, during their next charging session or across devices. In one embodiment, the system supplies energy to a user's home and synchronizes content consumption between the home and vehicle displays. Vehicles are equipped with vehicle-to-home (V2H) technology, allowing them to transmit stored electrical energy back to the user's home. This capability is particularly useful during power outages or peak demand periods, allowing the vehicle to act as a secondary power source. The system is designed to be bidirectional, allowing energy to flow from the vehicle to the home and vice versa, depending on the need. When the vehicle begins transmitting energy to the home, a multimedia content synchronization protocol is initiated between the vehicle's infotainment system and the home entertainment system. For example, if a user is watching a movie or series on their home TV and needs to leave the house, they can pause the content, plug in their vehicle for charging and energy transfer, and seamlessly resume watching in the vehicle. The content streaming service recognizes the user's profile and synchronizes playback, allowing the user to continue watching exactly where they left off. Synchronization is not limited to video content; it also extends to music, audiobooks, podcasts, and all other forms of digital media. The system is designed to be compatible with various streaming platforms, allowing a wide range of content to be available for seamless transitions between home and car. Furthermore, user settings such as audio levels, subtitles, and playback speed are synchronized, providing a consistent and personalized experience. The system can project content onto various screens throughout the vehicle. For example, passengers can watch and listen to other content on individual screens in the seatbacks. At the same time, the driver can access the navigation and control interface, allowing all vehicle occupants to enjoy personalized content. When the vehicle is moving, the driver's display only shows driving-related information, preventing distractions. Entertainment content is only available when the vehicle is stationary or specifically used for energy transmission, ensuring compliance with road safety regulations.

[0043] In one embodiment, the on-the-spot solution requires a device associated with a vehicle to prompt the vehicle to supply energy to a charging point and, in response, provide content to the device. The vehicle is equipped with a rechargeable battery and a vehicle computer or display system capable of wireless communication. A user device, such as a smartphone, pairs with the vehicle's system through technologies such as Bluetooth or Wi-Fi. Pairing is facilitated by bringing the user device within a certain distance of the vehicle and involves an authentication process for a secure connection. A charging station connected to the power grid can both receive and transmit power. It is designed to identify situations in which transmitting power is beneficial, such as during a power grid outage or emergency. Upon deciding to supply power to the power grid, the charging station communicates this need to a content providing server. The content providing server provides content to the user device and monitors the vehicle's power status. When the vehicle is connected to the charging station, the server analyzes the vehicle's battery charge level. If the charge level exceeds a certain threshold, the server prompts the user to send the vehicle for charging, facilitating energy transfer to the power grid. When a user drives a vehicle to a charging station and initiates the energy transfer process, the content providing server pauses the content on the user's device. The pause remains in effect until the vehicle starts to supply energy to the charging station. Once the energy transfer begins, the charging station notifies the server, which triggers the resumption of the paused content. The content is displayed either on the vehicle's display system or on the user's device, resuming from where it was paused.

[0044] The flow diagrams depicted herein, such as Figures 2C, 2D, 2E, 2F, 2G, and 2H, are examples of alternative embodiments that may be the same or different. Any of the operations in one flow diagram may be employed and shared with another flow diagram. Any example operations are not intended to limit the subject matter of any embodiment or corresponding claim.

[0045] All flow diagrams and corresponding steps derived from Figures 2C, 2D, 2E, 2F, 2G, and 2H may be part of the same process or may share sub-steps with each other. Therefore, it is important to note that the diagrams can be combined into one preferred embodiment that does not require one specific operation, but performs a specific operation from one exemplary process and one or more additional processes. All exemplary processes relate to the same physical system and can be used separately or interchangeably.

[0046] The present solution can be used in conjunction with one or more types of vehicles, such as battery electric vehicles, hybrid vehicles, fuel cell vehicles, internal combustion engine vehicles, and / or vehicles that utilize renewable resources. FIG. 2A shows a vehicle network diagram 200 according to an exemplary embodiment. The network is comprised of elements including a vehicle 202 including a processor 204 and a vehicle 202′ including a processor 204′. The vehicles 202, 202′ communicate with each other via the processors 204, 204′ and other elements (not shown) including transceivers, transmitters, receivers, storage, sensors, and other elements capable of providing communication. Communication between the vehicles 202, 202′ can occur directly, via private and / or public networks (not shown), or via other vehicles and elements including one or more of a processor, memory, and software. While 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 the elements of the field.

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

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

[0049] 2C shows yet another vehicle network diagram 240 according to an exemplary embodiment. The network is comprised of elements including a vehicle 202, a processor 204, and a non-transitory computer-readable medium 242C. The processor 204 is communicatively coupled to the computer-readable medium 242C and to element 230 (depicted in FIG. 2B). The vehicle 202 may be a vehicle, a server, or any device having a processor and memory.

[0050] The processor 204 performs one or more of identifying content being consumed by a user device associated with the vehicle while the user device is outside the vehicle at 244C, sending a request to the user device to pause the content on the user device at 246C, detecting that the vehicle is connected to a charging point and is supplying electrical energy to the charging point from a rechargeable battery in the vehicle at 248C, and in response thereto, resuming the content on a display device associated with the vehicle at 250C.

[0051] 2D shows a further vehicle network diagram 250 according to an example embodiment. The network is comprised of elements including a vehicle 202, a processor 204, and a non-transitory computer-readable medium 242D. The processor 204 is communicatively coupled to the computer-readable medium 242D and to element 230 (depicted in FIG. 2B). The vehicle 202 may be a vehicle, a server, or any device having a processor and memory.

[0052] In 244D, the processor 204 performs one or more of: registering access credentials of the software application with a server associated with the charging point; obtaining content from the software application via the server based on the access credentials; and playing the content from the software application on a display device associated with the vehicle; in 245D, receiving a timestamp from the user device identifying when the content was paused; and in 245D, resuming the content at the time when the content was paused based on the timestamp; in 246D, transmitting a geographical location of the charging point to the user device; estimating an amount of time remaining in a charging operation of the secondary battery; and selecting additional content based on the amount of time remaining in the charging operation; and in 247D, playing the additional content on a display device associated with the vehicle; in 249D, determining that the vehicle has a remaining charge equal to or greater than a predefined threshold before detecting that the vehicle is connected to the charging point; and in response, in 248D, sending a request to the user device and receiving consent to pause the content from the user device.

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

[0054] The processor 204 performs one or more of receiving a confirmation of the event from one or more of the elements described or depicted herein, where the confirmation comprises a blockchain consensus between peers represented by any of the elements, and executing a smart contract to record the confirmation on the blockchain consensus. The consensus is formed between any of the elements 230 and / or one or more of the elements described or depicted herein, including a vehicle, a server, a wireless device, etc. In another example, the vehicle 202 can be any of the elements 230 and / or one or more of the elements described or depicted herein, including a server, a wireless device, etc.

[0055] The processor and / or computer-readable medium may reside, in whole or in part, inside or outside the vehicle. The steps or functions stored on the computer-readable medium may be executed, in whole or in part, by any of the processors and / or elements in any order. Furthermore, one or more steps or functions may be added, omitted, combined, performed at a later date, etc. 2E shows a flow diagram 260 according to an example embodiment. Referring to FIG. 2E, the solution includes one or more of identifying content being consumed by a user device associated with a vehicle while the user device is outside of the vehicle at 244E, sending a request to the user device to pause the content on the user device at 246E, detecting that the vehicle is connected to a charge point and is providing electrical energy to the charge point from a rechargeable battery in the vehicle at 248E, and in response thereto, resuming the content on a display device associated with the vehicle at 250E.

[0056] 2F shows another flow diagram 270 according to an exemplary embodiment. Referring to FIG. 2F, the solution includes, at 244F, registering access credentials of a software application with a server associated with a charging point, obtaining content from the software application via the server based on the access credentials, playing the content from the software application on a display device associated with the vehicle, receiving, at 245F, a timestamp from the user device identifying when the content was paused, resuming, at 245F, the content at the time when the content was paused based on the timestamp, transmitting, at 246F, a geographical location of the charging point to the user device, estimating an amount of time remaining of a charging operation of a secondary battery, selecting additional content based on the amount of time remaining of the charging operation, playing, at 247F, the additional content on a display device associated with the vehicle, determining, at 249F, that the vehicle has a remaining charge equal to or greater than a predefined threshold before detecting that the vehicle is connected to the charging point, and, at 248F, sending a request to the user device in response and receiving consent to pause the content from the user device.

[0057] 2G illustrates a flow diagram 280 according to an exemplary embodiment. Referring to FIG. 2G, the solution includes one or more of detecting that a vehicle is connected to a charging point 244G, the vehicle sending a request to a device associated with the vehicle to provide energy to the charging point 246G, and in response, providing content to the device based on the amount of energy provided 248G.

[0058] In one embodiment, the device may be a display device and / or a device associated with a vehicle (e.g., a mobile device). In one embodiment, the energy may be electric, hydrogen-based, and / or any other type of energy capable of providing power.

[0059] FIG. 2H illustrates another flow diagram 290 according to an example embodiment. Referring to FIG. 2H, the solution in question includes one or more of: registering access credentials for a software application with a server associated with the charge point, where providing includes obtaining content from the software application via the server based on the access credentials and playing the content from the software application on a device associated with the vehicle (244H); the vehicle sending a further request to a device associated with the vehicle to provide additional energy to the charge point, and in response to the vehicle providing the additional energy to the charge point, providing enhanced content to the device based on the amount of additional energy provided (245H); when the enhanced content has been provided, pausing the content being provided to the device, receiving a timestamp from the device identifying when the content was paused, and providing the enhanced content at the time (246H); estimating the amount of time remaining for the vehicle to provide energy to the charge point, and selecting the additional content based on the remaining time, and playing the additional content on a device associated with the vehicle (247H); determining that the amount of energy in the vehicle exceeds a predefined threshold before sending (248H); and the provided content being based on information related to another device not associated with the vehicle (249H).

[0060] In one embodiment, transmitting includes transmitting the geographic location of the charging point to the user device. For example, regular content can be video or live sporting events available through regular media streaming, such as live sporting events (e.g., football games, wrestling matches, etc.), and can be based on a user profile (e.g., the system knows the teams / people playing). Enhanced content can be interesting angles, statistics, replays from different angles, picture-in-picture, or interesting content instead of commercials. The system may also utilize characteristics of another device (e.g., viewing genre) that are not related to the vehicle from another device.

[0061] Technological advances typically build on a foundation of prior technology, and artificial intelligence (AI) models are no different. AI classification systems describe the stages of AI advancement. The first classification was known as "reactive machines," progressing to the current AI classifications of "limited memory machines" (also known as "artificial narrow intelligence"), "theory of mind" (also known as "artificial general intelligence"), and "self-awareness" (also known as "artificial superintelligence"). Limited memory machines are a growing group of AI models built on the foundations of their predecessor, reactive machines. Reactive machines emulate human responses to stimuli but are generally limited in their capabilities because they cannot learn from past experience. As AI models developed learning capabilities, their classification was elevated to limited memory machines. In this current classification, AI models inherit all the capabilities of reactive machines but also have the ability to learn from large amounts of data, detect patterns, solve problems, generate data, and make predictions. Examples of AI models classified as limited memory machines include, but are not limited to, chatbots, virtual assistants, machine learning (ML), deep learning (DL), natural language processing (NLP), generative AI (GenAI) models, and future AI models yet to be developed that possess limited memory machine characteristics. Generative AI models combine limited memory machine technologies incorporating ML and DL, forming the foundational building blocks for future AI models. For example, "theory of mind" is the next advancement in AI, enabling AI models to perceive, connect, and react by generating appropriate responses in response to the entities they interact with. Furthermore, evolving into the "self-aware" category would enable AI models to understand and evoke the emotions of the entities they interact with, as well as have their own emotions, beliefs, and needs. Generative AI models are essential and core to future artificial intelligence models. As used herein, generative AI refers to current generative AI models and future AI models.

[0062] 3A illustrates an AI / ML network diagram 300A supporting the decision points of an AI-assisted vehicle or occupant. Other fields of AI, such as, but not limited to, computer vision, fuzzy logic, expert systems, neural networks / deep learning, generative AI, and natural language processing, may all be employed in the development of the AI ​​models illustrated in these embodiments. Furthermore, the AI ​​models included in these embodiments are not limited to any particular AI algorithm. Any algorithm or combination of algorithms related to supervised, unsupervised, and reinforcement learning algorithms may be employed.

[0063] In one embodiment, generative AI (GenAI) may be used by the on-the-spot solution in transforming data. Vehicles are equipped with a variety of sensors, cameras, radar, LIDAR, etc., which collect a vast amount of data, such as images, speed measurements, GPS data, acceleration metrics, etc. However, once acquired, the raw data undergoes extensive pre-processing in terms of normalization, anonymization, imputation of missing values, and noise removal to make the data more effectively usable.

[0064] GenAI performs data preprocessing followed by data augmentation. Due to the limitations of datasets in capturing the vast complexity of real-world vehicle scenarios, augmentation tools are employed to extend the dataset. This includes image-specific transformations such as rotation, translation, and brightness adjustment. For non-image data, techniques like jittering can be used to introduce synthetic noise to simulate a wider range of conditions.

[0065] In this in-place solution, data generation comes next. Tools like Generative Adversarial Networks (GANs) or Variational Autoencoders (VAEs) are trained on existing datasets to generate new, plausible data samples. For example, a GAN may be tasked with creating images showcasing a vehicle in unexplored situations or from unique perspectives. As another example, sensor data synthesis may be performed to model and create synthetic measurements for such scenarios. Given the safety-critical nature of vehicles, a key step in using GenAI is validation. This validation involves comparing the output data with real-world datasets or using specialized tools like GAN classifiers to measure the realism of the created samples.

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

[0067] The 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 related to 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-making subsystems 316 within the vehicle node 310 to assist in decision-making.

[0068] The vehicle node 310 may include one or more decision-making subsystems 316 that drive decision-making processes around the vehicle node 310, such as, but not limited to, vehicle control, temperature control, charging control, etc. In some embodiments, the decision-making subsystem 316 collects data from one or more sensors 312 to aid in the decision-making process. In some embodiments, the decision-making subsystem 316 may collect data from one or more UIs 314 to aid in the decision-making process. In some embodiments, the decision-making subsystem 316 may provide feedback to the UIs 314.

[0069] The AI / ML production system 330 may be used by the decision-making subsystem 316 in the vehicle node 310 to assist in its decision-making process. The AI / ML production system 330 includes one or more AI / ML models 332 that execute to obtain necessary data, such as, but not limited to, predictions, classifications, UI prompts, etc. In some embodiments, the AI / ML production system 330 is hosted on a server. In some embodiments, the AI / ML production system 330 is cloud-hosted. In some embodiments, the AI / ML production system 330 is deployed in a distributed multi-node architecture. In some embodiments, the AI ​​production system resides on the vehicle node 310.

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

[0071] Once AI / ML models 332 are trained and validated in AI / ML development system 340, they may be stored in AI / ML model registry 360 for retrieval by either AI / ML development system 340 or one or more AI / ML production systems 330. In one embodiment, AI / ML model registry 360 resides on a dedicated server. In some embodiments, AI / ML model registry 360 is cloud-hosted. In other embodiments, AI / ML model registry 360 is a distributed database. In further embodiments, AI / ML model registry 360 resides on AI / ML production system 330.

[0072] 3B shows a process 300B for developing one or more AI / ML models to assist in decision-making for an AI-assisted vehicle or occupant. An AI / ML development system 340 performs steps for developing an AI / ML model 332, starting with data extraction 342. In some embodiments, vehicle and user data is extracted from database 320. In some embodiments, model feedback data is extracted from one or more AI / ML production systems 330.

[0073] Once the necessary data is extracted (342), it must be prepared for model training (344). In some embodiments, this step includes statistical testing of the data to determine how well it reflects real-world events, their distribution, and the diversity of data in the dataset. In some embodiments, based on the results of the statistical tests, one or more data transformations may be employed to normalize one or more values ​​in the dataset. In some embodiments, this step includes cleaning data deemed noisy. Noisy datasets include, but are not limited to, values ​​that do not contribute to training, such as null values ​​and long string values. Data preparation (344) may be a manual process or an automated process using one or more of the elements and functions described or depicted herein.

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

[0075] The dataset output from the 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.

[0076] The AI / ML model 332 is trained and tuned 350 using the training data set from the data partitioning step 348. In this step, the learning data set is fed to an AI / ML algorithm and an initial set of algorithm parameters. The performance of the AI / ML model 332 is then tested in the AI / ML development system 340 using the validation data set from step 348. These steps can be repeated, adjusting one or more algorithm parameters, until the model's performance is acceptable based on various goals and / or outcomes.

[0077] The AI / ML model 332 is evaluated (352) in a staging environment (not shown) that resembles the final AI / ML production system 330. This evaluation uses a validation dataset to verify that performance in the AI / ML production system 330 meets 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 staging environment is part of the AI / ML development system 340. In other embodiments, the staging environment is managed separately from the AI / ML development system 340. Once the AI / ML model 332 is validated, it is stored in the AI / ML model registry 360 and can be retrieved for deployment and future updates. As previously mentioned, in some embodiments, the model evaluation step 352 is a manual process or an automated process using one or more elements, functions, or aspects described or depicted herein.

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

[0079] 3C illustrates a process 300C for utilizing an AI / ML model to assist an AI-assisted vehicle or occupant in making decisions. As previously noted, the AI ​​model utilization process depicted herein reflects ML, a specific branch of AI, but the solutions herein are not limited to ML, nor are they limited to any particular AI algorithm or combination of algorithms.

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

[0081] Upon receiving the API 334 request, the AI / ML server process 336 may transform the data payload or portions of the data payload to form valid feature values ​​for the AI / ML model 332. Data transformations include, but are not limited to, combining data values, normalizing data values, and enriching the input data with data from other data sources. Once the necessary data transformations have been performed, the AI / ML server process 336 executes the appropriate AI / ML model 332 using the transformed input data. Upon receiving the execution results, the AI / ML server process 336 responds to the API caller, which is the decision subsystem 316 of the vehicle node 310. In some embodiments, the response may trigger an update to the UI 314 of the vehicle node 310. In some embodiments, the response includes a request identifier that the decision subsystem 316 can later use to provide feedback on the performance of the AI / ML model 332. Additionally, in some embodiments, immediate performance feedback may be logged by the AI / ML server process 336 to a model feedback log 338. In some embodiments, a failure of the execution model is the reason for the immediate feedback.

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

[0083] Many steps / functions that may utilize the AI / ML processes described herein include one or more of the following: detecting that a vehicle is connected to a charge point; the vehicle sending a request to a device associated with the vehicle to provide energy to the charge point, and in response, providing content to the device based on the amount of energy provided; registering access credentials for a software application with a server associated with the charge point, where providing includes retrieving the content from the software application via the server based on the access credentials and playing the content from the software application on the device associated with the vehicle; the vehicle sending a further request to a device associated with the vehicle to provide additional energy to the charge point; and in response to the vehicle providing the additional energy to the charge point, providing enhanced content to the device based on the amount of additional energy provided; pausing the content being provided to the device when the enhanced content has been provided; receiving a timestamp from the device identifying when the content was paused; providing the enhanced content at that time; estimating the time remaining for the vehicle to provide energy to the charge point; selecting additional content based on the remaining time; and playing the additional content on a device associated with the vehicle; and determining that the amount of energy in the vehicle exceeds a predefined threshold before transmitting, where the provided content is based on information related to another device not associated with the vehicle.

[0084] Data associated with any of these steps / features, as well as other features or functions described or depicted herein, AI / ML production system 330, and one or more of the other elements depicted in FIG. 3C may be used to process this data in a pre-conversion and / or post-conversion process. Data associated with this process may be used by vehicle node 310. In one embodiment, data associated with this process may be used by a charging station / charging point, a server, a wireless device, and / or any of the processors described or depicted herein.

[0085] 3D illustrates a process 300D for designing a new machine learning model via the system's user interface 370, according to an example embodiment. As an example, the model may be output as part of the AI / ML development system 340. Referring to FIG. 3D, a user can add pieces / components to the model being developed within the workspace 754 of the user interface 370 using input mechanisms from menus 372 of the user interface 370.

[0086] Menu 372 includes multiple graphical user interface (GUI) menu options that can be selected to reveal additional components that can be added to the model design shown in the workspace. The GUI menu includes options for adding elements to the workspace, such as functions that may include, for example, neural networks, machine learning models, AI models, data sources, transformations (e.g., vectorization, encoding), analytics, etc. The user can continue to add features to the model and connect them using edges or other elements to create a flow within the workspace. For example, the user may add node 376 to the flow of a new model in the workspace. For example, the user may connect node 376 to another node in the diagram via edge 378 to create a dependency in the diagram. When the user is finished, the user can save the model for subsequent training / testing.

[0087] In another example, the name of the object can be identified from a web page or user interface 370 where the object is viewed in a browser or workspace on a user device. A pop-up in the browser or workspace can be overlaid where the object is viewed, and the pop-up includes an option to navigate via a rule set to an identified web page that corresponds to an alternative object.

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

[0089] Instead of dividing files into blocks stored on disk in a file system, object storage treats objects as discrete units of data stored in a structurally flat data environment. Here, object storage may not use folders, directories, or complex hierarchies. Instead, each object may be a simple, self-contained repository containing data, metadata, and a unique identifier that client applications can use to find and access it. In this case, the metadata is more descriptive than in file-based approaches. The metadata can be customized with additional context that can be extracted and leveraged for other purposes, such as data analysis.

[0090] Objects stored in object storage 390 can be accessed via API 384. API 384 may be a Hypertext Transfer Protocol (HTTP)-based RESTful API (also known as RESTful web services). API 384 can be used by client applications to query object metadata to find desired objects (data) from any location on any device over the Internet. API 384 may use HTTP commands such as "PUT" or "POST" to upload an object, "GET" to retrieve an object, and "DELETE" to delete an object.

[0091] The object storage 390 may provide a directory 398 that uses object metadata to locate appropriate data files. The directory 398 may include descriptive information about each object stored in the object storage 390, such as a name, a unique identifier, a creation timestamp, a collection name, etc. To query objects in the object storage 390, a client application may send a command, such as an HTTP command, having an identifier of the object 392, a payload, etc. The object storage 390 may store the operations and results described herein, including correlating two or more lists of ranked assets with each other based on variables used by the two or more lists of ranked assets that have a correlation above a predetermined threshold.

[0092] FIG. 4A shows a diagram 400A illustrating the electrification of one or more elements. In one example, a vehicle 402B may provide power stored in its battery to one or more elements, including another vehicle 408B, a charging station 406B, and an electric power grid 404B. The electric power grid 404B is coupled to one or more charging stations 406B, which may be coupled to one or more vehicles 408B. This configuration enables distribution of electricity / power received from the vehicle 402B. The vehicle 402B can also interact with the other vehicles 408B, such as through communication via V2V technology, cellular, Wi-Fi, etc. The vehicle 402B may also interact with the other vehicles 408B, the charging stations 406B, and / or the electric power grid 404B wirelessly and / or via wires. In one example, the vehicle 402B is routed (or routes itself) to the electric power grid 404B, the charging stations 406B, or other vehicles 408B in a safe and efficient manner. Using one or more embodiments of this field solution, the vehicle 402B can provide energy to one or more of the elements depicted herein in various advantageous ways as described and / or depicted herein, further improving the safety and efficiency of the vehicle and positively impacting the environment as described and / or depicted herein.

[0093] Terms such as "energy," "electricity," and "power" may be used to refer to any form of energy that a vehicle receives, stores, uses, shares, and / or loses. Energy may be referred to in connection with a voltage source and / or current supply provided to a vehicle from an entity during charging / use operations. Energy may also be in the form of fossil fuels (e.g., for use in hybrid vehicles) or via alternative power sources, including, but not limited to, lithium-based, nickel-based, hydrogen fuel cells, atomic / nuclear energy, fusion-based energy sources, and energy generated during energy sharing and / or use operations to increase or decrease the energy level of one or more vehicles at a given time.

[0094] In one example, charging station 406B manages the amount of energy transferred from vehicle 402B so that vehicle 402B has enough charge to reach its destination. In one example, a wireless connection is used to wirelessly direct the amount of energy transferred between vehicles 408B, and both vehicles may be moving. In one embodiment, wireless charging may occur via stationary chargers and batteries (e.g., charging mats in garages or parking spaces) in vehicles aligned with each other. In one example, an idle vehicle, such as vehicle 402B (which may be autonomous), provides an amount of energy to charging station 406B and is directed to return to its origin (e.g., its original location or a different destination). In one example, a mobile energy storage unit (not shown) is used to collect excess energy from at least one other vehicle 408B and transfer the excess energy stored at charging station 406B. In one example, factors such as distance, time, as well as traffic conditions, road conditions, environmental / weather conditions, the condition of the vehicle (e.g., weight), the schedule of the occupant(s) using the vehicle, and the schedule of the prospective occupant(s) waiting for the vehicle determine the amount of energy to transfer to charging station 406B. In one example, vehicle 408B, charging station 406B, and / or electrical power grid 404B can provide energy to vehicle 402B.

[0095] In one embodiment, a location (not shown), such as a building or residence, is communicatively coupled to one or more of the electrical power grid 404B, the vehicle 402B, and / or the charging station 406B. Depending on external conditions, such as weather, the rate of electricity flow to one or more of the location, the vehicle 402B, and the other vehicle 408B may be modified. For example, if the outside temperature is extremely hot or extremely cold, increasing the likelihood of a power outage, the flow of electricity to the connected vehicles 402B / 408B may be slowed to minimize the likelihood of a power outage.

[0096] In one embodiment, vehicles 402B and 408B may be utilized as bidirectional vehicles. Bidirectional vehicles are vehicles that can function as mobile micro-grids, assisting in the supply of power to the power grid 404B and / or reducing power consumption when the power grid is under load. Bidirectional vehicles incorporate bidirectional charging, allowing for the transfer of energy from the vehicle to the power grid 404B in addition to charging the vehicle. With bidirectional charging, electricity flows in both directions: to and from the vehicle. When a vehicle is being charged, alternating current (AC) electricity from the power grid 404B is converted to direct current (DC). This is performed by one or more converters in the vehicle itself or in the charging station 406B. Energy stored in the vehicle's battery can be sent back to the power grid in the reverse direction. Energy is typically converted from DC to AC through a converter, also referred to as a bidirectional charger, located in the charging station 406B. Furthermore, the present solution, such as that described and depicted with respect to FIG. 4B, can be utilized in this network and / or other networks and / or systems.

[0097] FIG. 4B illustrates the interconnections between different elements 400B. The solution may be stored and / or executed, in whole or in part, on and / or by one or more computing devices 414C, 418C, 424C, 428C, 432C, 436C, 406C, 442C, and 410C associated with various entities that are communicatively coupled to and in communication with a network 402C. A database 438C is communicatively coupled to the network and enables data storage and retrieval. In one example, the database is an immutable ledger. One or more of the various entities may be a vehicle 404C, one or more service providers 416C, one or more public buildings 422C, one or more transportation infrastructure 426C, one or more residences 430C, an electric power grid / charging station 434C, a microphone 440C, and / or another vehicle 408C. Other entities and / or devices, such as one or more individual users using a smartphone 412C, a laptop 420C, an augmented reality (AR) device, a virtual reality (VR) device, and / or any wearable device, may also interoperate with the solution. The smartphone 412C, the laptop 420C, the microphone 440C, and other devices may be connected to one or more of the connected computing devices 414C, 418C, 424C, 428C, 432C, 436C, 406C, 442C, and 410C. One or more public buildings 422C may include various institutions. One or more public buildings 422C may utilize computing devices 424C. One or more service providers 416C may include a dealership, a tow truck service, a collision center, or other repair shop. One or more service providers 416C may utilize computing devices 418C. These various computing devices may be directly and / or communicatively coupled to one another via a wired network, a wireless network, a blockchain network, etc. Microphone 440C may be utilized as a virtual assistant in one example.In one example, the one or more traffic infrastructure components 426C may include one or more traffic signals, one or more cameras, one or more sensors including vehicle speed sensors or traffic sensors, and / or other traffic infrastructure components. The one or more traffic infrastructure components 426C may utilize a computing device 428C.

[0098] In one embodiment, whenever charge is transferred to or from a charging station and / or the electrical power grid, the entity that facilitates this is one or more of the vehicle, the charging station, a server, and a network communicatively coupled to the vehicle, the charging station, and the electrical power grid.

[0099] In one example, vehicle 408C / 404C can transport people, objects, permanently or temporarily fixed equipment, etc. In one embodiment, vehicle 408C can communicate with vehicle 404C via V2V communications via computers associated with each vehicle 406C and 410C and may be referred to as an automobile, vehicle, automobile, etc. Vehicle 404C / 408C may be a self-propelled wheeled conveyance such as a car, sport utility vehicle, truck, bus, van, or other motor- or battery- or fuel-cell-powered vehicle. For example, vehicle 404C / 408C may be an electric vehicle, a hybrid vehicle, a hydrogen fuel cell vehicle, a plug-in hybrid vehicle, or any other type of vehicle equipped with a fuel cell stack, a motor, and / or a generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, boats, and any other form of transportation capable of transportation. Vehicle 404C / 408C may be semi-autonomous or autonomous. For example, vehicle 404C / 408C may be self-piloted and may navigate without human input. An autonomous vehicle may have and use one or more sensors and / or navigation units to navigate autonomously. All data described or depicted herein may be stored, analyzed, processed, and / or transmitted by one or more of the elements of FIG. 4B.

[0100] FIG. 4C is another block diagram illustrating the interconnections between different elements in one embodiment 400C. A vehicle 412D is shown, including ECUs 410D and 408D and a head unit (also known as an infotainment system) 406D. An ECU is an embedded system of automotive electronics that controls one or more electrical systems or subsystems within a vehicle. ECUs include, but are not limited to, managing the vehicle's engine, braking system, gearbox system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECUs are connected to the vehicle's Controller Area Network (CAN) bus 416D. The ECUs can also communicate with a vehicle computer 404D via the CAN bus 416D. The vehicle's processor / sensor (e.g., vehicle computer) 404D may communicate with external elements, such as a server 418D, via a network 402D (e.g., the Internet). Each ECU 410D, 408D, and head unit 406D may include its own security policy. The security policy defines the allowable processes that can be executed in the appropriate context. In one example, some or all of the security policy may reside in the vehicle computer 404D.

[0101] The ECUs 410D and 408D and the head unit 406D can each include a custom security function element 414D that defines authorized processes and the contexts in which those processes are permitted to run. Context-based authorization to determine the appropriateness of a process allows the ECU to maintain secure operation and prevent unauthorized access from elements such as the vehicle's CAN bus. If the ECU encounters an unauthorized process, it can block the operation of that process. Automotive ECUs can use a variety of contexts to determine whether a process is operating within authorized bounds. For example, proximity contexts include nearby objects, the distance to approaching objects, speed, and trajectory relative to other moving objects, an indication of whether the vehicle is moving or parked, the vehicle's current speed, the state of the transmission, user-related contexts such as devices connected to the transport via wireless protocols, infotainment, cruise control, parking assist, driving assist, location-based contexts, and / or other contexts.

[0102] Referring to FIG. 4D , a connected vehicle operating environment 400D is illustrated, according to some embodiments. As depicted, a vehicle 410E includes a CAN bus 408E connecting vehicle elements 412E-426E. Although not depicted herein, other elements may be connected to the CAN bus. Illustrated elements connected to the CAN bus include a sensor set 412E, an electronic control unit 414E, an autonomous function or advanced driver assistance system (ADAS) 416E, and a navigation system 418E. In some embodiments, the vehicle 410E includes a processor 420E, a memory 422E, a communication unit 424E, and an electronic display 426E.

[0103] The processor 420E may include an arithmetic logic unit, a microprocessor, a general-purpose controller, and / or a similar processor array to perform calculations and provide electronic display signals to the display unit 426E. The processor 420E processes data signals and may include a variety of computing architectures, including a complex instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture implementing a combination of instruction sets. The vehicle 410E may include one or more processors 420E. Other processors, operating systems, sensors, displays, and physical components (not shown) communicatively coupled to each other may be used with the present solution.

[0104] The memory 422E is a non-transitory memory that stores instructions or data that can be accessed and executed by the processor 420E. The instructions and / or data may include code for executing the techniques described herein. The memory 422E may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory, or another memory device. In some embodiments, the memory 422E may also include non-volatile memory or similar permanent storage devices and media, such as a hard disk drive, a floppy disk drive, a compact disk read-only memory (CD-ROM) device, a digital versatile disk read-only memory (DVD-ROM) device, a digital versatile disk random access memory (DVD-RAM) device, a digital versatile disk rewritable (DVD-RW) device, a flash memory device, or some other mass storage device for permanently storing information. A portion of the memory 422E may be reserved for use as a buffer or virtual random access memory (VRAM). The vehicle 410E may include one or more memories 422E without departing from the current solution.

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

[0106] The navigation system 418E may describe at least one navigation route, including a start point and an end point. In some embodiments, the navigation system 418E of the vehicle 410E receives a request from a user for a navigation route, the request including the start point and the end point. The navigation system 418E may query the real-time data server 404E (via the network 402E) for navigation route data corresponding to the navigation route, including the start point and the end point. The real-time data server 404E transmits the navigation route data to the vehicle 410E via the wireless network 402E, and the communication system 424E stores the navigation data 418E in the memory 422E of the vehicle 410E.

[0107] The ECU 414E controls the operation of many systems of the vehicle 410E, including the ADAS system 416E. The ECU 414E may disable unsafe and / or unselected autonomous functions during a journey controlled by the ADAS system 416E in response to instructions received from the navigation system 418E. In this manner, the navigation system 418E may control whether the ADAS system 416E is activated or enabled so that the ADAS system 416E may be activated for a given navigation route.

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

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

[0110] The vehicle 410E may interact with other vehicles 406E through V2V technology. V2V communication may include, for example, sensing radar information corresponding to a relative distance to an external object, receiving GPS information of the target vehicle, setting an area in which the other vehicle 406E is located based on the sensed radar information, calculating a probability that the GPS information of the target vehicle is located in the set area, and identifying the vehicle and / or object corresponding to the radar information and the GPS information of the target vehicle based on the calculated probability.

[0111] To properly secure a vehicle, it is necessary to protect it not only from unauthorized physical access but also from unauthorized remote access (e.g., cyber threats). To prevent unauthorized physical access, vehicles are equipped with secure access systems, such as keyless entry. Meanwhile, security protocols are added to vehicle computers and computer networks to enable secure remote communication with the vehicle.

[0112] ECUs are nodes within a vehicle that control tasks ranging from operating the windshield wipers to the anti-lock braking system. ECUs are often connected to each other through a central network in the vehicle called the Controller Area Network (CAN). Cutting-edge features such as autonomous driving rely heavily on new and complex ECU implementations such as ADAS and sensors. While these new technologies help improve vehicle safety and the driving experience, they also increase the number of units inside the vehicle communicating with the outside world, making them more susceptible to attacks. Below are some examples of how to protect your vehicle from physical and remote intrusions:

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

[0114] In this example, the ECU includes a transceiver and a microcontroller. The transceiver is used to send and receive messages to and from the CAN bus. For example, the transceiver converts data from the microcontroller into the format of the CAN bus and converts data from the CAN bus into the format of the microcontroller. Meanwhile, the microcontroller interprets the messages and determines which messages to send, for example, using the ECU software installed on it.

[0115] Various security protocols may be implemented to protect the CAN from cyber threats. For example, sub-networks (e.g., sub-networks A and B) may be used to divide the CAN into smaller sub-CANs to limit an attacker's ability to remotely access the vehicle. In one embodiment, a firewall (or gateway, etc.) may be added to block messages from traversing the CAN bus across sub-networks. If an attacker gains access to one sub-network, the attacker cannot access the entire network. To further secure the sub-networks, as an example, the most critical ECUs are not placed on the same sub-network.

[0116] In addition to protecting a vehicle's internal network, the vehicle may also be protected when communicating with external networks, such as the Internet. One advantage of connecting 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. Such communication systems are often referred to as telematics because they involve a combination of telecommunications and information technology. Furthermore, the solutions herein, as described and illustrated, can be utilized in this network and / or other networks and / or systems, including those described and illustrated herein.

[0117] FIG. 4E illustrates an example 400E of vehicles 402I and 408I performing secure V2V communication using security certificates, according to an exemplary embodiment. Referring to FIG. 4E, vehicles 402I and 408I may perform V2V communication over a short-range network, a cellular network, etc. Prior to sending a message, vehicles 402I and 408I may sign the message using their respective public key certificates. For example, vehicle 402I may sign the V2V message using public key certificate 404I. Similarly, vehicle 408I may sign the V2V message using public key certificate 410I. Public key certificates 404I and 410I are, by way of example, associated with vehicles 402I and 408I, respectively.

[0118] Vehicles receiving each other's communications may verify the signatures, such as with certificate authority 406I. For example, vehicle 408I may verify with certificate authority 406I that the public key certificate 404I used by vehicle 402I to sign the V2V communication is authentic. If vehicle 408I successfully verifies public key certificate 404I, the vehicle knows the data is from a valid source. Similarly, vehicle 402I may verify with certificate authority 406I that the public key certificate 410I used by vehicle 408I to sign the V2V communication is authentic. Furthermore, solutions herein, such as those described and depicted with respect to FIG. 4E , can be utilized in this network and / or other networks and / or systems, including those described and depicted herein.

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

[0120] For example, the authentication module may store passwords, usernames, PIN codes, biometric scans, etc. for different vehicle users. The authentication module may determine whether a user (or technician) has permission to access certain settings, such as the vehicle's computer. In some embodiments, the authorization module may communicate with a network interface to download the necessary authorization information from an external server. When a user wishes to change a vehicle setting or modify technical details of the vehicle through a console or GUI in the vehicle or through an attached / connected device, the authorization module may require the user to verify themselves in some manner before such settings can be changed. For example, the authentication module may request a username, password, PIN code, biometric scan, a predefined line drawing or gesture, etc. In response, the authorization module may determine whether the user has the necessary permission (e.g., access) being requested.

[0121] The authentication module may be used to authenticate internal communications between ECUs on a vehicle's CAN network. As an example, the authentication module may provide information for authenticating communications between ECUs. As an example, the authentication module may send a bit signature algorithm to the ECUs on the CAN network. The ECUs use the bit signature algorithm to insert authentication bits into the CAN field of the CAN frame. All ECUs on the CAN network typically receive each CAN frame. The bit signature algorithm dynamically changes the position and amount of authentication bits each time a new CAN frame is generated by one of the ECUs. The authentication module may provide a list of ECUs (safe list) that do not need to use the authentication bits. The authentication module may communicate with a remote server to obtain updates to the bit signature algorithm and the like.

[0122] The encryption module may store asymmetric key pairs that the vehicle uses to communicate with other external user devices and vehicles. For example, the encryption module may provide a private key that the vehicle uses to encrypt / decrypt communications and a corresponding public key to other user devices and vehicles so that the other devices can decrypt / encrypt the communications. The encryption module may communicate with a remote server to receive new keys, key updates, keys for new vehicles, users, etc. The encryption module may also send updates of the local private / public key pair to the remote server.

[0123] FIG. 5A illustrates an exemplary vehicle configuration 500A for managing database transactions related to a vehicle, according to an exemplary embodiment. Referring to FIG. 5A, when a particular vehicle 525A is engaged in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, transportation service, etc.), the vehicle may receive assets 510A and / or discharge / transfer assets 512A pursuant to the transaction. A vehicle processor 526A resides on the vehicle 525A, and communication exists between the vehicle processor 526A, a database 530A, and a transaction module 520A. The transaction module 520A may record information such as assets, parties, credits, service details, dates, times, locations, results, notifications, unexpected events, etc. Those transactions in the transaction module 520A may be replicated in a database 530A. Database 530A may be one of an SQL database, a relational database management system (RDBMS), a relational database, a non-relational database, a blockchain, a distributed ledger, and may be on-board the vehicle, off-board the vehicle, accessed directly and / or over a network, and may be accessible to the vehicle.

[0124] In one embodiment, when a vehicle reaches a state where it needs to share services with another vehicle, it may engage with the other vehicle to perform various actions, such as sharing, transferring, or taking a service call. For example, the vehicle may need to charge its battery, have tire problems, or 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 may notify another vehicle that is in its network and operating on its blockchain member service. The vehicle processor resides in another vehicle, and communication exists between the vehicle processor, a second database, the vehicle processor, and the transaction module. The other vehicle may then receive information from the vehicle and / or from a server (not shown) via a wireless communication request to perform package pickup. The transaction is recorded in the transaction modules of both vehicles. Credits are transferred from the vehicle to the other vehicle, and a record of the transferred service is recorded in the first database. It is assumed that the blockchains are different from each other or are recorded on the same blockchain used by all members. The first database may be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, and may be on-board the vehicle or off-board the vehicle and may be accessible directly and / or over a network.

[0125] FIG. 5B illustrates a blockchain architecture configuration 500B according to an example embodiment. Referring to FIG. 5B, the blockchain architecture 500B may include a particular blockchain element, e.g., a group of blockchain member nodes 502B-505B as part of a blockchain group 510B. In an example embodiment, a permissioned blockchain is not accessible to all participants, but rather only to authorized members who have access to the blockchain data. Blockchain nodes participate in many activities, such as adding blockchain entries and the validation process (consensus). One or more of the blockchain nodes may endorse entries based on an endorsement policy or provide ordering services to all blockchain nodes. Blockchain nodes may initiate blockchain actions (e.g., authentication) and require writes to a blockchain immutable ledger stored in the blockchain (a copy of which may also be stored in the underlying physical infrastructure).

[0126] Blockchain transactions 520B are stored in computer memory once they are received and approved by a consensus model dictated by member nodes. Approved transactions 526B are stored in the blockchain's current block and committed to the blockchain via a commit procedure that involves performing a hash of the transaction's data content in the current block and referencing a previous hash in a previous block. Within the blockchain, one or more smart contracts 530B may exist that define the terms and actions of a transaction agreement, including smart contract executable application code 532B, such as registered recipients, vehicle features, requirements, permissions, sensor thresholds, etc. The code may be configured to identify whether a requesting entity is registered for vehicle service, what service features it is entitled to / requested to receive given its profile status, and whether to monitor its behavior in subsequent events. For example, if a service event occurs and a user is in the vehicle, sensor data monitoring may be triggered to identify that a particular parameter, such as the vehicle charge level, has exceeded / fallen below a particular threshold for a particular period of time, which may result in a change in the current status, requiring an alert to be sent to an administrator (i.e., vehicle owner, vehicle operator, server, etc.) so that service can be identified and stored for reference. The vehicle sensor data collected may be based on the type of sensor data used to collect information about the vehicle's state. The sensor data may also form the basis of vehicle event data 534B, such as where to travel, average speed, maximum speed, acceleration, whether there was a collision, whether the planned route was traveled, where the next destination is, whether safety measures have been taken, whether the vehicle has sufficient charge / fuel, etc. All such information forms the basis of smart contract conditions 530B and is stored on the blockchain. For example, sensor thresholds stored in the smart contract may be used as the basis for whether the detected service is required, when, and where the service should be performed.

[0127] In one embodiment, example blockchain logic includes a blockchain application interface as an API or plug-in application that links to a computing device and execution platform for a particular transaction. A blockchain configuration may include one or more applications linked to an application programming interface (API) that access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.), may be created according to customized configurations desired by participants, maintain their own state, control their own assets, and receive external information, which are deployed as entries and installed on all blockchain nodes by adding them to the distributed ledger.

[0128] The application code of a smart contract provides the basis for blockchain transactions by establishing the application code, which, when executed, puts the terms of the transaction into effect. When the smart contract is executed, an approved transaction is generated and transferred to the blockchain platform. The platform includes a computing device that performs security / authorization and transaction management, and a storage portion as memory that stores transactions and smart contracts in the blockchain.

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

[0130] The blockchain architecture configurations of Figures 5A and 5B may process and execute program / application code through one or more interfaces exposed and provided by the blockchain platform. As a non-limiting example, smart contracts may be created to implement reminders, updates, and / or other notifications subject to changes, updates, etc. Smart contracts may be used to specify authentication and access requirements as well as rules associated with use of the ledger. For example, information may include new entries that may be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer. Results may include decisions to reject or approve new entries based on criteria defined in the smart contract and / or peer consensus. Physical infrastructure may be utilized to obtain any of the data or information described herein.

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

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

[0133] The smart contract executable code includes a code interpretation of the smart contract and may have additional functionality. As described herein, the smart contract executable code may be program code deployed on a computing network and executed and verified by a chain validator during the consensus process. The smart contract executable code receives a hash , and retrieves from the blockchain a hash associated with a data template created using a previously stored feature extractor. If the hash of the hash identifier matches the hash created from the stored identifier template data, the smart contract executable code sends an authorization key to the requested service. The smart contract executable code may write data associated with the cryptographic details to the blockchain.

[0134] FIG. 5C illustrates a blockchain configuration for storing blockchain transaction data, according to an exemplary embodiment. Referring to FIG. 5C, exemplary configuration 500C provides for a vehicle 562C, a user device 564C, and a server 566C to share information with a distributed ledger (i.e., blockchain) 568C. The server may represent a service provider entity that queries a vehicle service provider to share user profile rating information when a known, established user profile seeks to rent a vehicle with an established rating profile. Server 566C may receive and process data related to the vehicle's service requirements. When a service event occurs, such as when vehicle sensor data indicates the need for fuel / charging, maintenance service, etc., smart contracts may be used to invoke rules, thresholds, sensor information collection, etc. Blockchain transaction data 570C is stored for each transaction, such as an access event, subsequent updates to the vehicle's service status, event updates, etc. The transaction may include the parties involved, requirements (e.g., age 18, eligible for service, valid driver's license, etc.), coverage level, distance traveled during the event, registered recipients authorized to access the event and host vehicle services, rights / permissions, sensor data acquired during the vehicle event operation to record details of the upcoming service event and identify the vehicle's condition status, and thresholds used to determine whether the service event is complete and whether the vehicle's condition status has changed.

[0135] FIG. 5D illustrates a blockchain block and the contents of block structures 582A-582n that can be added to a distributed ledger, according to an example embodiment. Referring to FIG. 5D, a client (not shown) may submit entries to a blockchain node to perform activities on the blockchain. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, to propose entries to the blockchain. Multiple blockchain peers (e.g., blockchain nodes) may maintain copies of the blockchain network state and the distributed ledger. Different types of blockchain nodes / peers may exist in a blockchain network, including supporting peers that simulate and support entries proposed by clients, and committing peers that verify the support, validate the entries, and commit the entries to the distributed ledger. In this example, a blockchain node may act as an endorser node, a committer node, or both.

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

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

[0138] An endorsing node receives entries from clients and endorses the entries based on the simulation results. An endorser node holds a smart contract that simulates the entry proposal. 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 simulated entry. The manner in which an entry is endorsed depends on the endorsement policy specified in the smart contract executable code. An example of an endorsement policy is "a majority of endorsing peers must endorse the entry." Different channels may have different endorsement policies. The endorsed entry is forwarded by the client application to the ordering service.

[0139] The ordering service accepts endorsed entries, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service can initiate a new block when a threshold number of entries is reached, a timer times out, or other conditions are met. In this example, a blockchain node is a committing peer that receives data block 582A for storage on the blockchain. The ordering service may consist of a cluster of orderers. The ordering service does not process entries or smart contracts or maintain a shared ledger. Rather, the ordering service accepts endorsed entries and can specify the order in which those entries are committed to the distributed ledger. The architecture of a blockchain network can be designed so that specific implementations of "ordering" are pluggable components.

[0140] Entries are written to the distributed ledger in a consistent order. The order of entries is established to ensure that updates to the state database are valid when committed to the network. Unlike cryptocurrency blockchain systems, where ordering is achieved by solving a cryptographic puzzle or by mining, in this example the parties to the distributed ledger may choose the ordering mechanism that best suits their network.

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

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

[0143] In some embodiments, the block data 590A may also store transaction-specific data 586A that adds additional information to the block's hash link chain in the blockchain. Thus, the data 586A can be stored in an immutable log of the block on the distributed ledger. Some of the advantages of storing such data 586A are reflected in the various embodiments disclosed and illustrated herein. The block metadata 588A may store multiple fields of metadata (e.g., as a byte array). The metadata fields may include a signature at the time of block creation, a reference to the last constituent block, an entry filter that identifies valid and invalid entries in the block, the last persisted offset of the ordering service that ordered the block, etc. The signature, last constituent block, and orderer metadata may be added by the ordering service. Alternatively, the block committer (e.g., a blockchain node) may add valid / invalid information based on an endorsement policy, validation of the read / write set, etc. The entry filter may include a byte array of a size equal to the number of entries in the block data and a validation code that identifies whether the entry is valid or invalid.

[0144] The other blocks 582B-582n in the blockchain also have headers, files, and values. However, unlike the first block 582A, each of the other blocks' headers 584B-584n includes a hash value of the immediately preceding block. The hash value of the immediately preceding block may be just the hash value of the immediately preceding block's header, or it may be the hash value of the entire immediately preceding block. By including the hash value of the immediately preceding block in each remaining block, it is possible to trace back, block by block, from the Nth block back to the generating blocks (and associated original files), establishing an auditable and immutable chain of custody, as shown by arrow 592.

[0145] FIG. 5E illustrates a process 500E by which a new block is added to a distributed ledger 520E according to an example embodiment, and FIG. 5D illustrates the contents of a new data block structure 530E for the blockchain of FIG. 5E according to an example embodiment. Referring to FIG. 5E, a client (not shown) can submit a transaction to blockchain nodes 511E, 512E, and / or 513E. A client may be instructions received from any source to perform an activity on the blockchain 522E. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, that proposes a transaction to the blockchain. Multiple blockchain peers (e.g., blockchain nodes 511E, 512E, and 513E) can maintain a copy of the blockchain network state and the distributed ledger 520E. Different types of blockchain nodes / peers may exist in a blockchain network, including supporting peers that simulate and support transactions proposed by clients, and committing peers that verify the support, validate the transaction, and commit the transaction to the distributed ledger 520E. In this example, blockchain nodes 511E, 512E, and 513E may act as endorser nodes, committer nodes, or both.

[0146] The distributed ledger 520E includes a blockchain that stores immutable, ordered records in blocks and a state database 524E (current world state) that maintains the current state of the blockchain 522E. There may be one distributed ledger 520E per channel, and each peer maintains its own copy of the distributed ledger 520E for each channel in which it is a member. The blockchain 522E is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions. Block links (shown by arrows in Figure 5E) are generated by appending the hash of the previous block's header to the current block's block header. In this way, all transactions on the blockchain 522E are sequenced and cryptographically linked to prevent tampering with the blockchain data without breaking the hash link. Furthermore, because of the linking, the latest block on the blockchain 522E represents all previous transactions. The blockchain 522E may be stored in a peer file system (local storage or attached storage) and supports append-only blockchain workloads.

[0147] The current state of the blockchain 522E and distributed ledger 520E may be stored in a state database 524E, where the current state data represents the latest values ​​of all keys included in the chain transaction log of the blockchain 522E. Chaincode invocations execute transactions against the current state of the state database 524E. To make these chaincode interactions highly efficient, the latest values ​​of all keys are stored in the state database 524E. The state database 524E may contain an indexed view into the transaction log of the blockchain 522E and therefore can be regenerated off-chain at any time. The state database 524E may be automatically restored at peer startup (or generated as needed) before transactions are accepted.

[0148] An endorser node receives transactions from clients and endorses them based on the simulation results. An endorser node holds a smart contract that simulates a transaction proposal. When an endorser node endorses a transaction, it creates a transaction endorsement, which is a signed response from the endorser node to the client application indicating its endorsement of the simulated transaction. The manner in which a transaction is endorsed depends on the endorsement policy, which may be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must endorse the transaction." Different channels may have different endorsement policies. The endorsed transaction is forwarded by the client application to the ordering service 510E.

[0149] The ordering service 510E accepts approved transactions, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service 510E may initiate a new block when a transaction threshold is reached, a timer times out, or other conditions are met. In the example of FIG. 5E, blockchain node 512E is a committing peer that receives a new data block 530E for storage in blockchain 522E. The first block of a blockchain is sometimes called a genesis block, which contains information about the blockchain, its members, the data stored therein, etc.

[0150] The ordering service 510E may consist of a cluster of orderers. The ordering service 510E does not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service 510E may accept approved transactions and specify the order in which those transactions are committed to the distributed ledger 522E. The architecture of the blockchain network may be designed so that specific implementations of "ordering" are pluggable components. Transactions are written to the distributed ledger 520E in a consistent order. The order of transactions is established to ensure that updates to the state database 524E are valid when committed to the network. Unlike cryptocurrency blockchain systems where ordering is achieved by solving a cryptographic puzzle or by mining, in this example, the parties to the distributed ledger 520E may choose the ordering mechanism that best suits their network.

[0151] Once the ordering service 510E initializes the new data block 530E, the new data block 530E may be broadcast to committing peers (e.g., blockchain nodes 511E, 512E, and 513E). In response, each committing peer validates the transaction in the new data block 530E by verifying that the read set and write set still match the current world state in the state database 524E. Specifically, the committing peer may determine whether the read data that existed when the endorser simulated the transaction is identical to the current world state in the state database 524E. If the committing peer validates the transaction, the transaction is written to the blockchain 522E on the distributed ledger 520E, and the state database 524E is updated with the write data from the read-write set. If the transaction fails—that is, if the committing peer finds that the read-write set does not match the current world state in the state database 524E—the transaction ordered in the block is still included in the block but is marked as invalid, and the state database 524E is not updated.

[0152] Referring to FIG. 5F 500F, a new data block 530 (also referred to as a data block) stored in a blockchain 522E of a distributed ledger 520E may include multiple data segments, such as a block header 540, block data 550, and block metadata 560. It should be understood that the various depicted blocks and their contents, such as the new data block 530 and its contents shown in FIG. 5F, are merely illustrative and are not intended to limit the scope of the illustrative embodiments. The new data block 530 may store N (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) transaction information in the block data 550. The new data block 530 may also include a link to a previous block (e.g., on the blockchain 522E of FIG. 5E) in the block header 540. In particular, the block header 540 may include a hash of the previous block's header. 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 numbers of the new data block 530 may be unique and may be assigned in various orders, such as incremental / sequential order starting from zero.

[0153] Block data 550 may store transaction information for each transaction recorded in new data block 530. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of distributed ledger 520E (shown in FIG. 5E), transaction ID, epoch, payload visibility, chaincode path (deploy tx), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identification such as public key or certificate, client signature, sponsor identification, sponsor signature, proposal hash, chaincode event, response status, namespace, read set (e.g., list of keys and versions read by the transaction), write set (e.g., list of keys and versions), start key, end key, list of keys, Merkel tree query summary, etc. Transaction data may be stored for each of the N transactions.

[0154] In one embodiment of the on-the-spot solution, block data 564 may include data including one or more of detecting that a vehicle is connected to a charge point, the vehicle sending a request to a device associated with the vehicle to provide energy to the charge point, and in response providing content to the device based on the amount of energy provided.

[0155] 5F, blockchain data 563 is depicted in block data 550, but may also be located in block header 540 or block metadata 560. In some embodiments, an identifier for the vehicle, an identifier for the charging point, the amount of energy provided, an identifier for the device, an identifier for the paused content, a timestamp associated with the content at the time of pause, etc. may be written to blockchain data 563 and committed to the blockchain ledger.

[0156] The block metadata 560 may store multiple fields of metadata (e.g., as a byte array). The metadata fields may include a signature at the time of block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions in the block, and the last persisted offset of the orderer service that ordered the block. The signature, last constituent block, and orderer metadata may be added by the orderer service 510E in FIG. 5E. Alternatively, the block committer (e.g., blockchain node 512E in FIG. 5E) may add valid / invalid information based on an endorsement policy, validation of the read / write set, etc. The transaction filter may include a byte array with a size equal to the number of transactions in the block data and a validation code that identifies whether the transaction was valid / invalid.

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

[0158] An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application-specific integrated circuit ("ASIC"). Alternatively, the processor and the storage medium may reside as discrete components. For example, FIG. 6 illustrates an exemplary computer system architecture 600, which may represent or integrate any of the above-described components, etc.

[0159] 6 is a diagram illustrating a computing environment according to an exemplary embodiment. FIG. 6 is not intended to suggest any limitation as to the scope of use or functionality of the application embodiments described herein. However, computing environment 600 may be implemented to perform any of the functionality described herein. In computer environment 600, computing system 601 is operational in numerous other general-purpose or special-purpose computing system environments or configurations.

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

[0161] Computing system 601 is not depicted in FIG. 6 within a cloud, but it may be located within a cloud. However, computing system 601 need not be within a cloud, except to the extent that it may be affirmatively indicated. Computing system 601 may be described in the general context of computer system-executable instructions, such as program modules, executed by computing system 601. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform tasks or implement particular abstract data types. As shown in FIG. 6, computing system 601 of computing environment 600 is depicted in the form of a general-purpose computing device. Components of computing system 601 may include, but are not limited to, one or more processors or processing units 602, a system memory 630, and a bus 620 that couples various system components, including system memory 630, to processing unit 602.

[0162] Processing unit 602 includes one or more computer processors of any type now known or to be developed. Processing unit 602 may include circuitry distributed across multiple integrated circuit chips. Processing unit 602 may implement multiple processor threads and multiple processor cores. Cache 632 is memory located within the processor chip package or "off-chip," as depicted in FIG. 6. Cache 632 is typically used for data or code that should be available for quick access by threads or cores executing on processing unit 602. In some computing environments, processing unit 602 may be designed to work with qubits and perform quantum computing.

[0163] The network adapter 603 enables the 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 external networks, efficiently and reliably exchanging data. The network adapter 603 may include hardware, such as a modem or Wi-Fi signal transceiver, and software that packetizes and / or depacketizes data for communication network transmission. The network adapter 603 supports various communication protocols to ensure compatibility with network standards. For Ethernet connections, it may comply with protocols such as IEEE 802.3, and for wireless communications, it may support the IEEE 802.11 standard, Bluetooth, Near Field Communication (NFC), or other network wireless standards.

[0164] Computing system 601 may include removable / non-removable, volatile / non-volatile computer storage 610. By way of example only, storage 610 may be a non-removable, non-volatile magnetic medium (not shown, typically referred to as a "hard drive"). One or more data interfaces may connect it to bus 620. In embodiments requiring computing system 601 to have large amounts of storage (e.g., when computing system 601 stores and manages large databases locally), this storage may be provided by storage 610 designed for storing very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers.

[0165] Operating system 611 is software that manages the hardware resources of computing system 601 and provides common services to computer programs. Operating system 611 may take several forms, including various known proprietary operating systems and open-source Portable Operating System Interface-type operating systems that employ a kernel.

[0166] Bus 620 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using various bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus. Bus 620 is a signal-conducting path that allows various components of computing system 601 to communicate with one another.

[0167] Memory 630 may be any volatile memory now known or later developed. Examples include dynamic random access memory (RAM 631) or static type RAM 631. Typically, volatile memory is characterized by random access, although this is not required unless affirmatively indicated. In computing system 601, memory 630 is in a single package and internal to computing system 601; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally with respect to computing system 601. By way of example only, memory 630 may provide for reading from and writing to non-removable, non-volatile magnetic media (illustrated as storage device 610, typically referred to as a "hard drive"). Memory 630 may include at least one program product having a set of (e.g., at least one) program module configured to perform various functions. A typical computing system 601 may include cache 632, a specialized volatile memory that is generally faster than RAM 631 and generally located near the processing unit 602. Cache 632 stores frequently accessed data and instructions accessed by processing unit 602 to speed up processing time. Computing system 601 may include non-volatile memory 633 such as ROM, PROM, EEPROM, and flash memory. Non-volatile memory 633 often contains programming instructions for booting the computer, including information needed to boot the basic input / output system (BIOS) and operating system 611.

[0168] Computing system 601 may also communicate with one or more peripheral devices 641 via input / output (I / O) interface 640. Such devices may include one or more devices that allow a user to interact with computing system 601, such as a keyboard, pointing device, display, etc., and / or any device that allows computing system 601 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may occur via I / O interface 640. As depicted, I / O interface 640 communicates with other components of computing system 601 via bus 620.

[0169] Network 650 is any computer network capable of receiving and / or transmitting data. Network 650 may include a WAN, a LAN, a private cloud, or the public Internet and may communicate computer data over non-local distances by any technology now known or later developed. The depicted connections may be wired and / or wireless and may traverse other components not shown. In some embodiments, network 650 may be replaced and / or supplemented by a LAN designed to communicate 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 transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers. Computing system 601 connects to network 650 via network adapter 603 and bus 620.

[0170] User device 651 is any computer system used and controlled by an end user in conjunction with computing system 601. For example, in the hypothetical case where computing system 601 is designed to provide recommendations to the end user, the recommendations would typically be communicated over network 650 from network adapter 603 of computing system 601 to user device 651, allowing user device 651 to display or otherwise present the recommendations to the end user. User devices may be a wide range of devices, including PCs, laptops, tablets, handhelds, mobile phones, etc.

[0171] The remote server 660 is any computer that provides at least some data and / or functionality to the computing system 601 over a network 650, such as a WAN, a virtual private network (VPN), a private cloud, or the Internet. These networks 650 may communicate with a LAN to reach users. The user interface may include a web browser or an application that facilitates communication between the user and the remote data. Such applications are called "thin" desktops or "thin clients." Thin clients typically incorporate software programs that emulate a desktop session. Mobile applications may also be used. The remote server 660 may also host a remote database 661, which may be located on a single remote server 660 or distributed across multiple remote servers 660. The remote database 661 may be accessible from a database client application installed locally on the remote server 660, other remote servers 660, the user device 651, or the computing system 601 over the network 650.

[0172] A public cloud 670 provides on-demand access to computer system resources, including data storage and computing power, without direct, active management by users. Public clouds 670 are often distributed, with data centers in multiple locations for availability and performance. Computing resources on a public cloud 670 are shared among multiple tenants through virtual computing environments consisting of virtual machines 671, databases 672, containers 673, and other resources. Containers 673 are isolated, lightweight software for running applications on a host operating system 611. Containers 673 are built on top of the host operating system kernel and contain only applications and a few lightweight operating system APIs and services. In contrast, virtual machines 671 are software layers that include the complete operating system 611 and kernel. Virtual machines 671 are built on top of a hypervisor emulation layer designed to abstract the host computer hardware from the operating software environment. Public clouds 670 typically offer hosted databases 672, which abstract high-level database management activities. It should further be understood that one or more of the elements described or depicted in FIG. 6 may perform one or more of the operations, functions, or features described or depicted herein.

[0173] At least one exemplary embodiment of the system, method, and non-transitory computer-readable medium is illustrated in the accompanying drawings and described in the foregoing detailed description. However, it will be understood that the present application is not limited to the disclosed embodiments, but is capable of numerous rearrangements, modifications, and substitutions, as set forth and defined in the following claims. For example, the functionality of the various illustrated systems may be performed by one or more of the modules or components described herein, or in a distributed architecture, and may include sets of transmitters, receivers, or both. For example, all or part of the functionality performed by individual modules may be performed by one or more of these modules. Furthermore, the functions described herein may be performed at various times and in connection with various events, either internal or external to the modules or components. Furthermore, information transmitted between the various modules may be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or multiple protocols. Furthermore, messages sent or received by any of the modules may be transmitted or received directly and / or via one or more of the other modules.

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

[0175] Note that some of the system functionality described herein is illustrated as modules to further emphasize implementation independence. For example, a module may be implemented as a hardware circuit made from custom very large scale integrated (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, etc.

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

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

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

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

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

Claims

1. Detecting that the vehicle is connected to a charging point; - transmitting a request by the vehicle to a device associated with the vehicle to supply energy to the charging point; in response, providing content to the device based on the amount of energy provided; A method comprising:

2. registering access credentials of a software application with a server associated with the charging point, wherein said providing comprises obtaining said content from said software application via said server based on said access credentials; playing the content from the software application on the device associated with the vehicle; 10. The method of claim 1, comprising:

3. the vehicle transmitting a further request to the device associated with the vehicle to supply additional energy to the charging point; In response to the vehicle providing the additional energy to the charging point, providing enhanced content to the device based on the amount of the additional energy provided; 10. The method of claim 1, comprising:

4. pausing the content being provided to the device when the enhanced content is provided; receiving a timestamp from the device identifying when the content was paused; 4. The method of claim 3, comprising:

5. estimating the remaining time for the vehicle to supply energy to the charging point; selecting additional content based on the remaining time; playing the additional content on the device associated with the vehicle; and 10. The method of claim 1, comprising:

6. and determining whether the vehicle has an amount of energy equal to or greater than a predefined threshold before transmitting. The method of claim 1.

7. The provided content is based on information about other devices unrelated to the vehicle. The method of claim 1.

8. Memory and a processor coupled to the memory; Equipped with The processor is configured to detect when a vehicle is connected to a charging point, transmit a supply for the vehicle to supply energy to the charging point to a device associated with the vehicle, and in response provide content to the device based on the amount of energy supplied. Device.

9. The processor is further configured to register access credentials for a software application with a server associated with the charging point, retrieve the content from the software application via the server based on the access credentials, and play the content from the software application on the device associated with the vehicle.

9. The apparatus of claim 8.

10. The processor is further configured to send a further request to the device associated with the vehicle for the vehicle to supply additional energy to the charging point, and in response to the vehicle supplying the additional energy to the charging point, provide enhanced content to the device based on the amount of the supplied additional energy.

9. The apparatus of claim 8.

11. The processor is configured to pause the content being provided to the device when the enhanced content is provided, and to receive a timestamp from the device identifying when the content was paused.

11. The apparatus of claim 10.

12. The processor is further configured to estimate a remaining time for the vehicle to supply energy to the charging point, select additional content based on the remaining time, and play the additional content on the device associated with the vehicle.

9. The apparatus of claim 8.

13. The processor is configured to determine, prior to the transmitting, whether the vehicle has an amount of energy greater than or equal to a predefined threshold.

9. The apparatus of claim 8.

14. The provided content is based on information about other devices unrelated to the vehicle.

9. The apparatus of claim 8.

15. A computer-readable storage medium having stored thereon instructions that, when executed by a processor, cause the processor to detect that a vehicle is connected to a charging point, send a request to a device associated with the vehicle for the vehicle to supply energy to the charging point, and in response, provide content to the device based on the amount of energy supplied.

16. the processor registering access credentials of a software application with a server associated with the charging point, wherein the providing includes obtaining the content from the software application via the server based on the access credentials; and playing the content from the software application on the device associated with the vehicle.

16. The computer-readable storage medium of claim 15.

17. the processor transmitting a further request to the device associated with the vehicle for the vehicle to supply additional energy to the charging point; and, in response to the vehicle supplying the additional energy to the charging point, providing enhanced content to the device based on the amount of the supplied additional energy.

16. The computer-readable storage medium of claim 15.

18. The processor pauses the content being provided to the device when the enhanced content is provided, and receives a timestamp from the device identifying when the content was paused.

18. The computer-readable storage medium of claim 17.

19. The processor estimates a remaining time for the vehicle to supply energy to the charging point, selects additional content based on the remaining time, and plays the additional content on the device associated with the vehicle.

16. The computer-readable storage medium of claim 15.

20. The processor, prior to the transmitting, performs determining whether the vehicle has an amount of energy greater than or equal to a predefined threshold.

16. The computer-readable storage medium of claim 15.

Images