To provide content related to the amount of energy received.

Abstract

An exemplary operation includes, by a charging point, one or more of the following: receiving energy from a vehicle connected to the charging point; and providing the vehicle with content relating to the amount of energy received from the vehicle.

Description

[[BACKGROUND ART]]

[0001] Vehicles or transportation means such as automobiles, motorcycles, trucks, airplanes, and trains generally provide the need for transportation for occupants and / or goods in various ways. Vehicle-related functions may be identified and utilized by various computing devices, such as smartphones or computers disposed on and / or off the vehicle. [[SUMMARY OF THE INVENTION]]

[0002] One exemplary embodiment provides a method comprising one or more of: receiving, by a charging point, energy from a vehicle connected to the charging point; and providing content related to the amount of energy received from the vehicle to the vehicle.

[0003] Another exemplary embodiment provides a system comprising a processor and a memory, wherein the processor and the memory are communicatively coupled, and the processor performs one or more of: receiving, by a charging point, energy from a vehicle connected to the charging point; and providing content related to the amount of energy received from the vehicle to the vehicle.

[0004] A further exemplary embodiment provides a computer-readable recording medium comprising instructions that, when read by a processor, cause the processor to perform one or more of: receiving, by a charging point, energy from a vehicle connected to the charging point; and providing content related to the amount of energy received from the vehicle to the vehicle. [[BRIEF DESCRIPTION OF THE DRAWINGS]]

[0005] [Figure 1A] FIG. 1A shows an example of a system diagram according to an exemplary embodiment. [Figure 1B] FIG. 1B shows a further example of a system diagram according to an exemplary embodiment. [Figure 2A]Figure 2A shows a vehicle network diagram according to an exemplary embodiment. [Figure 2B] Figure 2B shows another vehicle network diagram according to an exemplary embodiment. [Figure 2C] Figure 2C shows yet another vehicle network diagram according to an exemplary embodiment. [Figure 2D] Figure 2D shows a further vehicle network diagram according to an exemplary embodiment. [Figure 2E] Figure 2E shows a flowchart according to an exemplary embodiment. [Figure 2F] Figure 2F shows another flowchart according to an exemplary embodiment. [Figure 3A] Figure 3A shows an artificial intelligence (AI) / machine learning (ML) network diagram for integrating an artificial intelligence (AI) model to an arbitrary decision point in an exemplary embodiment. [Figure 3B] Figure 3B illustrates the process for developing an artificial intelligence (AI) / machine learning (ML) model to support decision-making for AI-assisted vehicles or occupants. [Figure 3C] Figure 3C illustrates the process for utilizing artificial intelligence (AI) / machine learning (ML) models to support decision-making for AI-assisted vehicles or occupants. [Figure 3D] Figure 3D shows a machine learning network diagram according to an exemplary embodiment. [Figure 3E] Figure 3E shows a machine learning network diagram according to an exemplary embodiment. [Figure 4A] Figure 4A shows a diagram illustrating the electrification of one or more elements according to an exemplary embodiment. [Figure 4B] Figure 4B shows a diagram illustrating the interconnections between different elements according to an exemplary embodiment. [Figure 4C] Figure 4C shows a further diagram illustrating the interconnections between different elements according to an exemplary embodiment. [Figure 4D] Figure 4D shows a further diagram illustrating the interconnections between elements according to an exemplary embodiment. [Figure 4E]Figure 4E shows a further illustration depicting an example of a vehicle performing secure vehicle-to-vehicle (V2V) communication using security certificates, according to an exemplary embodiment. [Figure 5A] Figure 5A shows an example of a vehicle configuration for managing vehicle-related database transactions, according to an exemplary embodiment. [Figure 5B] Figure 5B shows an exemplary blockchain group according to an exemplary embodiment. [Figure 5C] Figure 5C illustrates an exemplary interaction between an element and a blockchain in an exemplary embodiment. [Figure 5D] Figure 5D shows exemplary data block interactions according to an exemplary embodiment. [Figure 5E] Figure 5E shows a blockchain network diagram according to an exemplary embodiment. [Figure 5F] Figure 5F shows an exemplary new data block according to an exemplary embodiment. [Figure 6] Figure 6 shows an exemplary system supporting one or more exemplary embodiments. [Modes for carrying out the invention]

[0006] It will be readily apparent that the components described herein, as generally explained and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Therefore, the following detailed description of at least one embodiment of the method, apparatus, computer-readable storage medium, and system, as shown in the accompanying figures, is not intended to limit the scope of the claimed application, but merely represents a selected embodiment. The multiple embodiments described herein are not intended to limit the scope of the solution. The computer-readable storage medium may be a non-transient computer-readable storage medium.

[0007] Communication between a vehicle and certain entities such as a remote server, other vehicles, and local computing devices (e.g., smartphones, personal computers, in-vehicle computers, etc.) may be transmitted and / or received and processed by one or more “components” which may be hardware, firmware, software, or a combination thereof. The components may be part of these entities, computing devices, or certain other computing devices. For example, consensus decisions related to blockchain transactions may be performed by one or more computing devices or components related to the vehicle (which may be any elements described and / or depicted herein), and one or more components located outside or away from the vehicle.

[0008] The features, structures, or characteristics described herein can be combined in any suitable way in one or more embodiments. For example, throughout this specification, the use of “exemplary embodiments,” “several embodiments,” “first embodiment,” or other similar phrases means that certain features, structures, or characteristics described in relation to one or more embodiments may be included in one or more other embodiments described or depicted herein. Thus, all one or more embodiments described or depicted throughout this specification may refer to the same embodiment. These embodiments may work in conjunction with any of the other embodiments and may not be functionally distinct, and the described features, structures, or characteristics may be combined in any suitable way in one or more embodiments. Multiple features, elements, and steps described in a particular aspect, but only illustratively, or described herein, may be used together in various combinations, unless otherwise expressly indicated herein. In the figures, any connection between elements can enable unidirectional and / or bidirectional communication, even if the depicted connection is a unidirectional or bidirectional connection such as an arrow.

[0009] In the solution herein, a vehicle may include one or more of an automobile, a truck, an internal combustion engine (ICE) vehicle, a battery electric vehicle (BEV), a fuel cell vehicle, any vehicle utilizing renewable energy sources, a hybrid vehicle, an e-pallet, 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 place to another.

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

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

[0012] Within communication infrastructure, a distributed database is a distributed storage system that includes multiple nodes communicating with each other. A blockchain is an example of a distributed database, containing an append-only, immutable data structure (i.e., a distributed ledger) that can maintain records between untrusted parties. In this specification, untrusted parties are referred to as peers, nodes, or peer nodes. Each peer holds a copy of the database records, and no single peer can modify the database records unless a consensus is reached among the distributed peers. For example, peers can execute a consensus protocol to validate storage entries in the blockchain, group storage entries into blocks, and build a hash chain through the blocks. This process forms a ledger by ordering the storage entries necessary to maintain consistency. Public blockchains and permissionless blockchains allow anyone to participate without a 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 protect interactions between groups of entities that share a common goal but do not fully trust or can not trust each other, such as businesses exchanging funds, goods, information, etc. The solution in this case can work with permissioned and / or permissionless blockchain settings.

[0013] A smart contract is a trusted decentralized application that leverages the tamper-proof properties of a shared or distributed ledger, which may be in the form of a blockchain, and the basic agreement among member nodes called endorsement or an endorsement policy. Generally, blockchain entries are "endorsed" before being committed to the blockchain, and entries that are not endorsed are ignored. In a typical endorsement policy, the executable code of the smart contract allows specifying endorsers for an entry in the form of a set of peer nodes required for endorsement. When a client sends an entry to a peer specified in the endorsement policy, the entry is executed to validate the entry. After validation, the entry enters an ordering phase, where a consensus protocol generates an ordered sequence of endorsed entries grouped into blocks.

[0014] A node is a communication entity in a blockchain system. A "node" can perform logical functions in the sense that 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 the nodes in various ways. For example, a client node or submitting client node submits an entry invocation to a recommender (e.g., a peer) and broadcasts an entry proposal to an ordering service (e.g., an ordering node). Another type of node is a peer node, which can receive entries submitted by clients, commit entries, and maintain the state of blockchain entries and a copy of the ledger. A peer may also serve the role of an endorser. An ordering service node or orderer is a node that runs communication services for all nodes, and implements delivery guarantees such as broadcasting to each peer node in the system when committing entries to change the world state of the blockchain. The world state may constitute the first blockchain entry and typically includes control information and setup information.

[0015] The ledger is a sequenced, tamper-proof record of all state transitions in a blockchain. State transitions can arise from invocations (i.e., entries) of smart contract executable code submitted by participating parties (e.g., client nodes, order nodes, endorser nodes, peer nodes, etc.). As a result of an entry, a set of key-value pairs of assets may be committed to the ledger as one or more operands, such as create, update, or delete. The ledger contains the blockchain (also called the chain), and blocks store an immutable, continuous record. The ledger also contains a state database, which maintains the current state of the blockchain. There is usually 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, with each block containing a sequence of N entries. The block 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 in the blockchain represents all previous entries on the chain, thus ensuring that all peer nodes are in a consistent and trustworthy state. Chains can be stored in the peer node's file system (i.e., local, connected storage, cloud, etc.), efficiently supporting the append-only nature of blockchain workloads.

[0017] The current state of the immutable ledger represents the most recent values ​​for all keys contained in the chain entry log. Because the current state represents the most recent key values ​​known to the channel, it is sometimes called the world state. Smart contract execution code calls execute entries against the current state data of the ledger. To streamline the interaction of smart contract execution code, the most recent key values ​​can be stored in a state database. The state database may simply be an indexed view of the chain's entry log and can therefore be regenerated from the chain at any time. The state database may be automatically restored (or generated as needed) when a peer node starts up and before entries are accepted.

[0018] Blockchain differs from traditional databases in that it is not a centralized storage but rather a decentralized, immutable, and secure storage, and nodes must share changes to the records within the storage. Some of the properties inherent in blockchain and useful for blockchain implementation include, but are not limited to, immutable ledger, smart contracts, security, privacy, decentralization, consensus, endorsement, and accessibility.

[0019] An exemplary embodiment provides services to a specific vehicle and / or a user profile applicable to that vehicle. For example, the user may be the owner of the vehicle or the operator of a vehicle owned by someone else. The vehicle may require service at regular intervals, and the need for service may require authorization before service can be granted. The service center may also provide services to nearby vehicles based on the vehicle's current route plan and the relative level of service requests (e.g., immediate, severe, moderate, minor). The vehicle's needs can be monitored via one or more vehicle and / or road sensors or cameras, which report sensing data to a central controller computer device inside and / or away from the vehicle. This data is then transferred to a management server for review and action. Sensors may be located inside the vehicle, outside the vehicle, on fixed objects away from the vehicle, or on one or more other vehicles in close proximity to the vehicle. Sensors may also be associated with vehicle speed, braking, acceleration, fuel level, service need, gear shift, steering, etc. Furthermore, the sensors described herein may be devices such as wireless devices located inside and / or near the vehicle. Sensor information can also be used to identify whether the vehicle is being driven safely and whether the occupants have engaged in any unexpected vehicle conditions, such as during access to and / or use of the vehicle. Vehicle information collected before, during, and / or after the operation of the vehicle may be identified and stored in a transaction on a shared / distributed ledger, which may be generated in a “distributed” manner, such as through a blockchain member group, as determined by a permissioning consortium, and committed to an immutable ledger.

[0020] Each stakeholder (i.e., owner, user, company, agent, etc.) may wish to limit the exposure of their personal information, and therefore, blockchain and its immutability can be used to manage permissions for each specific user vehicle profile. Smart contracts may be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when services are needed, identify collision and / or deterioration events, identify safety concern events, identify parties to events, and provide delivery to registered entities requesting access to such vehicle event data. Results can also be identified and the necessary information shared among registered companies and / or individuals based on a consensus approach related to the blockchain. Such an approach may not be implementable in traditional centralized databases.

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

[0022] A solution in this context, in certain embodiments, involves authorizing a vehicle for service via an automated, rapid authentication scheme. For example, driving to a charging station or fuel pump may be performed by a vehicle operator or an autonomous vehicle, and authorization to receive charge or fuel may be performed without delay, provided that authorization is received by the service and / or charging station. The vehicle may provide a communication signal that identifies the vehicle having a currently active profile linked to an account authorized to accept service, which may later be corrected by compensation. Additional means may be used to provide further authentication, such as another identifier being transmitted wirelessly 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] Shared and received data is maintained in a single database (e.g., a database server) and is generally stored in a database located in one specific location. This location is often a central computer, such as a desktop central processing unit (CPU), server CPU, or mainframe computer. Information stored in a centralized database is usually accessible from multiple different locations. Centralized databases are easy to manage, maintain, and control, and are particularly suitable for security purposes because they are centralized in one place. In a centralized database, data redundancy is minimized because all data is stored in a single location, and there is only one primary record for a given dataset. Blockchain can be used to store vehicle-related data and transactions.

[0024] Any operation described herein may be performed by one or more processors (such as microprocessors, sensors, electronic control units (ECUs), head units, etc.) which may or may not be installed in a vehicle, and which may or may not have memory, and which may or may not be installed in a vehicle (such as servers, computers, mobile / wireless devices, etc.). One or more processors may communicate with other memory and / or other processors installed in or installed in other vehicles in order to utilize data transmitted by and / or to the vehicle. One or more processors and other processors may transmit data, receive data, and use this data to perform one or more operations described or depicted herein.

[0025] Figure 1A shows an example of a system diagram 100 according to an exemplary embodiment. In some embodiments, the solution in question is fully or partially implemented in the memory 105 of server 103, in the memory 110 of processor 111 associated with vehicle 102, in the memory 123 of server 121 associated with content provider 106, in the memory 138 of processor 139 associated with charging point 107, or in the memory of one or more other processors associated with devices and / or entities referred to herein. In some embodiments, one or more of server 103, processor 111, server 121, or processor 139 may include a microcontroller with one or more central processing unit (CPU) cores, along with program memory and programmable input / output peripherals. The program memory may be provided, for example, in the form of flash memory.

[0026] In some embodiments, the charging point 107 receives energy from the vehicle's battery 113 when the vehicle 102 is connected to the charging connector 131 of the charging point 107. For example, a processor 139 can direct the flow of energy from the battery 113 to the charging connector 131 via a battery management system 112. Content may be provided to the vehicle 102 from a content provider 106, and the content is related to the amount of energy received from the vehicle's battery 113. For example, content may be retrieved from a content database 120 by a server 121 and transmitted over the network 104. Content may be received over the network 104 by a processor 111 and transmitted to a multimedia device 117 for playback. Alternatively, or additionally, content may be retrieved by the processor 139 from a locally provided content database 122 at the charging point 107.

[0027] In some embodiments, processor 111 and / or processor 139 determine the amount of time to receive energy. Processor 111 and / or processor 139 may determine content based on the amount of time. For example, processor 111 and / or processor 139 may monitor the battery management system 112 to determine the state of charge (SoC) of battery 113. Based on the SoC, processor 111 and / or processor 139 can determine the time it takes for battery 113 to discharge. Based on the time it takes for battery 113 to discharge, processor 139 at charging point 107 can determine the time it takes for battery 113 to supply a desired, specified, or requested amount of energy to charging point 107. For example, processor 111 and / or processor 139 can determine the amount of energy supplied to charging point 107 by battery 113 from a vehicle profile and / or user profile. In further embodiments, when the amount of time constitutes a first amount of time, a first content may be provided to vehicle 102. If the amount of time consists of a second amount of time that is shorter than the first amount of time, the second content may be provided to the vehicle 102, the first content lasting for a first duration, and the second content lasting for a second duration that is shorter than the first duration.

[0028] In some embodiments, the vehicle 102's memory 110 may store a vehicle profile and / or user profile, which specifies the amount of energy provided by the battery 113. For example, the vehicle profile may specify that all stored energy in the battery 113 may be transferred to the charging point 107 as long as a minimum threshold energy, such as 20% SoC, remains in the battery 113. Alternatively, or additionally, the processor 139 and / or processor 111 may determine the amount of energy provided by the battery 113 based on one or more of the following: the SoC of the battery 113, the location of the charging point 107, the likelihood of the vehicle 102's destination as determined by the vehicle 102's Global Positioning System (GPS) device 127, the time, or the vehicle's route as determined by the vehicle 102's GPS device 127. For example, if the user of vehicle 102 leaves the office at 6 p.m. and stops at charging point 107 on the way home, processor 139 and / or processor 111 need to ensure that the battery 113 of vehicle 102 has enough energy (SoC) to get the user home. Alternatively or additionally, the vehicle profile and / or user profile may specify that the user of vehicle 102 does not want to arrive home later than 7 p.m., and therefore the amount of energy drawn from battery 113 can be limited so that the user of vehicle 102 has enough time to get home after transferring energy to charging point 107.

[0029] In some embodiments, the processor 139 determines the urgency of the need for energy to be received from the battery 113 of the vehicle 102. Based on this determination, the processor 139 may calculate a schedule for the charging point 107 to receive energy from the battery 113. The processor 139 and / or the processor 111 can monitor the amount of time elapsed before the charging point 107 begins receiving energy from the battery 113. The processor 139 and / or the processor 111 can compare the schedule with the amount of time elapsed. In response to the comparison, the processor 139 and / or the processor 111 may determine the content to be sent to the vehicle 102. In further embodiments, a notification indicating an urgent need for energy is sent by the processor 139 to the processor 111 of the vehicle 102 via the network 104. The notification can be displayed on the vehicle's multimedia device 117. Alternatively, or additionally, the notification may be sent by the processor 139 via the network 104 to a mobile device 118 associated with the user of the vehicle 102. In a further embodiment, the urgency of the need is provided by the processor 139, wirelessly via the network 104, and / or by a server operably coupled to the charging point 107 via the network 104, such as the grid server 144 of the electric grid 143.

[0030] In some embodiments, a first portion of the content is provided to the vehicle 102 by the processor 139 in response to the charging point 107 receiving a first portion of the amount of energy received from the battery 113 of the vehicle 102. A second portion of the content is provided to the vehicle 102 by the processor 139 in response to the charging point 107 receiving a second portion of the amount of energy received from the battery 113 of the vehicle 102.

[0031] In a further embodiment, the first and second parts are determined based on the total length of time the vehicle 102 provides energy to the charging point 107. In yet another embodiment, the first and second parts are determined by dividing the total length of time by 2 and / or by applying a mathematical ratio to the first and second parts. For example, if the total time is 40 minutes, the first part may be 20 minutes and the second part may be 20 minutes. In yet another embodiment, the first and second parts are determined based on the importance of the energy received by the charging point 107. For example, if the total length of time is 40 minutes, the importance of receiving energy in the first 30 minutes may be higher than the importance of receiving energy in the last 10 minutes. Thus, the first part may be 30 minutes and the second part may be 10 minutes.

[0032] In some embodiments, the charging point 107 receives energy from the battery 113 and transfers the received energy to the battery bank 115 of the charging point 107 via the battery management system 114. In another embodiment, the charging point 107 receives energy from the battery 113 and transfers the received energy to the electric grid 143, the electric company, and / or government agencies. In further embodiments, the first part may not occur during the peak hours of the electric grid 143, and the second part may occur during the peak hours of the electric grid 143. For example, 30 minutes of non-peak time may be of equal importance to 10 minutes of peak time.

[0033] In some embodiments, the processor 139 determines the rate at which energy is received from the vehicle's battery 113 by the charging point 107. Based on this determination, the processor 139 instructs the content provider 106 to provide content from its content database 120 and / or the charging point 107's content database 122 at a content delivery rate commensurate with the energy reception rate.

[0034] Figure 1B shows a further example of the system diagram 150 according to an exemplary embodiment. In some embodiments, the solution in question is fully or partially performed in the memory 105 of server 103, in the memory 110 of processor 111 associated with vehicle 102, in the memory 123 (shown in Figure 1A) of server 121 associated with content provider 106, in the memory 138 of processor 139 associated with charging point 107, or in the memory of one or more other processors associated with devices and / or entities referred to herein. In some embodiments, one or more of server 103, processor 111, server 121, or processor 139 may include a microcontroller with one or more central processing unit (CPU) cores, along with program memory and programmable input / output peripherals. The program memory may be provided, for example, in the form of flash memory.

[0035] In some embodiments, the processor 139 and / or processor 111 determine the location 108 of the charging point 107. If the determined location 108 is a residence, the content may be provided to a device such as a multimedia device 145 associated with the residence. If the determined location 108 is not a residence, the content may be provided to one or more devices associated with one or more occupants of the vehicle 102, such as a first multimedia device 128, a second multimedia device 129, and / or a mobile device 118.

[0036] In some embodiments, the processor 111 uses the occupant sensor 116 to determine the position of one or more occupants in the vehicle 102. For example, the occupant sensor 116 may be a seat belt sensor, a vehicle seat pressure sensor, a proximity detection device, an optical scanner, an infrared detector, a camera, a carbon dioxide detector, a sensor for detecting a mobile device 118, or another type of sensor.

[0037] In some embodiments, the content consists of first content and second content. For example, the first content may include audio-only content, and the second content may include audiovisual content. The processor 111 may provide the first content to one or more front seats of the vehicle 102, and the second content to one or more rear seats of the vehicle 102. For example, the first content may be provided to a first multimedia device 128, which serves one or more front seats of the vehicle 102. The second content may be provided to a second multimedia device 129, which serves one or more rear seats of the vehicle 102. In further embodiments, the vehicle 102 is moving, for example, as determined by GPS 127. The processor 139 and / or processor 111 provide content to one or more non-drivers of the vehicle 102, or provide content to the vehicle 102 in audio-only form.

[0038] In some embodiments, the processor 111 directs content to a content playback device based on the position of one or more occupants determined by the occupant sensor 116. For example, the content playback device is one of a first multimedia device 128, a second multimedia device 129, or a mobile device 118. When one or more occupants are in the front seats of the vehicle 102, the processor 111 may direct the content to the first multimedia device 128, which serves the front seats of the vehicle 102. When one or more occupants are in the rear seats of the vehicle 102, the processor may direct the content to the second multimedia device 129, which serves the rear seats of the vehicle.

[0039] In one embodiment, the system dynamically provides tiered, personalized infotainment content to vehicle occupants in exchange for the vehicle supplying energy to a charging point. This system operates with a dynamic pricing system for energy exchanged at the charging point, based on real-time factors such as current energy demand, time of day, and overall energy availability in the power grid. For example, during peak hours of high electricity demand, the cost of energy transmission from the vehicle to the grid may increase. To offset these higher costs, the charging point offers premium content to vehicle occupants. This premium content may include exclusive access to high-definition movies, live event streaming, virtual reality experiences, and subscriptions to premium music and podcasts. Conversely, during off-peak hours when electricity demand is low and energy transfer costs are reduced, the charging station offers standard content such as basic news updates, weather forecasts, and radio streaming services. This tiered content system is directly linked to the energy pricing model, ensuring that users always receive value commensurate with their energy costs. Furthermore, the system utilizes user preferences and historical data to learn the content preferences of repeat users and provides personalized content recommendations based on time of day, current energy prices, and individual user history. The system incorporates gamification elements, allowing users who consistently provide energy during peak hours to earn points and rewards redeemable for special content or discounts on future energy exchanges.

[0040] In one embodiment, the system provides vehicle occupants with personalized augmented reality (AR) content in exchange for energy transferred to a charging station. Once the vehicle sends energy back to the charging point, its occupants can access the personalized AR content. For example, when a vehicle connects to a charging station and the energy transfer process begins, the system unlocks an AR experience tailored to the occupants' location and interests. This experience could include virtual tours of nearby historical sites, interactive AR games, or educational content about local wildlife and environmental features. The experience can be viewed through AR glasses or the vehicle's multimedia system. The content is also dynamic and changes according to the vehicle's location. For example, if the vehicle is charging near a museum, the AR experience might offer a virtual tour of the museum's latest exhibits. Near a nature park, it might offer an interactive experience about the park's ecosystem. The system caters to the specific interests of passengers. For example, it might offer educational games or virtual zoo tours to children in the vehicle, while providing deeper content about local history and cultural landmarks to adults. The system also integrates with the vehicle's safety features. For example, while the vehicle is stationary during charging, AR content can interactively provide the driver with safety tips and vehicle maintenance information.

[0041] In one embodiment, the system encourages community engagement by exchanging energy from a vehicle to a charging point for digital vouchers and exclusive content from local businesses. This system integrates vehicle charging with local commerce, supporting local businesses. As a vehicle returns energy to a charging point, occupants receive digital coupons, discounts, exclusive content, and services from a network of local businesses partnered with the charging station. Upon connecting to the charging station, the vehicle is authenticated and its energy contribution is measured. This measurement is converted into a value equivalent to digital vouchers or content offers. Charging stations equipped with advanced communication systems work with a centralized server managing a database of participating local businesses and their offerings. Depending on the amount of energy the vehicle provides, a corresponding offer is selected and sent directly to the vehicle's infotainment system or the occupants' mobile devices. Offers range from discounts at nearby cafes and exclusive use at local entertainment venues to special promotions at retail stores. The system encourages car owners to contribute energy while promoting traffic to local businesses. The system leverages historical user data to provide personalized recommendations tailored to user interests and past activities. This system incorporates a feedback loop, allowing users to evaluate their experiences at companies they visit through the program. This feedback improves the recommendation algorithm, ensuring a consistently high-quality user experience while simultaneously providing valuable insights to local businesses.

[0042] In one embodiment, the system unlocks educational materials for vehicle occupants in exchange for energy supplied to a charging station, transforming charging time into a learning opportunity. As the vehicle transfers energy at a charging point, various educational materials are unlocked and streamed or downloaded to the vehicle's infotainment system or the occupants' personal devices. The content ranges from ebooks and educational videos to interactive learning modules and documentaries, covering a wide range of topics including science, history, technology, art, and language. The content is curated to accommodate various age groups and learning levels, making it accessible to children, teenagers, and adults. For example, while the car is charging, children in the back seat can immerse themselves in interactive educational games or watch animated science explanations, while adults in the front seat can listen to educational podcasts or watch documentaries related to their interests. The system also includes language learning programs, allowing occupants to learn a new language through immersive lessons and exercises during charging time. Educational content is tailored based on the user's profile. The profile includes information about the resident's educational interests, learning style, and past interactions with the system. Personalization ensures that each user receives educational, engaging, and relevant content. Furthermore, the system tracks learning progress chronologically, allowing users to continue learning from where they left off, even if they are charging at a different station. The system can partner with educational institutions and content providers, creating opportunities for co-developing and distributing content.

[0043] In one embodiment, the system provides vehicle occupants with personalized health and wellness content, such as meditation sessions or fitness routines, in exchange for energy supplied to the charging station. Once the vehicle connects to the charging station and supplies energy, the system unlocks a variety of health and wellness content accessible from the vehicle's infotainment system and the occupants' devices. This content may include guided meditation sessions, personalized fitness routines, wellness podcasts, nutritional advice, and personalized health tips based on the user's preferences and previous interactions with the system. For example, occupants can engage in a 15-minute guided meditation or stress-relieving breathing exercise while charging, allowing them to recharge and relax. They can also perform short exercises in the vehicle for those who tend to sit for long periods while driving or in the car. Furthermore, the system provides healthy eating tips and recipes tailored to dietary preferences and health goals. The system can also integrate with wearable health devices to provide more personalized content based on real-time health data from the occupants. For example, if a wearable device indicates an elevated stress level, the system might suggest a calming meditation or a soothing music playlist. Similarly, if the system detects that a resident has been sitting for an extended period, it may recommend a series of mobility exercises. The system tracks health and wellness efforts over the long term, allowing users to set goals and monitor their progress. For example, it can track how often residents participate in meditation sessions or perform fitness exercises, providing gentle reminders and encouragement to maintain regular healthy habits.

[0044] In one embodiment, the system receives energy from a connected vehicle and provides content tailored to the vehicle's occupants based on the amount of energy transferred. This system utilizes a battery management system to manage the energy flow from the vehicle's battery to the charging point. The system provides the vehicle with content related to the amount of energy received. Content delivery occurs via a network connecting various components, including servers and processors located both in the vehicle and at the charging point, as well as servers associated with content providers. Content, ranging from multimedia to important notifications, is retrieved from a content database, remotely from content providers, or locally at the charging point. The retrieved content is transmitted via the network to multimedia devices within the vehicle and played. The system determines the duration of the energy transaction and adjusts the content provided accordingly. The system assesses the vehicle's battery charge status and the required energy transfer to the charging point, considering factors such as the vehicle's location, expected destination, time of day, and energy requirements to reach the user's home after charging. The system adjusts the content based on the urgency of the energy need, determined by monitoring elapsed time and comparing it to a pre-calculated schedule for energy reception. The system further adjusts content based on the vehicle's occupants detected via occupant sensors. Content is delivered to the appropriate multimedia device within the vehicle, depending on the occupant's position. For example, front-seat occupants may receive audio-only content, while rear-seat occupants may receive audiovisual content.

[0045] The flowcharts depicted herein, such as Figures 2C, 2D, 2E, and 2F, are separate examples, but may represent the same or different embodiments. Any operation in one flowchart may be adopted and shared with another flowchart. No exemplary operation is intended to limit any embodiment or the subject matter of the corresponding claim.

[0046] The important point is that all the flowcharts and corresponding processes derived from Figures 2C, 2D, 2E, and 2F may be part of the same process or may share subprocesses with each other, so that the diagrams can be combined into a single preferred embodiment that does not require one specific operation but performs a specific operation from one exemplary process and specific operations from one or more additional processes. All exemplary processes relate to the same physical system and can be used separately or interchangeably.

[0047] This solution can be used in combination 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.

[0048] Figure 2A shows a vehicle network diagram 200 according to an exemplary embodiment. The network consists of elements including vehicle 202 including processor 204, and vehicle 202' including processor 204'. Vehicles 202 and 202' communicate with each other via processors 204 and 204', and other elements (not shown) including transceivers, transmitters, receivers, storage, sensors, and other elements that can provide communication. Communication between vehicles 202 and 202' can occur directly, via private and / or public networks (not shown), or via other vehicles and elements including one or more of processors, memory, and software. Although depicted as a single vehicle and processor, multiple vehicles and processors may exist. One or more applications, features, steps, solutions, etc., described and / or depicted herein may be utilized and / or provided by the elements herein.

[0049] Figure 2B shows another vehicle network diagram 210 according to an exemplary embodiment. The network consists of elements including vehicle 202 including a processor 204, and vehicle 202' including a processor 204'. Vehicles 202, 202' communicate with each other via processors 204, 204', and other elements (not shown) including transceivers, transmitters, receivers, storage, sensors, and other elements that can provide communication. Communication between 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 processors, memory, and software. Processors 204, 204' can further communicate with one or more elements 230 including sensors 212, wired devices 214, wireless devices 216, a database 218, a mobile phone 220, vehicle 222, a computer 224, an input / output (I / O) device 226, and a voice application 228. Processors 204, 204' can further communicate with an element including one or more of a processor, memory, and software.

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

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

[0052] The processor 204 performs one or more of the following actions by the charging point: receiving energy from the vehicle connected to the charging point 244C, and providing the vehicle with content related to the amount of energy received from the vehicle 246C.

[0053] Figure 2D shows a further vehicle network diagram 250 according to an exemplary embodiment. The network comprises elements including a vehicle 202, a processor 204, and a non-transient computer-readable medium 242D. The processor 204 is communicably coupled to the computer-readable medium 242D and element 230 (as depicted in Figure 2B). The 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 the following: determining the amount of time to receive energy and determining content based on the amount of time (244D); determining the location of a charging point and providing the content to a device associated with the dwelling if the determined location is a dwelling, and providing the content to one or more devices associated with one or more occupants of the vehicle if the determined location is not a dwelling (245D); providing a first part of the content in response to the charging point receiving a first part of the amount of energy received and providing a second part of the content in response to the charging point receiving a second part of the amount of energy received (246D); determining the rate of reception (247D); providing the content at a content distribution rate commensurate with the rate of reception based on the determination (247D); determining the location of one or more occupants in the vehicle (248D); and directing the content to a content playback device based on the location of one or more occupants (249D).

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

[0056] The processor 204 performs one or more of the following: receiving confirmation of an event from one or more elements described or depicted herein, the confirmation constitutes a blockchain consensus between peers represented by any of the elements, and executes a smart contract to record the confirmation in the blockchain consensus. The consensus is formed between any element 230 and / or any element described or depicted herein, including vehicles, servers, wireless devices, etc. In another example, vehicle 202 may be any element 230 and / or any element described or depicted herein, including servers, wireless devices, etc.

[0057] The processor and / or computer-readable medium may be located entirely or partially inside or outside the vehicle. Steps or functions stored in the computer-readable medium may be executed in whole or in part by the processor and / or any of the elements, in any order. Furthermore, one or more steps or functions may be executed at additional, omitted, or combined points in time.

[0058] Figure 2E shows a flowchart 260 according to an exemplary embodiment. Referring to Figure 2E, the solution in this case includes, by a charging point, one or more of the following: receiving energy from a vehicle connected to the charging point (244E) and providing the vehicle with content related to the amount of energy received from the vehicle (246E).

[0059] Figure 2F shows another flowchart 270 according to an exemplary embodiment. Referring to Figure 2F, the solution in this case includes one or more of the following: determining the amount of time to receive energy and determining content based on the amount of time (244F); determining the location of a charging point and providing content to a device associated with the dwelling if the determined location is a dwelling, and providing content to one or more devices associated with one or more occupants of the vehicle if the determined location is not a dwelling (245F); providing a first portion of content in response to the charging point receiving a first portion of the amount of energy received and providing a second portion of content in response to the charging point receiving a second portion of the amount of energy received (246F); determining the rate of reception (247F); providing content at a content distribution rate commensurate with the rate of reception based on the determination (247F); determining the location of one or more occupants in the vehicle (248F); and directing content to a content playback device based on the location of one or more occupants (249F).

[0060] Technological advancements are typically built upon the foundations of prior technologies, and this is also true for artificial intelligence (AI) models. AI classification systems describe the stages of AI progress. The initial classification, known as "reactive machines," progresses to the current AI classification of "limited memory machines" (also called "artificial narrow intelligence"), then to "theory of mind" (also called "artificial general intelligence"), and finally to the AI ​​classification of "self-aware machines" (also called "artificial superintelligence"). The current limited memory machines are a growing group of AI models built upon the foundations of their predecessors, the reactive machines. Reactive machines emulate human responses to stimuli, but their capabilities are limited because they generally cannot learn from past experiences. As AI models developed learning capabilities, their classification was elevated to limited memory machines. This current classification inherits all the capabilities of reactive machines while possessing abilities such as learning from large amounts of data, detecting patterns, solving problems, generating data, and making 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 the characteristics of limited-memory machines. Generative AI models combine limited-memory machine technologies incorporating ML and DL, forming the building blocks for future AI models. For example, Theory of Mind is the next advancement in AI models, which may be able to perceive, connect, and react by generating appropriate responses in response to entities with which it interacts. Furthermore, evolving into the "self-aware" category, AI models will be able to understand and evoke the emotions of entities with which they interact, and will also possess their own emotions, beliefs, and needs. Generative AI models are essential and core to future artificial intelligence models. As described herein, generative AI refers to current generative AI models and future AI models.

[0061] Figure 3A shows an AI / ML network (Figure 300A) supporting decision points for an AI-assisted vehicle or occupant. While not limited to these, other areas of AI, such as 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 shown in these embodiments. Furthermore, the AI ​​models included in these embodiments are not limited to specific AI algorithms. Any algorithm or combination of algorithms relating to supervised, unsupervised, and reinforcement learning algorithms may be employed.

[0062] In one embodiment, Generative AI (GenAI) may be used in the data transformation by the solution presented here. Vehicles are equipped with a variety of sensors, cameras, radar, and LiDAR, and vast amounts of data such as images, speed measurements, GPS data, and acceleration measurements are collected. However, once the raw data is acquired, it undergoes preprocessing, which may include normalization, anonymization, imputation of missing values, or denoising, in order to make the data more effectively usable.

[0063] GenAI performs data augmentation following data preprocessing. Because the dataset has limitations in capturing the immense complexity of real-world vehicle scenarios, augmentation tools are employed to expand 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 and simulate a wider range of conditions.

[0064] In this solution, data generation is then performed on the data. Tools such as Generative Adversarial Networks (GANs) or Variational Autoencoders (VAEs) are trained on existing datasets to generate new, plausible data samples. For example, a GAN might be tasked with creating images that showcase a vehicle in uncharted territory or from a unique perspective. As another example, synthesis of sensor data may be performed to model and create synthetic measurements for such scenarios. Given the safety-critical nature of the vehicle, a crucial step in using GenAI is validation. This validation may involve comparing the output data to real-world datasets or using specialized tools such as GAN classifiers to measure the reality of the crafted samples.

[0065] The vehicle node 310 may include a plurality of sensors 312, including but not limited to optical sensors, weight sensors, cameras, LiDAR, and radar. In some embodiments, these sensors 312 transmit data to a database 320 that stores data about the vehicle and its occupants. In some embodiments, these sensors 312 transmit data to one or more decision-making subsystems 316 within the vehicle node 310 to assist in decision-making.

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

[0067] The vehicle node 310 may include one or more decision subsystems 316 that drive decision-making processes around it, but are not limited to vehicle control, temperature control, or charge control. In some embodiments, the decision subsystem 316 collects data from one or more sensors 312 to support the decision-making process. In some embodiments, the decision subsystem 316 may collect data from one or more UIs 314 to support the decision-making process. In some embodiments, the decision subsystem 316 may provide feedback to the UIs 314.

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

[0069] The AI / ML development system 340 creates one or more AI / ML models 332. In some embodiments, the AI / ML development system 340 develops and trains one or more AI models 332 using data in the database 320. In some embodiments, the AI / ML development system 340 utilizes feedback data from one or more AI / ML production systems 330 for the development of new models and / or for retraining existing models. In one embodiment, the AI / ML development system 340 resides and runs on a server. In another embodiment, the AI / ML development system 340 is cloud-hosted. In further embodiments, the AI / ML development system 340 utilizes a distributed data pipeline / analysis engine.

[0070] Once the AI / ML model 332 is trained and validated in the AI / ML development system 340, it may be stored in the AI / ML repository 360 so that it can be retrieved by either the AI / ML development system 340 or one or more AI / ML production systems 330. In one embodiment, the AI / ML repository 360 resides on a dedicated server. In some embodiments, the AI / ML repository 360 is cloud-hosted. In other embodiments, the AI / ML repository 360 is a distributed database. In further embodiments, the AI / ML repository 360 resides in the AI / ML production system 330.

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

[0072] Once the necessary data has been 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, the diversity of data in the dataset, etc. In some embodiments, the results of this statistical testing may lead to employing one or more data transformations to normalize one or more values ​​in the dataset. In some embodiments, this step includes cleaning of data that is considered noisy. Noisy datasets include, but are not limited to, values ​​that do not contribute to learning, such as null values ​​and long string values. Data preparation (344) may be a manual process or an automated process using one or more elements, functions, described or depicted herein.

[0073] Data features are identified and extracted (346). In some embodiments, data features are present internally in the data prepared from step 344. In other embodiments, data features require that a portion of the data prepared from step 344 be enriched with data from another data source so that it is useful for 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 described or depicted herein. Once features are identified, the feature values ​​are collected into a dataset used to develop the AI / ML model 332.

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

[0075] Using the training dataset from step 348, the AI / ML model 332 is trained and tuned (350). In this step, the training dataset is supplied to the AI / ML algorithm and an initial set of algorithm parameters. The performance of the AI / ML model 332 is then tested within the AI / ML development system 340 using the validation dataset from step 348. These steps can be repeated, adjusting one or more algorithm parameters until the model's performance is acceptable based on various objectives and / or results.

[0076] The AI / ML model 332 is evaluated in a staging environment (not shown) similar to the final AI / ML production system 330 (352). This evaluation uses a validation dataset to confirm that the 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 previously 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 stated, in some embodiments, the model evaluation step 352 is a manual process or an automated process using one or more of the elements, functions described or depicted herein.

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

[0078] Figure 3C shows process 300C for utilizing an AI / ML model to support an AI-assisted vehicle or occupant decision point. As previously stated, the AI ​​model utilization process described herein reflects ML, a specific branch of AI, but the present invention is not limited to ML and is not limited to any AI algorithm or combination of algorithms.

[0079] Referring to Figure 3C, the AI / ML production system 330 can be used by the decision-making subsystem 316 within the vehicle node 310 to support its decision-making process. The AI / ML production system 330 provides an application programming interface (API) 334 executed by the AI / ML server process 336 through which requests can be made. In some embodiments, a request may include an identifier for the AI / ML model 332 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., 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 the occupant data subsystem. In embodiments, one or more elements or nodes 320, 330, 340, or 360 may be located in the vehicle 310.

[0080] Upon receiving an API 334 request, the AI / ML server process 336 may need to transform the data payload or a portion of the data payload, which are valid feature values, into an AI / ML model 332. Data transformation may include, but is not limited to, combining data values, normalizing data values, and enriching input data with data from other data sources. Once the necessary data transformations are performed, the AI / ML server process 336 runs 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 result in 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. Furthermore, in some embodiments, immediate performance feedback may be recorded by the AI / ML server process 336 in the model feedback log 338. In some embodiments, failure of the running model is the reason for immediate feedback.

[0081] In some embodiments, API 334 includes an interface that provides AI / ML model 332 feedback after the AI / ML model 332 execution response has been processed. This mechanism can be used to evaluate the performance of AI / ML model 332 by enabling the API caller to provide feedback on the accuracy of the model results. For example, if 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 for the initial request so that it can be used to associate the feedback with the request. Upon receiving a call to the feedback interface of API 334, the AI / ML server process 336 records the feedback in the model feedback log 338. In some embodiments, the data in this model feedback log 338 is provided to the model performance monitor (356) of the AI / ML development system 340. In one embodiment, this log data is streamed to the AI / ML development system 340. In some embodiments, the log data is provided on request.

[0082] Many steps / functions that can utilize the AI / ML processes described herein include a charging point receiving energy from a vehicle connected to the charging point and providing the vehicle with content related to the amount of energy received from the vehicle. The steps / functions also include determining the amount of time for which energy is to be received, determining the content based on the amount of time, determining the location of the charging point, providing the content to a device associated with the residence if the determined location is a residence, providing the content to one or more devices associated with one or more occupants of the vehicle if the determined location is not a residence, providing a first portion of the content in response to the charging point receiving a first portion of the amount of energy received, providing a second portion of the content in response to the charging point receiving a second portion of the amount of energy received, determining the rate of reception, providing the content at a content delivery rate commensurate with the rate of reception based on the determination, determining the location of one or more occupants in the vehicle, and directing the content to a content playback device based on the location of one or more occupants.

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

[0084] Figure 3D illustrates a process 300D for designing a new machine learning model via the system's user interface 370, according to an exemplary embodiment. As an example, the model may be output as part of an AI / ML development system 340. Referring to Figure 3D, the user can add pieces / components to the model under development within the workspace 374 of the user interface 370 using an input mechanism from menu 372 of the user interface 370.

[0085] Menu 372 contains multiple selectable graphical user interface (GUI) menu options to reveal additional components that can be added to the model design shown in workspace 374. The GUI menu includes options for adding elements to the workspace, such as functionalities that may include neural networks, machine learning models, AI models, data sources, transformation processes (vectorization, encoding, etc.), and analysis. The user can continue adding features to the model, connecting them using edges or other means, and creating a flow within workspace 374. For example, the user can add node 376 to the flow of a new model in workspace 374. For example, the user can connect node 376 to another node in the diagram via edge 378, creating a dependency within the diagram. When the user has finished working, they can save the model for subsequent training / testing.

[0086] In another example, the object's name can be identified from a webpage or user interface 370 where the object is visible within workspace 374 on the browser or user device. A popup can be overlaid in the browser or workspace 374 where the object is visible, and this popup includes the option to navigate to the identified webpage corresponding to the alternative object via a rule set.

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

[0088] Instead of dividing files into blocks stored on the disk of a file system, object storage 390 treats objects as distinct 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 a file-based approach. The metadata can be customized with additional context that can later be extracted and leveraged for other purposes, such as data analysis.

[0089] 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 a RESTful web service). API 384 is used by client applications to query the metadata of objects in order to retrieve desired objects (data) over the internet from any location on any device. API 384 can use HTTP commands such as "PUT" or "POST" for uploading objects, "GET" for retrieving objects, and "DELETE" for deleting objects.

[0090] The object storage 390 may provide a directory 398 that uses the metadata of an object to find the appropriate data file. The directory 398 may include descriptive information about each object stored in the object storage 390, such as its name, unique identifier, creation timestamp, and collection name. To query an object in the object storage 390, a client application may send a command, such as an HTTP command, which has the identifier of the object 392, a payload, and so on. The object storage 390 may store the actions and results described herein, including associating two or more lists of ranked assets with respect to each other based on variables used by two or more lists of ranked assets that have a correlation above a predetermined threshold.

[0091] Figure 4A shows Figure 400A illustrating the electrification of one or more elements. In one example, vehicle 402B can supply power stored in its battery to one or more elements, including other vehicles 408B, charging stations 406B, and an electric grid 404B. The electric grid 404B is coupled to one or more charging stations 406B and may be coupled to one or more vehicles 408B. This configuration enables the distribution of electricity / power received from vehicle 402B. Vehicle 402B can also interact with other vehicles 408B via communication such as V2V technology, cellular, or Wi-Fi®. Vehicle 402B can also interact with other vehicles 408B, charging stations 406B, and / or the power grid 404B wirelessly and / or via wired connections. In one example, vehicle 402B is routed (or routes itself) to an electric grid(s)404B, a charging station(s)406B, or another vehicle(s)408B in a safe and efficient manner. Using one or more embodiments of the solution in this field, vehicle 402B can provide energy to one or more of the elements described herein in a variety of advantageous ways as described and / or depicted herein. Furthermore, the safety and efficiency of the vehicle can be improved and have a positive impact on the environment as described and / or depicted herein.

[0092] Terms such as “energy,” “electricity,” and “power” may be used to describe any form of energy received, stored, used, shared, and / or lost by a vehicle. Energy may be referred to in relation to voltage sources and / or current supplies supplied 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 in the form of 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 levels of one or more vehicles over a given period of time.

[0093] In one embodiment, the 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 embodiment, a wireless connection is used to wirelessly instruct the amount of energy to be transferred between vehicles 408B, and both vehicles may be in motion. In one embodiment, wireless charging may be performed via fixed chargers and batteries of vehicles aligned with each other (such as a charging mat in a garage or parking space). In one example, an idle vehicle, such as vehicle 402B (which may be autonomous), is instructed to supply an amount of energy to the charging station 406B and return to its original location (e.g., the original location or a different destination). In one embodiment, a mobile energy storage unit (not shown) is used to collect surplus energy from at least one other vehicle 408B and transfer the surplus energy stored at the charging station 406B. In one embodiment, factors such as distance, time, as well as traffic conditions, road conditions, environmental / weather conditions, vehicle condition (such as weight), occupant schedules while the vehicle is in use, and occupant schedules waiting for the vehicle determine the amount of energy to be transferred to the charging station 406B. In one example, vehicle 408B, charging station 406B, and / or electric grid 404B can supply energy to vehicle 402B.

[0094] In one embodiment, a location (not shown), such as a building or residence, is communicably coupled to one or more of the following: an electric grid 404B, a vehicle 402B, and / or a charging station 406B. The rate of electricity flow to one or more of the above location, vehicle 402B, and other vehicles 408B is changed according to external conditions such as weather. For example, if the outside temperature is extremely hot or extremely cold and the likelihood of a power outage is high, the flow of electricity to the connected vehicles 402B / 408B is slowed down to help minimize the likelihood of a power outage.

[0095] In one embodiment, vehicles 402B and 408B can be used as bidirectional vehicles. A bidirectional vehicle is a vehicle that can function as a mobile microgrid, assisting in the supply of power to grid 404B and / or reducing power consumption when the grid is under stress. The bidirectional vehicle incorporates bidirectional charging, allowing for the transfer of energy from the vehicle to grid 404B in addition to charging the vehicle. In bidirectional charging, electricity flows in both directions: into and out of the vehicle. When the vehicle is charged, alternating current (AC) electricity from grid 404B is converted to direct current (DC). This is done by one or more converters in the vehicle itself or in charging station 406B. The energy stored in the vehicle's battery can be sent back to the grid in the reverse direction. The energy is typically converted from DC to AC through a converter (also known as a bidirectional charger) installed in charging station 406B. Furthermore, the in-situ solution described and depicted with respect to Figure 4B can be used in this and other networks and / or systems.

[0096] Figure 4B shows the interconnections between different elements 400B. The solution in this field can be stored and / or executed, whole or in part, on and / or by one or more computing devices 414C, 418C, 424C, 428C, 432C, 436C, 406C, 442C, and 410C related to various entities, which are communicatively connected to and communicating with the network 402C. The database 438C is communicatively connected to the network, enabling the storage and retrieval of data. In one example, the database is an immutable ledger. One or more of the various entities are a vehicle 404C, one or more service providers 416C, one or more public buildings 422C, one or more transport infrastructure 426C, one or more houses 430C, a power grid / charging station 434C, a microphone 440C, and / or another vehicle 408C. Other entities and / or devices, such as one or more individual users using smartphones 412C, laptops 420C, augmented reality (AR) devices, virtual reality (VR) devices, and / or any wearable devices, may also interact with the solution in this field. Smartphones 412C, laptops 420C, microphones 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 have access to computing devices 424C. One or more service providers 416C may include dealerships, tow truck services, crash centers, or other repair shops. One or more service providers 416C may have access to computing equipment 418C. These various computer devices may be connected to each other directly and / or communicate with each other via wired networks, wireless networks, blockchain networks, etc. The microphone 440C may, in one example, be used as a virtual assistant.For example, one or more traffic infrastructures 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. One or more traffic infrastructures 426C may utilize a computing device 428C.

[0097] In one embodiment, whenever charge is exchanged between a charging station and / or the electric grid, the entities enabling this are one or more of the vehicle, the charging station, the server, and the network which is communicatively coupled to the vehicle, the charging station, and the electric grid.

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

[0099] Figure 4C is another block diagram showing the interconnections between different elements in one embodiment 400C. A vehicle 412D is shown, including ECUs 410D, 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, the management of the vehicle's engine, brake system, gearbox system, door locks, dashboard, airbag system, infotainment system, electronic differential, and active suspension. The ECUs are connected to the vehicle's CAN (Controller Area Network) bus 416D. The ECUs can also communicate with the vehicle computer 404D via the CAN bus 416D. The vehicle's processor / sensor (such as the vehicle computer) 404D can communicate with external elements such as a server 418D via a network 402D (such as the internet). Each ECU 410D, 408D, and head unit 406D may include its own security policy. Security policies define permissible processes that can be executed within the appropriate context. For example, some or all of the security policy is provided by the vehicle computer 404D.

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

[0101] Referring to Figure 4D, the operating environment 400D of a connected vehicle is illustrated according to several embodiments. As depicted, the vehicle 410E includes a CAN bus 408E connecting the vehicle's elements 412E-426E. Other elements may be connected to the CAN bus and are not depicted herein. 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, memory 422E, a communication unit 424E, and an electronic display 426E.

[0102] The processor 420E includes an arithmetic logic unit, a microprocessor, a general-purpose controller, and / or a similar processor array to perform calculations and provide electronic display signals to the display unit 426E. The processor 420E may include various computing architectures, including a composite instruction set computer (CISC) architecture, a reduced instruction set computer (RISC) architecture, or an architecture that implements a combination of instruction sets for processing data signals. The vehicle 410E may include one or more processors 420E. Other processors, operating systems, sensors, displays, and a physical configuration (not depicted) that is communicatively coupled to one another may be used with the solution in this case.

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

[0104] The memory 422E of the vehicle 410E can store one or more types of data, including navigation route data 418E and autonomous feature data 416E. In some embodiments, the memory 422E stores data that may be necessary for the navigation application 418E to provide functionality.

[0105] The navigation system 418E can 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 the user for a navigation route including a start point and an end point. The navigation system 418E can query the real-time data server 404E (via the network 402E) for navigation route data corresponding to a navigation route including a start point and an 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.

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

[0107] 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 and long-range sensors. In some embodiments, the sensor set 412E of the vehicle 410E may include one or more of the following: a camera, a light detection and ranging (Lidar) sensor, an ultrasonic sensor, an automotive 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 automotive sensor. The navigation system 418E may store sensor data in memory 422E.

[0108] 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 communication (DSRC) transceiver, a DSRC receiver, and other hardware or software necessary to make the vehicle 410E a DSRC-equipped device.

[0109] Vehicle 410E can interact with other vehicles 406E via V2V technology. For example, V2V communication may include sensing radar information corresponding to the relative distance to an external object, receiving GPS information of the target vehicle, defining an area where the other vehicle 406E is located based on the sensed radar information, calculating the probability that the target vehicle's GPS information is located in the defined area, and identifying the vehicle and / or object corresponding to the radar information and the target vehicle's GPS information based on the calculated probability.

[0110] To properly protect 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 the vehicle's computer and computer network to facilitate secure remote communication with the vehicle.

[0111] An ECU is a node within a vehicle that controls tasks ranging from operating the windshield wipers to the anti-lock braking system. ECUs are often connected to each other through a central vehicle network called a Controller Area Network (CAN). Advanced features such as autonomous driving heavily rely on the implementation of new and complex ECUs, such as ADAS and sensors. While these new technologies help improve vehicle safety and the driving experience, they also increase the number of units communicating with the outside world within the vehicle, making it more vulnerable to attacks. The following are examples of protecting a vehicle from physical and remote intrusion.

[0112] In one embodiment, CAN includes a CAN bus with high and low terminals, and a number of 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 that do not use a host computer. The CAN bus implements a message-based protocol (such as the ISO 11898 standard) that allows ECUs to send commands to each other at the root level. ECUs, on the other hand, represent controllers for controlling electrical systems or subsystems within a vehicle. Examples of electrical systems include power steering, anti-lock brakes, air conditioning, tire pressure monitoring, cruise control, and many other functions.

[0113] 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 to the CAN bus format and data from the CAN bus to the microcontroller format. The microcontroller, on the other hand, interprets the messages and, for example, uses the ECU software installed therein to determine which messages to send.

[0114] Various security protocols can be implemented to protect CAN from cyber threats. For example, subnetworks (e.g., subnetworks A and B) can be used to divide CAN into smaller sub-CANs, limiting the ability of attackers to remotely access vehicles. In one embodiment, a firewall (or gateway, etc.) may be added to block messages traversing the CAN bus across subnetworks. Even if an attacker gains access to one subnetwork, they cannot access the entire network. To further enhance the security of subnetworks, for example, the most critical ECUs should not be placed on the same subnetwork.

[0115] In addition to protecting the vehicle's internal network, the vehicle can also be protected when communicating with external networks such as the internet. One advantage of connecting a vehicle to data sources such as the internet is that information from the vehicle can be transmitted remotely via the network for analysis. Examples of vehicle information include GPS, on-board diagnostics, and tire pressure. Such communication systems are often called telematics because they involve a combination of telecommunications and information technology. Furthermore, the solutions described and depicted here can be used in this network and / or other networks and / or systems, including those described and depicted herein.

[0116] Figure 4E shows Example 400E of vehicles 402I and 408I performing secure V2V communication using security certificates, according to an exemplary embodiment. Referring to Figure 4E, vehicles 402I and 408I can communicate via V2V communication over a short-range network, a cellular network, etc. Before sending a message, vehicles 402I and 408I may sign the message using their respective public key certificates. For example, vehicle 402I may sign a V2V message using public key certificate 404I. Similarly, vehicle 408I signs a V2V message using public key certificate 410I. Public key certificates 404I and 410I are associated with vehicles 402I and 408I, respectively, as an example.

[0117] Upon receiving communication from each other, the vehicles may verify the signature with a certification authority 406I or the like. For example, vehicle 408I may verify with certification authority 406I that the public key certificate 404I used by vehicle 402I to sign the V2V communication is authentic. If vehicle 408I successfully verifies the public key certificate 404I, the vehicle knows that the data is from a legitimate source. Similarly, vehicle 402I can verify with certification authority 406I that the public key certificate 410I used by vehicle 408I to sign the V2V communication is authentic. Furthermore, the solutions described and depicted with respect to Figure 4E may be used in this network and / or other networks and / or systems, including those described and depicted herein.

[0118] 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 between ECUs and other devices on the vehicle's CAN bus, as well as on data messages transmitted between different vehicles. The security processor may include authentication modules and cryptographic modules. The security processor may be implemented within the vehicle's computer and may communicate with other vehicle elements, such as wired and wireless devices like ECU / CAN networks and wireless network interfaces, and input ports. The security processor can ensure that data frames (e.g., CAN frames) transmitted within the vehicle (e.g., via ECUs / CAN networks) are secure. Similarly, the security processor can ensure that messages transmitted between different vehicles and devices connected to or attached to the vehicle's computer via wires are also secure.

[0119] For example, the authorization module may store passwords, usernames, PIN codes, biometric scans, etc., for different vehicle users. The authorization module may also determine whether the 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. If a user wishes to change vehicle settings or vehicle technical details via the in-vehicle console or GUI, or via an attached / connected device, the authorization module may require the user to verify themselves in some way before such settings are changed. For example, the authentication module may request a username, password, PIN code, biometric scan, a predefined drawing or gesture, etc. In response, the authentication module may determine whether the user has the necessary permissions (such as access) being requested.

[0120] Authentication modules may be used to authenticate internal communication between ECUs on a vehicle's CAN network. For example, an authentication module may provide information for authenticating communication between ECUs. For instance, the authentication module sends 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 fields 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 also provide a list of ECUs that do not need to use authentication bits (a safe list). The authentication module may communicate with a remote server to obtain updates, such as the bit signature algorithm.

[0121] The encryption module can store asymmetric key pairs that a vehicle uses to communicate with other external user devices or vehicles. For example, the encryption module provides a private key used by the vehicle to encrypt / decrypt communications, and the corresponding public key is provided to other user devices and vehicles, enabling them to decrypt / encrypt communications. The encryption module may communicate with a remote server to receive new keys, key updates, keys for new vehicles or users, etc. The encryption module may also send updates to the local private / public key pair to the remote server.

[0122] Figure 5A shows an exemplary vehicle configuration 500A for managing database transactions related to a vehicle, according to an exemplary embodiment. Referring to Figure 5A, when a particular vehicle 525 is engaged in a transaction (e.g., vehicle service, dealer transaction, delivery / pickup, transport service, etc.), the vehicle may receive assets 510 and / or discharge / transfer assets 512 according to the transaction(s). A vehicle processor 526 resides in the vehicle 525, and communication exists between the vehicle processor 526, the database 530, and the transaction module 520. The transaction module 520 can record information such as assets, parties, credits, service details, date and time, location, results, notifications, and unexpected events. These transactions within the transaction module 520 may be replicated to the database 530. The database 530 can be one of the following: an SQL database, a relational database management system (RDBMS), a relational database, a non-relational database, a blockchain, or a distributed ledger, and may be mounted on the vehicle, detached from the vehicle, accessed directly and / or via a network, or accessible from the vehicle.

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

[0124] Figure 5B shows a blockchain architecture configuration 500B according to an exemplary embodiment. Referring to Figure 5B, the blockchain architecture 500B may include a group of blockchain member nodes 502-505 as part of a specific blockchain element, for example, a blockchain group 510. In one exemplary embodiment, the authorized blockchain is not accessible to all parties, but only to members who are authorized to access the blockchain data. Blockchain nodes participate in many activities, such as adding blockchain entries and verification processes (consensus). One or more blockchain nodes may endorse entries based on an endorsement policy and may provide ordering services to all blockchain nodes. Blockchain nodes may initiate blockchain actions (such as authentication) and request to write to the blockchain immutable ledger stored on the blockchain, a copy of which may also be stored in the underlying physical computer infrastructure.

[0125] A blockchain transaction 520 is stored in the computer's memory once the transaction is received and approved by a consensus model directed by member nodes. The approved transaction 526 is stored in the current block of the blockchain and committed to the blockchain via a commit procedure that involves hashing the data contents of the transaction in the current block and referencing the previous hash of the previous block. Within the blockchain, there may be one or more smart contracts 530 that define the conditions and actions of the transaction agreement contained in the smart contract executable application code 532, such as registered recipients, vehicle functions, requirements, permissions, sensor thresholds, etc. The code may be configured to identify whether a requesting entity is registered to receive vehicle services, what service functions it is entitled to / requesting given a profile status, and whether to monitor its actions in subsequent events. For example, when a service event occurs and a user is in the vehicle, sensor data monitoring is triggered, and if it is determined that certain parameters, such as the vehicle charge level, have exceeded / fallen a specific threshold for a specific period, the current status may need to be changed as a result, and an alert may need to be sent to the managing party (i.e., vehicle owner, vehicle operator, server, etc.) so that the service can be identified and saved for reference. The vehicle sensor data collected may be based on the type of sensor data used to collect information about the vehicle's condition. Sensor data may also form the basis for vehicle event data 534, such as where the vehicle should be driven, average speed, maximum speed, acceleration, whether there was a collision, whether the route was as expected, where the next destination is, whether safety measures are in place, and whether the vehicle has sufficient charge / fuel. All such information forms the basis for the conditions 530 of the smart contract and is stored on the blockchain. For example, sensor thresholds stored in the smart contract can be used as a basis for determining whether a detected service is needed, and when and where the service should be performed.

[0126] In one embodiment, the blockchain logic example includes a blockchain application interface as an API or plug-in application that links to computing devices and execution platforms for specific transactions. The blockchain configuration may include one or more applications that are linked to the application programming interface (API) and access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.), and can be created according to a customized configuration requested by the participant, maintaining its own state, controlling its own assets, and receiving external information. This may be deployed as an entry and installed on all blockchain nodes via appending to the distributed ledger.

[0127] The application code of a smart contract provides the foundation for blockchain transactions by establishing the application code, and when this is executed, the transaction conditions become active. When a smart contract is executed, a specific approved transaction is generated and transferred to the blockchain platform. The platform includes computing devices that perform security / approval and transaction management, and a storage portion as memory to store transactions and smart contracts within the blockchain.

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

[0129] The blockchain architecture configurations in Figures 5A and 5B can 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 perform reminders, updates, and / or other notifications concerning changes, updates, etc. Smart contracts can themselves be used to specify authentication and access requirements as well as rules related to the use of the ledger. For example, information may be processed by one or more processing entities (e.g., processors, virtual machines, etc.) included in the blockchain layer and may include new entries. The 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 used to obtain any of the data or information described herein.

[0130] Within smart contract executable code, smart contracts may be created via high-level applications and programming languages ​​and then written to blocks in the blockchain. Smart contracts may contain executable code that is registered, stored, and / or replicated on the blockchain (e.g., a decentralized network of blockchain peers). An entry is the execution of smart contract code, which may be executed in response to the fulfillment of conditions related to the smart contract. The execution of a smart contract may trigger a trusted modification to the state of the digital blockchain ledger. Modifications to the blockchain ledger caused by the execution of a smart contract may be automatically replicated across the decentralized network of blockchain peers through one or more consensus protocols.

[0131] Smart contracts can write data to the blockchain in the format of key-value pairs. Furthermore, smart contract code can read values ​​stored on the blockchain and use them in application operations. Smart contract code can write the 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 made public and / or kept private by encryption. Temporary data used / generated by smart contracts is held in memory by the supplied execution environment and deleted when the data required for the blockchain is identified.

[0132] Smart contract executable code includes the interpretation of smart contract code and may include additional functionality. As described herein, smart contract executable code may also be program code deployed on a computing network, where it is executed and validated together by chain validators during the consensus process. Smart contract executable code receives a hash and searches the blockchain for 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, smart contract executable code sends an authorization key to the requested service. Smart contract executable code may write to blockchain data associated with cryptographic details.

[0133] Figure 5C shows a blockchain configuration for storing blockchain transaction data according to an exemplary embodiment. Referring to Figure 5C, the exemplary configuration 500C provides a vehicle 562, user equipment 564, and a server 566 sharing information with a distributed ledger (i.e., blockchain) 568. 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 is seeking to rent a vehicle with an established rating profile. The server 566 may receive and process data related to the vehicle's service requirements. When service events occur, such as vehicle sensor data indicating the need for fuel / charging, maintenance services, etc., smart contracts may be used to invoke rules, thresholds, sensor information collection, etc. Blockchain transaction data 570 is stored for each transaction, such as access events, subsequent updates to the vehicle's service status, and event updates. A transaction may include the parties, requirements (e.g., age 18, eligible service candidate, valid driver's license, etc.), compensation level, distance traveled during the event, registered recipients authorized to access the event and host vehicle services, rights / permissions, sensor data taken during the vehicle event operation to record details of the next service event and identify the vehicle's state status, and thresholds used to determine whether the service event is complete and whether the vehicle's state status has changed.

[0134] Figure 5D shows, according to an exemplary embodiment, the contents of blockchain blocks that can be added to the distributed ledger, and block structures 582A to 582n. Referring to Figure 5D, a client (not shown) can 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) can maintain the state of the blockchain network and copies of the distributed ledger. Different types of blockchain nodes / peers may exist in a blockchain network, including supporting peers that simulate and endorse entries proposed by clients, and committing peers that verify endorsements, validate entries, and commit entries to the distributed ledger. In this example, a blockchain node can play the role of an endorser node, a committer node, or both.

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

[0136] The current state of a blockchain and distributed ledger may be stored in a state database. Here, the current state data represents the most recent values ​​of all keys contained in the blockchain's chain entry log. A smart contract executable code call executes an entry against the current state of the state database. To make such smart contract executable code interactions highly efficient, the most recent values ​​of all keys are stored in the state database. The state database can contain an indexed view of the blockchain's entry log and can therefore be regenerated from the chain at any time. The state database may be automatically restored (or generated as needed) upon peer invocation before entries are accepted.

[0137] Supporting nodes receive entries from clients and endorse them based on simulation results. Endosing nodes hold smart contracts that simulate the proposed entries. When an endosing node approves an entry, it creates an endorsement for the entry. This is a signed response from the endosing node to the client application indicating approval of the simulated entry. How 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. Endorsed entries are forwarded by the client application to the ordering service.

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

[0139] 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 done by solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger can choose the ordering mechanism that best suits their network.

[0140] Referring to Figure 5D, a block 582A (also called a data block) stored in a blockchain and / or distributed ledger may contain multiple data segments, such as block headers 584A-584n, transaction-specific data 586A-586n, and block metadata 588A-588n. It should be understood that 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 the block header 584A and block metadata 588A may be smaller than the transaction-specific data 586A that stores the entry data, but this is not a requirement. Block 582A may store transaction information for N entries (e.g., 100, 500, 1000, 2000, 3000, etc.) within block data 590A-590n. Block 582A may also include a link to the previous block (e.g., on the blockchain) within the block header 584A. In particular, the block header 584A may include a hash of the header of the previous block. The block header 584A may also include a unique block number, a hash of the block data 590A of the current block 582A, and so on. The block number of block 582A may be unique and may be assigned in an incremental / sequential order starting from zero. The first block of the blockchain may be called the founding block, containing information about the blockchain, its members, the data stored therein, etc.

[0141] Block data 590A can store entry information for each entry recorded within the block. For example, entry data may include one or more of the following: entry type, version, timestamp, distributed ledger channel ID, entry ID, epoch, payload visibility, smart contract 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 public key and certificate, client signature, endorser identification, endorser signature, proposal hash, smart contract executable code event, response status, namespace, read set (such as a list of keys and versions read by the entry), write set (such as a list of keys and versions read by the entry), write set (such as a list of keys and values), start key, end key, list of keys, Merkel tree query summary, etc. Entry data may be stored for each of N entries.

[0142] In some embodiments, the block data 590A may also store transaction-specific data 586A that adds additional information to the hash link chain of the block in the blockchain. Thus, the data 586A can be stored in the 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 depicted herein. The block metadata 588A may store multiple fields of metadata (e.g., a byte array). The metadata fields may include the signature at the time of block creation, a reference to the last constituent block, an entry filter that identifies valid and invalid entries in the block, and the last persisted offset of the ordering service that ordered the block. The signature, last constituent block, and ordering service metadata may be added by the ordering service. Meanwhile, the block committer (e.g., a blockchain node) may add valid / invalid information based on endorsement policies, read / write set verification, etc. The entry filter may include a byte array of a size equal to the number of entries in the block data and a verification code that identifies whether the entry was valid or invalid.

[0143] Other blocks in the blockchain, 582B through 582n, also have headers, files, and values. However, unlike the first block 582A, each of the headers 584A through 584n of the other blocks contains the hash value of the preceding block. The hash value of the preceding block may be just the hash value of the header of the preceding block, or it may be the hash value of the entire preceding block. By including the hash value of the preceding block in each of the remaining blocks, it is possible to trace back from the Nth block, block by block, to the generated block (and associated original file), as shown by arrow 592, and establish an auditable and immutable Chain-of-Custody.

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

[0145] The distributed ledger 520E includes a blockchain that stores immutable and ordered records within blocks, and a state database 524E (current world state) that maintains the current state of blockchain 522E. There may be one distributed ledger 520E per channel, and each peer maintains a copy of the distributed ledger 520E for each channel it is a member of. Blockchain 522E is a transaction log structured as hash-linked blocks, each block containing the following N transaction sequences: The block links (indicated 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 blockchain 522E are sequenced and cryptographically linked to prevent tampering with blockchain data without breaking the hash links. Furthermore, because of the links, the most recent block on blockchain 522E represents all previous transactions. Blockchain 522E may be stored in a peer file system (local storage or attached storage), which supports append-only blockchain workloads.

[0146] The current state of blockchain 522E and distributed ledger 520E may be stored in state database 524E, where the current state data represents the most recent values ​​of all keys contained in the chain transaction log of blockchain 522E. Chaincode calls execute transactions against the current state of state database 524E. To make these chaincode interactions highly efficient, the most recent values ​​of all keys are stored in state database 524E. State database 524E may contain an indexed view of the transaction log of blockchain 522E and can therefore be regenerated from the chain at any time. State database 524E may be automatically recovered (or generated as needed) upon peer invocation before a transaction is accepted.

[0147] The endorser node receives transactions from clients and endorses them based on the simulation results. The endorser node holds a smart contract that simulates the 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 the endorsement of the simulated transaction. How a transaction is endorsed depends on the endorsement policy that may be specified within the chaincode. An example of an endorsement policy is "a majority of the endorsing peers must endorse the transaction." Different channels may have different endorsement policies. Endorsed transactions are forwarded by the client application to the ordering service 510E.

[0148] The ordering service 510E accepts endorsed transactions, orders them into blocks, and delivers the blocks to committing peers. For example, the ordering service 510E can start a new block when a transaction threshold is reached, when a timer times out, or under other conditions. In the example in Figure 5E, blockchain node 512E is a committing peer that has received a new data block 530E to be stored in blockchain 522E. The first block of a blockchain is sometimes called the inventive block, which contains information about the blockchain, its members, the data stored therein, and so on.

[0149] The order service 510E may consist of a cluster of orderers. The order service 510E does not process transactions, smart contracts, or maintain a shared ledger. Rather, the order service 510E can accept approved transactions and specify the order in which those transactions are committed to the distributed ledger. The architecture of the blockchain network may be designed so that a particular implementation of “orders” is a pluggable component.

[0150] 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 performed by solving a cryptographic puzzle or by mining, in this example, the parties to the distributed ledger 520E can choose the ordering mechanism that best suits the network.

[0151] When the ordering service 510E initializes a new data block 530E, the new data block 530E may be broadcast to committing peers (e.g., blockchain nodes 51IE, 512E, and 513E). In response, each committing peer verifies the transactions in the new data block 530E by ensuring that the read and write sets still match the current world state in the state database 524E. Specifically, a committing peer can 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. Once a committing peer verifies a transaction, it is written to blockchain 522E on the distributed ledger 520E, and the state database 524E is updated with the write data from the read and write sets. If a transaction fails, i.e., if a committing peer finds that the read and write sets do not match the current world state in the state database 524E, the transaction ordered to the block is still included in that block but is marked as invalid, and the state database 524E is not updated.

[0152] Referring to Figure 5F 500F, a new data block 530 (also called a data block) stored in blockchain 522E of the distributed ledger 520E shown in Figure 5E may contain multiple data segments, such as a block header 540, block data 550, and block metadata 560. It should be understood that various depicted blocks and their contents, such as the new data block 530 and its contents shown in Figure 5F, are merely illustrative and are not intended to limit the scope of the exemplary embodiments. The new data block 530 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 550. The new data block 530 may also include a link to a previous block (e.g., on blockchain 522E in Figure 5E) within the block header 540. In particular, the block header 540 may include a hash of the header of the previous block. The block header 540 may also include a unique block number, a hash of the block data 550 of the new data block 530, and so on. The block number of the new data block 530 may be unique and may be assigned in various orders, such as zero-based incremental / sequential order.

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

[0154] In one embodiment of the solution in this field, the block data 550 may include data relating to the charging point receiving energy from a vehicle connected to the charging point, and data relating to providing the vehicle with content relating to the amount of energy received from the vehicle.

[0155] In Figure 5F, blockchain data 563 is depicted in block data 550, but blockchain data 563 may also be placed in block header 540 or block metadata 560. In some examples, blockchain data 563 includes data relating to the charging point receiving energy from a vehicle connected to the charging point, and data relating to providing the vehicle with content relating to the amount of energy received from the vehicle.

[0156] Block metadata 560 (Figure 5F) can store multiple fields of metadata (such as a byte array). Metadata fields may include the signature at the time of block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions within the block, and the last persisted offset of the ordering service that ordered the block. The signature, last constituent block, and ordering service metadata may be added by the ordering service 510E in Figure 5E. Meanwhile, the block committer (such as the blockchain node 512E in Figure 5E) may add valid / invalid information based on endorsement policies, read / write set verification, etc. The transaction filter may include a byte array equal in size to the number of transactions in the block data and a verification code that identifies whether a transaction was valid or invalid.

[0157] The embodiments described above can 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, hard disks, removable disks, compact disk read-only memory ("CD-ROM"), or other forms of storage medium known in the art.

[0158] An exemplary storage medium can be coupled to a processor so that the processor can read information from and write information to the storage medium. Alternatively, the storage medium may be integrated with the processor. The processor and storage medium may reside within an application-specific integrated circuit ("ASIC"). Alternatively, the processor and storage medium may exist as separate components. For example, Figure 6 shows an exemplary computer system architecture 600, which may represent or integrate any of the above-described components.

[0159] Figure 6 shows a computing environment according to an exemplary embodiment. Figure 6 is not intended to imply any limitation on the scope or functionality of the application embodiments described herein. Nevertheless, the computing environment 600 may be implemented to perform any of the functionalities described herein. In the computing environment 600, the computer system 601 can operate within a number of other general-purpose or special-purpose computing system environments or configurations.

[0160] Computer system 601 can take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, server computer system, thin client, thick client, network PC, minicomputer system, mainframe computer, quantum computer, or any other form of computer or mobile device currently known or to be developed in the future that is capable of running programs, accessing network 650, or querying databases. Depending on the technology, the execution of the methods performed by the computer may be distributed across multiple computers and multiple locations. However, in this presentation of computing environment 600, in order to keep the presentation as simple as possible, the detailed discussion will focus on a single computer, specifically computer system 601.

[0161] Computer system 601, although not shown in the cloud in Figure 6, may be located in the cloud. On the other hand, computer system 601 does not need to be in the cloud, except to the extent that it may be shown positively. Computer system 601 may be described in the general context of computer system executable instructions, such as program modules, that are executed by computer system 601. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform tasks or implement specific abstract data types. As shown in Figure 6, computer system 601 of computing environment 600 is shown in the form of a general-purpose computing device. The components of computer system 601 may include, but are not limited to, one or more processors or processing units 602, system memory 630, and buses 620 that connect various system components, including system memory 630, to the processor 602.

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

[0163] The network adapter 603 enables the computer 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 (such as the Internet). It bridges the computer's internal bus 620 with the external network, facilitating efficient and reliable data exchange. The network adapter 603 may include hardware such as a modem or Wi-Fi signal transceiver, and software that packets and / or depackets data for communication network transmission. To ensure compatibility with network standards, the network adapter 603 supports various communication protocols. For Ethernet connections, it may comply with protocols such as IEEE 802.3, and for wireless communication, it may support IEEE 802.11, Bluetooth®, Near Field Communication (NFC), or other network wireless standards.

[0164] The computer system 601 may include removable / non-removable, volatile / non-volatile computer storage devices 610. For example, the storage device 610 may be a non-removable, non-volatile magnetic medium (not shown, typically called a “hard drive”). One or more data interfaces may connect it to the bus 620. In embodiments where the computer system 601 is required to have large-capacity storage (for example, if the computer system 601 locally stores and manages a large database), this storage may be provided by peripheral storage devices 610 designed to store 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 a computer system 601 and provides common services to computer programs. Operating System 611 can 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 memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses using various bus architectures. Examples, but not limited to, such architectures include the Industry Standard Architecture (ISA) bus, Microchannel Architecture (MCA) bus, Extended ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and PCI (Peripheral Component Interconnects) bus. Bus 620 is a signaling path that allows various components of a computer system 601 to communicate with one another.

[0167] Memory 630 is any volatile memory currently known or to be developed in the future. Examples include dynamic random access memory (RAM 631) or static type RAM 631. Typically, volatile memory is characterized by random access, but this is not mandatory unless positively indicated. In computer system 601, memory 630 is in a single package and is internal to computer system 601, but alternatively or additionally, volatile memory may be distributed in multiple packages and / or located externally with respect to computer system 601. For example only, memory 630 may be provided for reading from and writing to an immovable non-volatile magnetic medium (indicated as storage device 610, typically called a “hard drive”). Memory 630 may include at least one program product having a set of program modules (e.g., at least one) configured to perform various functions. A typical computer system 601 may include a cache 632, a special volatile memory that is generally faster than RAM 631 and is 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. The computer 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 necessary to start the BIOS and operating system 611.

[0168] Computer system 601 can also communicate with one or more peripheral devices 641 via I / O interface 640. Such devices may include one or more devices that enable a user to interact with computer system 601, such as a keyboard, pointing device, or display, and / or any devices that enable computer system 601 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may occur via input / output (I / O) interface 640. As depicted, I / O interface 640 communicates with other components of computer 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, LAN, private cloud, or public internet, and may communicate computer data over non-local distances by any technology currently known or to be developed in the future. Any connection depicted may be wired and / or wireless and may traverse other components not shown. In some embodiments, Network 650 may be replaced and / or complemented 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 transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers. Computer system 601 connects to Network 650 via network adapter 603 and bus 620.

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

[0171] A remote server 660 is any computer that provides at least some data and / or functionality to a computer system 601 via a network 650, such as a WAN, virtual private network (VPN), or private cloud, or via the internet. These networks 650 may communicate with a LAN to reach the user. 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 desktop sessions, such as Microsoft RDP (Remote Desktop Protocol) or Citrix ICA (Independent Computing Architecture). Mobile applications can also be used. A remote server 660 may also host a remote database 661, which may reside on a single remote server 660 or be distributed across multiple remote servers 660. The remote database 661 is accessible from a database client application locally installed on the remote server 660, other remote servers 660, user devices 651, or computer system 601 via the network 650.

[0172] Public Cloud 670 is the on-demand availability of computer system resources, including data storage and computing power, without direct, active management by the user. Public Cloud 670 is often distributed, with data centers located in multiple locations for availability and performance. Computing resources on Public Cloud 670 are shared among multiple tenants through a virtual computing environment 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 some lightweight operating system APIs and services. In contrast, virtual machines 671 are a software layer that includes the complete operating system 611 and kernel. Virtual machines 671 are built on top of a hypervisor emulation layer designed to abstract the host computer hardware from the operating software environment. Public Cloud 670 generally provides a hosted database 672 that abstracts high-level database management activities. It should be further understood that one or more of the elements described or depicted in Figure 6 can perform one or more of the actions, functions, or features described or depicted herein.

[0173] At least one exemplary embodiment of a system, method, and non-transient computer-readable medium is illustrated in the accompanying drawings and described in the preceding detailed description. However, it will be understood that this application is not limited to the disclosed embodiments and that numerous rearrangements, modifications, and substitutions are possible, as defined and defined by the following claims. For example, the functions 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 transmitters, receivers, or combinations thereof. For example, all or part of the functions performed by individual modules may be performed by one or more of these modules. Furthermore, the functions described herein may be performed at various timings inside or outside the modules or components, in relation to various events. Also, information transmitted between various modules may be transmitted between modules via at least one of data networks, the internet, voice networks, Internet Protocol networks, wireless devices, and wired devices, and / or via multiple protocols. Also, messages transmitted 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 understand that “System” can be embodied as a personal computer, server, console, personal digital assistant (PDA), mobile phone, tablet computing device, smartphone, or any other suitable computing device, or combination of devices. Presenting the functions described above as being performed by “System” is not intended to limit the scope of this application in any way, but rather to provide examples of many embodiments. Indeed, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technology.

[0175] It should be noted that some of the system features described herein are presented as modules to particularly emphasize the independence of their implementation. For example, modules may be implemented as hardware circuits consisting of custom very large-scale integrated circuits (VLSI) or commercially available semiconductors such as gate arrays, logic chips, transistors, or other discrete components. Modules may also be implemented as programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, and graphics processing units.

[0176] Modules may also be implemented in software, at least partially, for execution by various types of processors. A specified unit of executable code may consist of one or more physical or logical blocks of computer instructions, which can be organized, for example, as objects, procedures, or functions. However, the executable code of a specified module does not need to be physically located together, and may consist of heterogeneous instructions stored in different locations that, when logically combined, constitute a module and achieve the module's purpose. Furthermore, modules may be stored in computer-readable media, which may, for example, be hard disk drives, flash devices, RAM, tape, or any other such medium used to store data.

[0177] In fact, a module of executable code may be a single instruction or a number of instructions, and may be distributed across multiple different code segments, different programs, and multiple memory devices. Similarly, operational data may be identified within a module, exemplified herein, embodied in any suitable form, and organized within any suitable type of data structure. Operational data may be collected as a single dataset, distributed across different locations including on different storage devices, or at least partially exist simply as electronic signals on a system or network.

[0178] It will be readily apparent that the components of this application, as generally described and illustrated in the figures of this specification, may be arranged and designed in a wide variety of different configurations. Therefore, the detailed description of embodiments is not intended to limit the scope of this application as claimed, but merely represents selected embodiments of this application.

[0179] Those skilled in the art will readily understand that the above can be carried out using steps in a different order and / or hardware elements with configurations different from those disclosed. Therefore, although this application is described based on these preferred embodiments, specific modifications, variations, and alternative structures 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 illustrative only, and the scope of the present application, when considered to include the full range of equivalents and modifications thereto (e.g., protocols, hardware devices, software platforms, etc.), is defined solely by the appended claims.

Claims

1. The charging point receives energy from the vehicle connected to the charging point, To provide the vehicle with content relating to the amount of energy received from the vehicle, A method that includes this.

2. Determining the amount of time the aforementioned energy is received, Determining the content based on the aforementioned time amount, The method according to claim 1, including the method described in claim 1.

3. Determining the location of the aforementioned charging point, If the determined location is a residence, the content is provided to a device associated with the residence. If the determined location is not a residence, the content is provided to one or more devices associated with one or more occupants of the vehicle. The method according to claim 1, including the method described in claim 1.

4. In response to a first portion of the amount of energy received being received by the charging point, the first portion of the content is provided. In response to the second portion of the amount of energy received being received by the charging point, the second portion of the content is provided. The method according to claim 1, including the method described in claim 1.

5. Determining the reception rate, Based on the decision, the content will be provided at a content distribution rate that matches the reception rate, The method according to claim 1, including the method described in claim 1.

6. To determine the position of one or more occupants inside the vehicle. The method according to claim 1, including the method described in claim 1.

7. Based on the position of the one or more occupants, direct the content towards the content playback device. The method according to claim 6, including the method described in claim 6.

8. Processor and Memory and Equipped with, The processor and the memory are connected in a communication manner. The aforementioned processor, The charging point receives energy from the vehicle connected to the charging point. Provide the vehicle with content relating to the amount of energy received from the vehicle. system.

9. The aforementioned processor, The amount of time to receive the aforementioned energy is determined, The content is determined based on the aforementioned time amount. The system according to claim 8.

10. The aforementioned processor, Determine the location of the aforementioned charging point, If the determined location is a residence, the content is provided to a device associated with the residence. If the determined location is not a residence, the content will be provided to one or more devices associated with one or more occupants of the vehicle. The system according to claim 8.

11. The aforementioned processor, In response to a first portion of the amount of energy received being received by the charging point, the first portion of the content is provided. In response to the second portion of the amount of energy received being received by the charging point, the second portion of the content is provided. The system according to claim 8.

12. The aforementioned processor, Determine the reception rate, Based on the decision, the content will be provided at a content distribution rate that matches the reception rate. The system according to claim 8.

13. The aforementioned processor, Determining the position of one or more occupants inside the vehicle. The system according to claim 8.

14. The aforementioned processor, Based on the position of the one or more occupants, the content is directed towards the content playback device. The system according to claim 13.

15. When read by the processor, the processor: The charging point receives energy from the vehicle connected to the charging point, To provide the vehicle with content relating to the amount of energy received from the vehicle, A computer-readable recording medium containing instructions to execute a command.

16. The amount of time to receive the aforementioned energy is determined, The content is determined based on the aforementioned time amount. The computer-readable recording medium according to claim 15, further comprising instructions for the purpose of recording.

17. Determine the location of the aforementioned charging point, If the determined location is a residence, the content is provided to a device associated with the residence. If the determined location is not a residence, the content will be provided to one or more devices associated with one or more occupants of the vehicle. The computer-readable recording medium according to claim 15, further comprising instructions for the purpose of recording.

18. In response to a first portion of the amount of energy received being received by the charging point, the first portion of the content is provided. In response to the second portion of the amount of energy received being received by the charging point, the second portion of the content is provided. The computer-readable recording medium according to claim 15, further comprising instructions for the purpose of recording.

19. Determine the reception rate, Based on the decision, the content will be provided at a content distribution rate that matches the reception rate. The computer-readable recording medium according to claim 15, further comprising instructions for the purpose of recording.

20. Based on the position of one or more occupants, the content is directed towards the content playback device. The computer-readable recording medium according to claim 19, further comprising instructions for the purpose of recording.

Images