Data security through temporary value translation

Abstract

To provide a secure software process.SOLUTION: An example operation includes one or more of: receiving a request to compile a software application; identifying one or more dummy values which were previously stored in source code of the software application; translating the one or more dummy values into source code using one or more secret values stored in a data store; and compiling, via a device, the source code of the software application into binary code using the secret values.SELECTED DRAWING: Figure 1A

Description

[Background technology]

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

[0002] One exemplary embodiment provides a method that includes receiving a request to compile a software application; identifying one or more dummy values ​​previously stored in source code of the software application; converting the one or more dummy values ​​into source code using one or more secret values ​​stored in a data store; and compiling, via a device, the source code of the software application into binary code using the secret values.

[0003] Another example embodiment may include a system including one or more processors configured to receive a request to compile a software application, identify one or more dummy values ​​previously stored in source code of the software application, convert the one or more dummy values ​​into source code using one or more secret values ​​stored in a data store, and compile the source code of the software application into binary code using the secret values.

[0004] Another example embodiment may include a non-transitory computer-readable storage medium configured to store instructions that, when executed, cause a processor to receive a request to compile a software application; identify one or more dummy values ​​previously stored in source code of the software application; translate the one or more dummy values ​​into source code using one or more secret values ​​stored in a data store; and compile, via a device, the source code of the software application into binary code using the secret values. [Brief explanation of the drawings]

[0005] [Figure 1A] FIG. 1 illustrates an exemplary system diagram in which a secure software process occurs, according to an exemplary embodiment. [Figure 1B] FIG. 1 illustrates a network diagram in which a secure software process occurs, according to an exemplary embodiment. [Figure 2A] FIG. 1 illustrates a vehicle network diagram according to an exemplary embodiment. [Figure 2B] FIG. 1 illustrates another vehicle network diagram according to an exemplary embodiment. [Figure 2C] FIG. 10 illustrates yet another vehicle network diagram in accordance with an illustrative embodiment. [Figure 2D] FIG. 10 illustrates a further vehicle network diagram according to an exemplary embodiment. [Figure 2E] FIG. 1 illustrates a flow diagram according to an exemplary embodiment. [Figure 2F] FIG. 10 illustrates another flow diagram according to an exemplary embodiment. [Figure 3A] FIG. 1 illustrates an artificial intelligence (AI) / machine learning (ML) network diagram incorporating artificial intelligence (AI) models into any decision point in an exemplary embodiment. [Figure 3B]FIG. 1 illustrates a process for developing artificial intelligence (AI) / machine learning (ML) models to support AI-assisted vehicle or occupant decision points. [Figure 3C] FIG. 1 illustrates a process for utilizing artificial intelligence (AI) / machine learning (ML) models to support AI-assisted vehicle or occupant decision points. [Figure 3D] FIG. 1 illustrates a machine learning network diagram according to an exemplary embodiment. [Figure 3E] FIG. 1 illustrates a machine learning network diagram according to an exemplary embodiment. [Figure 4A] FIG. 1 illustrates a diagram depicting powering of one or more elements according to an exemplary embodiment. [Figure 4B] FIG. 1 illustrates a diagram depicting interconnections between different elements according to an exemplary embodiment. [Figure 4C] FIG. 10 illustrates a further diagram depicting interconnections between different elements according to an exemplary embodiment. [Figure 4D] FIG. 10 illustrates yet another diagram depicting interconnections between elements according to an exemplary embodiment. [Figure 4E] FIG. 10 illustrates yet an additional diagram depicting an example of vehicles using security certificates for secure vehicle-to-vehicle (V2V) communication, according to an exemplary embodiment. [Figure 5A] FIG. 1 illustrates an exemplary vehicle configuration for managing database transactions associated with a vehicle, according to an exemplary embodiment. [Figure 5B] FIG. 1 illustrates an exemplary blockchain group, according to an exemplary embodiment. [Figure 5C] FIG. 1 illustrates an exemplary interaction between an element and a blockchain, according to an exemplary embodiment. [Figure 5D] FIG. 1 illustrates exemplary data block interactions according to an exemplary embodiment. [Figure 5E] FIG. 1 illustrates a blockchain network diagram, according to an exemplary embodiment. [Figure 5F]FIG. 10 illustrates an exemplary new data block according to an exemplary embodiment. [Figure 6] FIG. 1 illustrates an exemplary system that supports one or more of the exemplary embodiments. DETAILED DESCRIPTION OF THE INVENTION

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

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

[0008] The features, structures, or characteristics described herein may be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrases “exemplary embodiment,” “some embodiments,” “first embodiment,” or other similar terms indicates that a particular feature, structure, or characteristic described in connection with one or more embodiments may also be included in one or more other embodiments described or depicted herein. Thus, one or more embodiments described or depicted throughout this specification may all refer to the same embodiment. Thus, an embodiment may function together with any of the other embodiments and may not be functionally separate; in one or more embodiments, the described features, structures, or characteristics may be combined in any suitable manner. Although described in a particular manner, by way of example, only or more of the features, elements, and steps described herein may be utilized together in various combinations, not exclusively, unless otherwise expressly indicated herein. In the figures, any connections between elements may enable one-way and / or two-way communication, even if the depicted connection is a one-way or two-way connection, e.g., an arrow.

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

[0010] Additionally, although the term "message" may be used in describing the embodiments, other types of network data may be used, such as packets, frames, datagrams, etc. Furthermore, although particular types of messages and signaling may be depicted in preferred embodiments, they are not limited to particular 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 a transportation means (also referred to herein as a vehicle or passenger vehicle), a data collection system, a data monitoring system, a verification system, an authorization system, and a vehicle data distribution system. Vehicle status status data received in the form of communication messages, such as wireless data network communications and / or wired communication messages, can be processed to identify vehicle status conditions and provide feedback regarding vehicle status and / or changes. In one example, a user profile can be applied to a particular vehicle to authorize a current vehicle event, a service stop at a service station, authorize subsequent vehicle rental services, and enable vehicle-to-vehicle communication.

[0012] Within a communications infrastructure, a distributed database is a distributed storage system that includes multiple nodes communicating with each other. A blockchain is an example of a distributed database that includes an append-only, immutable data structure (i.e., a distributed ledger) that allows records to be maintained among untrusted parties. The untrusted parties are referred to herein as peers, nodes, or peer nodes. Each peer maintains a copy of the database record, and no peer can modify the database record without reaching consensus among the distributed peers. For example, peers may execute a consensus protocol to validate blockchain storage entries, organize the storage entries into blocks, and build a hash chain through the blocks. This process forms a ledger by ordering the storage entries as necessary for consistency. In a public or permissionless blockchain, anyone can participate without specific identity. Public blockchains are involved in cryptocurrencies and may use consensus based on various protocols, such as proof-of-work (PoW). Conversely, a permissioned blockchain database can ensure interaction among a group of entities that share a common goal but do not or cannot fully trust each other, such as entities exchanging funds, goods, information, and the like. The solution can function in permissioned and / or permissionless blockchain settings.

[0013] Smart contracts are trusted decentralized applications that leverage the tamper-resistant properties of a shared or distributed ledger (which may be in the form of a blockchain) and an underlying agreement between member nodes called an endorsement or endorsement policy. Generally, blockchain entries are "approved" before being committed to the blockchain, while entries that are not endorsed are ignored. A typical endorsement policy allows the smart contract executable code to specify an endorser for the 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 policy is executed to validate the entry. After validation, the entry enters an ordering phase, during which a consensus protocol generates an ordered sequence of endorsed entries organized into blocks.

[0014] A node is a communicating entity in a blockchain system. A "node" may perform a logical function, in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped together within a trust domain and associated with logical entities that control the node in various ways. Nodes may include different types, such as client or submitting client nodes, which submit entry calls to endorsers (e.g., peers) and broadcast entry proposals to an ordering service (e.g., ordering node). Another type of node is a peer node, which may receive client-submitted entries, commit the entries, and maintain a ledger state and copy of the blockchain entries. A peer may also have the role of an endorser. An ordering service node, or orderer, is a node that performs communication services for all nodes and implements delivery guarantees, such as broadcasting to each of the peer nodes in the system, when committing entries and modifying the blockchain world state. The world state may constitute the initial blockchain entry, typically including control and configuration information.

[0015] A ledger is an ordered, tamper-resistant record of all state transitions of a blockchain. A state transition may result from an invocation (i.e., an entry) of smart contract executable code submitted by a participating party (e.g., client node, ordering node, endorser node, peer node, etc.). An entry may result in a set of key-value pairs of assets that are committed to the ledger as one or more operands, such as creation, update, deletion, and the like. A ledger includes a blockchain (also called a chain) that stores immutably ordered records in blocks. A ledger also includes a state database that maintains the current state of the blockchain. There is typically one ledger per channel. Each peer node maintains a copy of the ledger for each channel in which it is a member.

[0016] A chain is an entry log structured as hash-linked blocks, where each block contains a sequence of N entries, where N is 1 or greater. The block header contains a hash of the block's entries and a hash of the previous block's header. In this way, all entries in the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash links. The hash of the most recently added blockchain block represents all entries on the chain that came before it, ensuring that all peer nodes are in a consistent and trusted state. The chain can be stored in the peer node file system (i.e., locally, on attached storage, in the cloud, etc.) to efficiently support 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's entry log. Because the current state represents the most recent key values ​​known to the channel, it is sometimes referred to as the world state. Invocations of smart contract executable code execute entries against the ledger's current state data. To make the smart contract executable code's interactions efficient, the most recent values ​​of keys may be stored in a state database. The state database may simply be an indexed view into the chain's entry log, and therefore may be regenerated from the chain at any time. The state database may be automatically restored (or generated if necessary) upon peer node startup and before entries are accepted.

[0018] Blockchains differ from traditional databases in that they are not centralized storage, but rather distributed, immutable, and secure storage, where nodes must share changes to records in storage. Some properties inherent in blockchains and that aid in their implementation include, but are not limited to, immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, and the like.

[0019] Exemplary embodiments provide service for a particular vehicle and / or a user profile applied to the vehicle. For example, a user may be the owner of the vehicle or an operator of a vehicle owned by another party. The vehicle may require service at specific intervals, and service requests may require approval before service is permitted. A service center may also provide service to vehicles in a nearby area based on the vehicle's current route plan and the relative level of service requirement (e.g., urgent, critical, moderate, minor, etc.). Vehicle requests may be monitored via one or more vehicle and / or roadway sensors or cameras that report sensed data to a central controller computing device within the vehicle and / or remote from the vehicle. This data is forwarded to a management server for review and action. Sensors may be located on one or more of the interior of the vehicle, the exterior of the vehicle, on fixed objects remote from the vehicle, and on another vehicle near the vehicle. Sensors may also be associated with vehicle speed, vehicle braking, vehicle acceleration, fuel level, service requests, vehicle gear shifting, vehicle maneuvering, and the like. Sensors as described herein may also be devices, such as wireless devices, within and / or near the vehicle. Sensor information may also be used to identify whether the vehicle is operating safely and whether the occupant has engaged in any unexpected vehicle conditions, such as during vehicle access and / or usage. Vehicle information collected before, during, and / or after vehicle operation may be identified and stored in transactions on a shared / distributed ledger, which may be created and committed to an immutable ledger as determined in a “decentralized” manner by a permission-granting consortium, such as a blockchain membership group.

[0020] Each interested party (i.e., owner, user, company, agency, etc.) may want to limit the exposure of private information, and therefore, the blockchain and its immutability can be used to manage permissions for each specific user-vehicle profile. Smart contracts can be used to provide compensation, quantify user profile scores / ratings / reviews, apply vehicle event permissions, determine when service is needed, identify collision and / or degradation events, identify events that pose safety concerns, identify event participants, and distribute the vehicle event data to registered entities seeking access to the data. Results can also be identified, and necessary information can be shared among registered companies and / or individuals based on a consensus method associated with the blockchain, which may not be implemented in a traditional centralized database.

[0021] To create maps of terrain and roads that the vehicle can use for navigation and other purposes, the various driving systems of the present solution may utilize software, sensor arrays, and machine learning capabilities, light detection and ranging (lidar) projectors, radar, ultrasonic sensors, etc. In some embodiments, instead of lidar, GPS, maps, cameras, sensors, and the like may also be used in autonomous vehicles.

[0022] In certain embodiments, the solution includes authorizing a vehicle for service through an automated, rapid authentication scheme. For example, driving to a charging station or fuel pump can be performed by the vehicle operator or the autonomous vehicle, and authorization to receive charge or fuel can occur without any delay once authorization is received by the service and / or charging station. The vehicle can provide a communication signal providing the vehicle's identity, which has a currently active profile linked to an account authorized to receive service that can later be modified with compensation. Additional measures can be used to provide further authentication, for example, another identifier can be wirelessly transmitted from the user's device to the service center to replace or supplement the first authorization between the vehicle and the service center with the additional authorization.

[0023] The shared and received data may be stored in a database, which generally maintains the data in a specific location within a single database (e.g., a database server). This location is often a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a centralized database is typically accessible from multiple different points. Centralized databases are easy to manage, maintain, and control, and are particularly suitable for security purposes because the centralized database is in a single location. In a centralized database, having all data in a single storage location also means that a given data set has only one primary record, thereby minimizing data redundancy. Blockchain may be used to store vehicle-related data and transactions.

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

[0025] FIG. 1A illustrates an exemplary system diagram in which a vehicle receives secure software application updates managed by a server, according to an exemplary embodiment. Referring to FIG. 1A , system configuration 100 includes vehicle 130 identified as a candidate for receiving secure software updates and source code applications that are processed securely through obfuscation. Server 160 may be a remote computer in a cloud network or a local computer operating near vehicle 130, such as a mobile device or other computing device associated with vehicle 130. Mobile device 120 may be part of the software security functions performed by server 160. In one example, mobile device 120 may store secret information used to decrypt / deobfuscate source code data that was previously obfuscated with encrypted data, dummy values, etc.

[0026] Referring to FIG. 1A , example 100 provides that server 160 receives 116 a command or request to compile source or a particular application. Server 160 may identify 118 a group of dummy values ​​or obfuscated data (e.g., encrypted data, substitute data, non-critical data), retrieve 119 a list of secret values, and map 122 the dummy values ​​to actual data based on one or more secret values ​​stored in a secure location. The dummy values ​​are then converted (modified) 124 to actual data or intended values ​​in the source code. 126 The source code in the vehicle software or other location may be updated to include the software application build based on the source code in the appropriate source code format. The decryption / deobfuscation may be performed at server 160 and transmitted to the intended device location, e.g., mobile device 120 and / or vehicle 130. The secret data used to determine the data may be stored at server 160, mobile device 120, vehicle 130, or a combination of one or more of the devices. For example, the server 160 may manage the source code compilation process by extracting dummy values ​​from a device such as the mobile device 120 when the mobile device 120 is close to the vehicle 130 (e.g., within 10 yards (approximately 9.144 m)) and attempt to update the source code and applications in the vehicle 130 based on the source code.

[0027] FIG. 1B illustrates a network diagram in which a vehicle, a mobile device, and a server manage software application security processes, according to an exemplary embodiment. Referring to FIG. 1B, network 150 includes a vehicle management server 160 that can maintain the status of vehicle 130. Server 160 can identify what the current value of the vehicle's operating system is at any given time and / or any other applications that vehicle 130 is running. Application source code may need to be installed on vehicle 130 or other devices. The example of FIG. 1B may include identifying 162 a request to compile software, such as source code, stored in a specific memory location on a device, e.g., vehicle 130, server 160, etc. While the secret needed to decrypt data may be stored on any device, delivery of the secret may be based on one or more criteria, such as the proximity of mobile device 120 to vehicle 130 (e.g., within 100 feet, 30 feet, etc.). This can ensure that the correct user profile and user device are within operating distance of the correct vehicle 130 before authorization occurs. The secret can then be sent to the device performing the conversion, and source code conversion can then be performed based on the update operation (166). Dummy values ​​can be replaced by selecting a data set that is considered to be real data before the source code is compiled.

[0028] Based on a mapping of dummy values ​​to secret data, substituting dummy values ​​in the source code at compile time with the secret data can be used to generate the resulting binary code. Data breaches are on the rise. Hackers and bad actors have discovered that one of the best ways to access databases and their valuable data is to identify the source code and extract the credentials needed to access specific services. Some breaches have been found to be caused by credentials left inside the source code.

[0029] Storing secrets in code is a mistake, as it can unintentionally expose credentials. This includes access keys to source code repositories, databases, cloud-based services, API keys, and other sensitive information. Even encrypted secrets should be kept separate from the source code for improved security. Furthermore, manual inspection through code reviews does not guarantee that reviewers will catch every instance of one's sensitive information in every file. A better approach is to obfuscate coding secrets using substitution variables in the source code. The variables can then be maintained in a separate, encrypted location, isolated from the source code and ensuring no accidental exposure in the code repository. Then, at compile time or runtime, the variable value can be extracted with a function call, decrypted, and used for its intended purpose.

[0030] Once a secret is obfuscated from the source code, the secret is maintained as a list with an encrypted value in a secure storage device. Utilizing the secret at compile time requires appropriate logic that can access the secret from the secure storage device, decrypt the secret, and reconstruct the actual value for the secret by using the secret in the code. One exemplary approach may include receiving a request to run a software application and identifying one or more dummy values ​​in the application. A process then converts the dummy values ​​back to secrets based on a mapping of the dummy values ​​to secret values. The process then compiles the source code into binary code, replacing the dummy values ​​with the secret values ​​during generation of the binary code. Abstracting the secret replacement process at compile time ensures that the secret is never revealed in the source code and that the secret is excluded from the local development computer, as well as the source code repository and backups of the repository.

[0031] As an example, #define SECRET_STRING “IA235579” / / It could instead be written as #define SECRET_STRING @SS_24@ / / This can be replaced with #define SECRET_STRING “aiDdzCOidDNSdnaWdo==”. The technique may provide a way to protect secret data until the time immediately prior to data compilation.

[0032] One exemplary process may include identifying one or more dummy values ​​previously stored in source code of a software application, converting the one or more dummy values ​​into source code using one or more secret values ​​stored in a data store, and compiling, via a device, the source code of the software application into binary code using the secret values. The dummy values ​​may be completely arbitrary or may indicate locations or other identifying attributes that provide hints about where secret data is stored and how to use the secret data with the source code. In response to receiving a request, the process may replace the one or more dummy values ​​with one or more secret values ​​to generate binary code, map the dummy values ​​to the secret values ​​to generate unencrypted data, and apply the unencrypted data to the source code. The dummy values ​​may be mapped to the secret data in a one-to-one relationship character by character and / or via a cut-and-paste operation that removes the dummy values ​​and places the secret values ​​at specific starting points in the code. The dummy value may be considered obfuscated code, which may be decrypted by applying a secret value to the dummy value in or through a substitution process, where the secret value serves as a key used to combine with the dummy value in a processing operation that allows the result to yield one or more different characters as a result of the transformation of the dummy value and the secret value. The process may also include retrieving a list having the secret value from a data store on a device separate from the device performing the compilation and decrypting the secret value using a key stored on the separate device. In this example, server 160 may assist in storing and / or transforming the source code, and vehicle 130 and / or mobile device 120 may also play a role in the final process of transforming and compiling the code. In one example, all substitution, transformation, and compilation occurs on server 160.In another example, the vehicle 130 and the mobile device 120 must be within close proximity (distance "D") of each other before the secret value is released and applied to the source code. A confirmation may be generated when the mobile device 120 and the vehicle 130 are near each other. The confirmation then allows the secret data to be released to the source code. The separate devices may include one or more of the vehicle and the mobile devices of the vehicle occupants.

[0033] The process also includes identifying that a vehicle equipped with the device is near a location, transferring a software application to the vehicle's device in response to the vehicle's proximity, identifying that the occupant's mobile device is near the location, and retrieving a secret value from the mobile device. The source code may be a software build that is to be updated on the vehicle's computing device once the secret data is retrieved and applied. In one example, the vehicle 130 may be attempting to receive an updated software build, but before receiving the build, the server 160 needs to compile the software build and send it to the vehicle 130, or, if an uncompiled build is compiled on the vehicle via the vehicle computing system, send the build to the vehicle 130. The vehicle 130 may receive confirmation that an authorized user is present when the mobile device 120 is near the vehicle 130. The mobile device 120 may already have the secret data sent to the vehicle 130 by the server 160. Alternatively, the server 160 may then send the secret data to the vehicle 130 for compilation purposes when the mobile device 120 is near.

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

[0035] It is important to note that all flow diagrams and corresponding processes derived from Figures 1A, 2C, 2D, 2E, and 2F may be part of the same process or may share sub-processes with each other, thus making the diagrams combinable into a single preferred embodiment that does not require any one specific operation, but performs specific operations from one exemplary process and one or more additional processes. All exemplary processes relate to the same physical system and may be used separately or interchangeably.

[0036] The solution may be used with one or more types of vehicles: battery electric vehicles, hybrid vehicles, fuel cell vehicles, internal combustion engine vehicles, and / or vehicles that utilize renewable sources.

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

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

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

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

[0041] The processor 204 performs one or more of the following: receiving a request to compile a software application 244C; identifying one or more dummy values ​​previously stored in the source code of the software application 246C; converting the one or more dummy values ​​into the source code using one or more secret values ​​stored in the data store 248C; and compiling, via the device, the source code of the software application into binary code using the secret values ​​249C.

[0042] 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-transitory computer-readable medium 242D. The processor 204 is communicatively coupled to the computer-readable medium 242D and to element 230 (depicted in FIG. 2B). The vehicle 202 may be a vehicle, a server, or any device having a processor and memory.

[0043] In response to receiving the request, the processor 204 performs one or more of the following: replacing one or more dummy values ​​with one or more secret values ​​to generate binary code, mapping the dummy values ​​to the secret values ​​to generate unencrypted data, and applying the unencrypted data to the source code 244D; the dummy values ​​being obfuscated code that can be decrypted by applying the secret values ​​to the dummy values ​​245D; retrieving a list comprising the secret values ​​from a data store on a device separate from the compiling device and decrypting the secret values ​​using a key stored on the separate device 246D; the separate device comprising one or more of a vehicle and a mobile device of a vehicle occupant 247D; identifying that a vehicle comprising the device is near a location and, in response to the vehicle being near, transferring the software application to the vehicle's device 248D; and identifying that the occupant's mobile device is near the location and retrieving the secret value from the mobile device 249D.

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

[0045] 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 comprising a blockchain consensus between peers represented by any of the elements; and executing a smart contract to record the confirmation in the blockchain consensus. The consensus is formed between any of the elements 230 and / or one or more of the elements described or depicted herein, including a vehicle, a server, a wireless device, etc. In another example, the vehicle 202 can be any of the elements 230 and / or one or more of the elements described or depicted herein, including a server, a wireless device, etc.

[0046] The processor and / or computer-readable medium may reside, completely or partially, inside or outside the vehicle. The steps or features stored on the computer-readable medium may be performed, completely or partially, in any order by any of the processors and / or elements. Furthermore, one or more steps or features may be added, omitted, combined, performed later, etc.

[0047] 2E illustrates a flow diagram 260 according to an example embodiment. Referring to FIG. 2E, the solution includes one or more of receiving a request to compile a software application 244E, identifying one or more dummy values ​​previously stored in source code of the software application 246E, converting the one or more dummy values ​​into source code using one or more secret values ​​stored in a data store 248E, and compiling, via a device, the source code of the software application into binary code using the secret values ​​249E.

[0048] 2F shows another flow diagram 270 according to an example embodiment. Referring to FIG. 2F , the solution includes one or more of: in response to receiving a request, replacing one or more dummy values ​​with one or more secret values ​​to generate binary code, mapping the dummy values ​​to the secret values ​​to generate unencrypted data, and applying the unencrypted data to the source code 244F, the dummy values ​​being obfuscated code that can be decrypted by applying the secret values ​​to the dummy values ​​245F; retrieving a list comprising the secret values ​​from a data store on a device separate from the compiling device and decrypting the secret values ​​using a key stored on the separate device 246F; the separate device comprising one or more of a vehicle and a mobile device of a vehicle occupant 247F; identifying that a vehicle comprising the device is near a location, and in response to the vehicle being near, transferring the software application to the vehicle device 248F; and identifying that the occupant's mobile device is near the location and retrieving the secret value from the mobile device 249F.

[0049] Technological advances typically build on the foundations of previous technologies, and this is especially true for artificial intelligence (AI) models. AI classification systems describe stages in AI development. The first classification is known as "reactive machines," followed by today's AI classification of "limited memory machines" (also known as "narrow-focused artificial intelligence"), which then progresses to "theory of mind" (also known as "artificial general intelligence"), and finally to the AI ​​classification of "self-awareness" (also known as "artificial superintelligence"). Today's limited memory machines are a growing group of AI models built on their previous foundation: reactive machines. Reactive machines emulate human responses to stimuli, but are limited in their capabilities because they typically cannot learn from previous experiences. As learning capabilities in AI models emerged, the classification was promoted to limited memory machines. In this current classification, AI models inherit all of the functions of reactive machines, learning from large amounts of data, detecting patterns, solving problems, generating and predicting data, and the like. 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 any future AI models yet to be developed that have limited memory machine characteristics. Generative AI models incorporate ML and DL to combine limited memory machine technologies, forming the foundational building blocks of future AI models. For example, theory of mind is the next stage of AI development in which an AI model may be able to perceive, connect, and react by generating appropriate responses depending on the entity it is interacting with, all of which capabilities rely on the foundations of generative AI. Furthermore, as it evolves into self-aware classification, an AI model may also be able to understand and evoke emotions in the entities it interacts with, and may have its own emotions, beliefs, and needs, all of which rely on the foundations of generative AI for learning from experience to generate and draw conclusions about itself and its surroundings. Generative AI models are essential and fundamental to future artificial intelligence models.As described herein, generative AI refers to generative AI models today and future AI models.

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

[0051] In one embodiment, generative AI (GenAI) may be used by the present solution in the transformation of data. Vehicles are equipped with a variety of sensors, cameras, radar, and LIDAR, that collect a vast array of data, such as images, speed readings, GPS data, and acceleration metrics. However, once the raw data is acquired, it undergoes pre-processing, which may include normalization, anonymization, imputation of missing values, or noise reduction, allowing the data to be effectively further used.

[0052] GenAI performs data augmentation following data preprocessing. Due to the limitations of the dataset in capturing the high complexity of real-world vehicle scenarios, augmentation tools are employed to extend the dataset. This may include image-specific transformations such as rotation, translation, or brightness adjustment. For non-image data, techniques such as jittering may be used to simulate a wider set of conditions to create synthetic noise.

[0053] In this solution, data generation is then performed on the data. Tools such as generative adversarial networks (GANs) and variational autoencoders (VAEs) are trained on existing datasets to generate new plausible data samples. For example, GANs can be tasked with crafting images showing a vehicle in unknown conditions or from unique perspectives. As another example, sensor data synthesis can be performed to model and create synthetic readings for the scenario, enabling full system testing without actual physical experience. Given the safety-critical nature of vehicles, a key step in using GenAI is validation. This validation can involve comparing output data to real-world datasets or using specialized tools such as GAN classifiers to evaluate the realism of the crafted samples.

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

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

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

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

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

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

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

[0061] Once the necessary data is extracted (342), it must be prepared for model training (344). In some embodiments, this step includes statistical testing of the data to determine how well the data reflects real-world events, the distribution of the data, the variety of data in the dataset, etc. In some embodiments, the results of this statistical testing may lead to one or more data transformations being employed to normalize one or more values ​​in the dataset. In some embodiments, this step includes cleaning data that is considered noisy. A noisy dataset includes values ​​that do not contribute to training, including, but not limited to, null long string values. Data preparation 344 can be a manual or automated process using one or more of the elements, functions, etc. described or depicted herein.

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

[0063] The dataset output from the feature extraction step 346 is separated 348 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.

[0064] The AI / ML model 332 is trained and tuned (350) using the training dataset from the data separation step 348. In this step, the training dataset is fed to an initial set of AI / ML algorithms and 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 with adjustments to one or more algorithm parameters until the model's performance is acceptable based on various goals and / or outcomes.

[0065] The AI / ML model 332 is evaluated (352) in a staging environment (not shown) that resembles the final AI / ML production system 330. This evaluation uses a validation dataset to ensure that performance in the AI / ML production system 330 matches or exceeds expectations. In some embodiments, the validation dataset from step 348 is used. In other embodiments, one or more unknown validation datasets are used. In some embodiments, the 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, where it can be retrieved for deployment and future updates. As before, in some embodiments, the model evaluation step 352 is a manual or automated process using one or more of the elements, functions, or aspects described or depicted herein.

[0066] Once the AI / ML model 332 is validated and published to the AI / ML model registry 360, it may be deployed (354) to one or more AI / ML production systems 330. In some embodiments, the performance of the deployed AI / ML model 332 is monitored (356) by the AI / ML development system 340. In some embodiments, AI / ML model 332 feedback data 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, the model performance monitoring includes one or more triggers that cause the AI / ML model 332 to be updated by repeating steps 342-354 with updated data from one or more data sources.

[0067] 3C illustrates a process 300C for utilizing AI / ML models to support AI-assisted vehicle or occupant decision points. As previously mentioned, the AI ​​model utilization process depicted herein reflects a specific branch of AI, ML, but the solution is not limited to ML, nor is it limited to any AI algorithm or combination of algorithms.

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

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

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

[0071] Numerous steps / features that may utilize the AI / ML process described herein include receiving a request to compile a software application, identifying one or more dummy values ​​previously stored in the source code of the software application, converting the one or more dummy values ​​into source code using one or more secret values ​​stored in a data store, compiling, via a device, the source code of the software application into binary code using the secret values, and, in response to receiving the request, replacing the one or more dummy values ​​with one or more secret values ​​to generate the binary code, mapping the dummy values ​​to the secret values ​​to generate unencrypted data, and converting the unencrypted data into source code. the dummy values ​​are obfuscated code that can be decrypted by applying a secret value to the dummy values; retrieving a list comprising the secret values ​​from a data store on a device separate from the compiling device and decrypting the secret values ​​using a key stored on the separate device, the separate device comprising one or more of a vehicle and a mobile device of a vehicle occupant; identifying that a vehicle comprising the device is near a location and, in response to the vehicle being near, transferring the software application to the vehicle's device; and identifying that the occupant's mobile device is near the location and retrieving the secret value from the mobile device.

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

[0073] 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 FIG. 3D, a user may add pieces / components to a model being developed within a workspace 374 of the user interface 370 using input mechanisms from menus 372 of the user interface 370.

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

[0075] In another example, the name of the object may be identified from a web page or user interface 370, where the object is recognizable within a browser or workspace 374 on the user device. A pop-up within the browser or workspace 374 may be superimposed where the object is recognizable, which includes an option to navigate via a rule set to an identifying web page corresponding to an alternative object.

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

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

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

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

[0080] FIG. 4A shows a diagram 400A depicting the power supply of one or more elements. In one example, a vehicle 402B can provide 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 can be connected to one or more of the charging stations 406B, which can be connected to one or more of the vehicles 408B. This configuration enables the distribution of electricity / power received from the vehicle 402B. The vehicle 402B can also interact with other vehicles 408B via V2V technology, cellular communication, Wi-Fi, and the like. The vehicle 402B can also interact with other vehicles 408B, charging stations 406B, and / or the electric grid 404B wirelessly and / or via wired connections. In one example, vehicle 402B is routed (or routes itself) to electric grid 404B, charging station 406B, or other vehicles 408B in a safe and efficient manner. Using one or more embodiments of the present solution, vehicle 402B may provide energy to one or more of the elements depicted herein in various advantageous ways as described and / or depicted herein. Additionally, vehicle safety and efficiency may be enhanced, and environmental impacts may be positively impacted as described and / or depicted herein.

[0081] The terms “energy,” “electricity,” “power,” and the like may be used to refer to any form of energy received, stored, used, shared, and / or lost by a vehicle. Energy may refer to a voltage source of electrical charge and / or a current supply provided from an entity to a vehicle during charging / use operations. Energy may also be in the form of fossil fuels (e.g., for use in hybrid vehicles) or from 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 that increase or decrease one or more vehicle energy levels at a given time.

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

[0083] In one embodiment, a location, such as a building, residence, or the like (not depicted), is communicatively connected to one or more of an electric grid 404B, a vehicle 402B, and / or a charging station 406B. The rate at which electricity flows to the location, vehicle 402B, and / or one or more of the other vehicles 408B is modified in response to external conditions, such as weather. For example, when the external temperature is very hot or very cold, increasing the likelihood of a power outage, the flow of electricity to the connected vehicles 402B / 408B is slowed to help minimize the likelihood of a power outage.

[0084] In one embodiment, vehicles 402B and 408B may be utilized as bidirectional vehicles. Bidirectional vehicles may function as a mobile microgrid that can assist in supplying power to grid 404B and / or reduce power consumption when the grid is stressed. Bidirectional vehicles incorporate bidirectional charging; in addition to receiving charge for the vehicle, the vehicle may transfer energy from the vehicle to grid 404B, otherwise referred to as "V2G." In bidirectional charging, electricity flows both to and from the vehicle. When the vehicle is charged, alternating current (AC) electricity from grid 404B is converted to direct current (DC). This may be done by one or more converters on the vehicle itself or at charging station 406B. Energy stored in the vehicle's battery may be sent back to the grid in the opposite direction. Energy is converted from DC to AC through a converter, typically located at charging station 406B, otherwise referred to as a bidirectional charger. Moreover, the solution as described and depicted with respect to FIG. 4B may be utilized in this network and / or system, as well as other networks and / or systems.

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

[0086] In one embodiment, whenever charge is provided to or received from a charging station and / or the electrical grid, the entities that enable this to occur are one or more of the vehicle, the charging station, a server, and a network communicatively connected to the vehicle, the charging station, and the electrical grid.

[0087] In one example, the vehicles 408C / 404C may transport people, objects, permanently or temporarily attached equipment, and the like. In one example, the vehicles 408C may communicate with the vehicles 404C via V2V communications through computers 406C and 410C associated with each vehicle and may be referred to as cars, vehicles, automobiles, and the like. The vehicles 404C / 408C may be self-propelled, wheeled vehicles such as cars, sport utility vehicles, trucks, buses, vans, or other motor- or battery-powered or fuel-cell-powered vehicles. For example, the vehicles 404C / 408C may be electric vehicles, hybrid vehicles, hydrogen fuel cell vehicles, plug-in hybrid vehicles, or any other type of vehicle having a fuel cell stack, motor, and / or generator. Other examples of vehicles include bicycles, scooters, trains, airplanes, boats, and any other form of vehicle capable of transportation. The vehicles 404C / 408C may be semi-autonomous or autonomous. For example, vehicle 404C / 408C may be on autopilot and navigate without human input. An autonomous vehicle may have and use one or more sensors and / or navigation units to drive autonomously. All of the data described or depicted herein may be stored, analyzed, processed, and / or transmitted by one or more of the elements in FIG. 4B.

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

[0089] ECUs 410D, 408D and head unit 406D may each include a custom security function element 414D that defines approved processes and the contexts in which they are allowed to operate. Context-based authorization, which determines the validity of whether a process can be executed, allows the ECU to maintain secure operation and prevent unauthorized access from elements such as the vehicle's CAN bus. If the ECU encounters an unauthorized process, the ECU may prevent the process from operating. Automotive ECUs may use various contexts to determine whether a process is operating within its permitted boundaries, such as proximity context, nearby objects, distance to approaching objects, speed, trajectory relative to other moving objects, and operational contexts such as an indication of whether the vehicle is moving or parked, the vehicle's current speed, transmission status, devices connected to the vehicle via wireless protocols, user-related contexts such as infotainment usage, cruise control, parking assistance, driving assistance, location-based contexts, and / or other contexts.

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

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

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

[0093] The memory 422E of the vehicle 410E may store one or more of the following types of data: 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.

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

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

[0096] The sensor set 412E may include any sensors in the vehicle 410E that generate sensor data. For example, the sensor set 412E may include short-range sensors and long-range sensors. In some embodiments, the sensor set 412E of the vehicle 410E may include one or more of the following vehicle sensors: a camera, a light detection and ranging (lidar) sensor, an ultrasonic sensor, an automobile engine sensor, a radar sensor, a laser altimeter, a manifold absolute pressure sensor, an infrared detector, a motion detector, a thermostat, an audio 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 fault detector, a Hall effect sensor, a parking sensor, a speed 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 moisture sensor, a wheel speed sensor, a global positioning system (GPS) sensor, a mapping function, and any other type of automobile sensor. The navigation system 418E may store the sensor data in memory 422E.

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

[0098] The vehicle 410E may interact with other vehicles 406E via V2V technology. In one example, the V2V communication includes detecting radar information corresponding to a relative distance to an external object, receiving GPS information of the vehicle, setting an area in which the other vehicle 406E is located based on the detected radar information, calculating a probability that the GPS information of the target vehicle is located in the set area, and identifying the vehicle and / or object corresponding to the radar information and GPS information of the target vehicle based on the calculated probability.

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

[0100] ECUs are nodes within a vehicle that control tasks ranging from windshield wiper operation to anti-lock braking systems. ECUs are often connected to one another through a central vehicle network that may be referred to as a Controller Area Network (CAN). Cutting-edge features such as autonomous driving rely heavily on the implementation of new and complex ECUs, such as ADAS, sensors, and the like. While these new technologies are helping to improve vehicle safety and the driving experience, they also increase the number of external communication units within the vehicle, making them more vulnerable to attacks. Below are some examples of securing vehicles from physical and remote intrusions:

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

[0102] In this example, the ECU includes a transceiver and a microcontroller. The transceiver can be used to send and receive messages to and from the CAN bus. For example, the transceiver can convert data from the microcontroller into a format for the CAN bus and convert data from the CAN bus into a format for the microcontroller. Meanwhile, in one example, the microcontroller interprets the messages and determines which messages to send using ECU software installed on the microcontroller.

[0103] Various security protocols can be implemented to protect the CAN from cyber threats. For example, sub-networks (e.g., sub-networks A and B) can be used to divide the CAN into smaller sub-CANs to limit an attacker's ability to remotely access the vehicle. In one embodiment, a firewall (or gateway, etc.) can be added to prevent messages from traversing the CAN bus beyond the sub-network. If an attacker gains access to one sub-network, the attacker does not have access to the entire network. In one example, to make the sub-networks even more secure, the most critical ECUs are not placed in the same sub-network.

[0104] In addition to protecting the vehicle's internal network, the vehicle may also be protected when communicating with external networks, such as the Internet. One advantage of having a vehicle connected to a data source, such as the Internet, is that information from the vehicle can be transmitted over the network to a remote location for analysis. Examples of vehicle information include GPS, on-board diagnostics, tire pressure, and the like. Because these communication systems involve a combination of telecommunications and informatics, the communication systems are often referred to as telematics. Furthermore, the present solution as described and depicted may be utilized with this and other networks and / or systems, including those described and depicted herein.

[0105] FIG. 4E illustrates an example 400E of vehicles 402I and 408I engaging in secure V2V communication using security certificates, according to an exemplary embodiment. Referring to FIG. 4E, vehicles 402I and 408I may communicate via V2V communication over a short-range network, a cellular network, or the like. Prior to sending a message, vehicles 402I and 408I may sign the message using their respective public key certificates. For example, vehicle 402I may sign a V2V message using public key certificate 404I. Similarly, vehicle 408I may sign a V2V message using public key certificate 410I. In one example, public key certificates 404I and 410I are associated with vehicles 402I and 408I, respectively.

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

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

[0108] For example, the authorization module may store passwords, usernames, PIN codes, biometric scans, and the like for various vehicle users. The authorization module may determine whether a user (or technician) has permission to access certain settings, such as the vehicle's computer. In some embodiments, the authorization module may communicate with a network interface to download any necessary authorization information from an external server. When a user requests to make a change to a vehicle setting or modify the vehicle's technical details via a console or GUI in the vehicle or via an attached / connected device, the authorization module may require the user to identify themselves in some way before the setting is changed. For example, the authorization module may require a username, password, PIN code, biometric scan, a predefined line drawing or gesture, and the like. In response, the authorization module may determine whether the user has the necessary permission (e.g., access) being requested.

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

[0110] The encryption module may store asymmetric key pairs used by the vehicle to communicate with other external user devices and vehicles. For example, the encryption module may provide a private key used by the vehicle to encrypt / decrypt communications, while a corresponding public key may be provided to other user devices and vehicles to enable the other devices to decrypt / encrypt communications. The encryption module may communicate with a remote server to receive new keys, updates to keys, new vehicle or user keys, and the like. The encryption module may also send any updates to the local private / public key pair to the remote server.

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

[0112] In one embodiment, when a vehicle reaches a situation where a service needs to be shared with another vehicle, the vehicle may engage with the other vehicle to perform various actions, such as sharing, transmitting, or obtaining a service request. For example, the vehicle may be due for battery charging and / or may have a tire problem, or may be on route to pick up a delivery package. The vehicle processor resides in the vehicle, and communication exists between the vehicle processor, a first database, and a transaction module. The vehicle may notify another vehicle in its network and operating on its blockchain member service. The vehicle processor resides in another vehicle, and communication exists between the vehicle processor, a second database, the vehicle processor, and the transaction module. The other vehicle may then receive information via a wireless communication request from the vehicle and / or from a server (not shown) to perform package pickup. The transaction is logged in the transaction modules of both vehicles. Credits are transmitted from the vehicle to the other vehicle, and a record of the transmitted service is logged in a first database, assuming the blockchains are different from each other, or in the same blockchain used by all members. The first database may be one of an SQL database, an RDBMS, a relational database, a non-relational database, a blockchain, a distributed ledger, may be on-board the vehicle, may be off-board the vehicle, and may be accessible directly and / or over a network.

[0113] FIG. 5B illustrates a blockchain architecture configuration 500B according to an example embodiment. Referring to FIG. 5B, the blockchain architecture 500B may include a group of blockchain member nodes 502-505 as part of a particular blockchain element, e.g., a blockchain group 510. In an example embodiment, a permissioned blockchain is accessible only to members who have permission to access the blockchain data, rather than all parties. Blockchain nodes participate in numerous activities, such as the addition and validation process (consensus) of blockchain entries. One or more of the blockchain nodes may approve entries based on an endorsement policy and provide an ordering service for all blockchain nodes. Blockchain nodes may initiate blockchain operations (e.g., authentication) and attempt to write to the blockchain immutable ledger stored in the blockchain, a copy of which may also be stored on the underlying physical infrastructure.

[0114] Once a transaction is received and approved by a consensus model determined by the member nodes, the blockchain transaction 520 is stored in the computer's memory. The approved transaction 526 is stored in the blockchain's current block and committed to the blockchain via a commit procedure, which involves hashing the data content of the transaction in the current block and referencing a previous hash in the previous block. Within the blockchain, there may be one or more smart contracts 530 that define the terms of transaction agreement and operation, such as registered recipients, vehicle features, requirements, permissions, and sensor thresholds, contained in smart contract executable application code 532. The code may be configured to identify whether a requesting entity is registered to receive vehicle services, which service features the entity is eligible / required to receive given the entity's profile status, and whether to monitor the entity's behavior at a later time. For example, when a service event occurs and a user is in the vehicle, monitoring of sensor data may be triggered, and a certain parameter, such as the vehicle's charge level, may be identified as being above / below a certain threshold for a certain period of time, which may then result in a change in the current status, necessitating the sending of an alert to a controlling party (i.e., the vehicle owner, the vehicle operator, a server, etc.), so that a service can be identified and stored for reference. The vehicle sensor data collected may be based on the type of sensor data used to collect information about the vehicle's status. Sensor data may also be the basis for vehicle event data 534, such as where traveled, average speed, maximum speed, acceleration, whether there have been any collisions, whether the expected route has been taken, where the next destination is, whether safety measures have been implemented, whether the vehicle has sufficient charge / fuel, etc. All such information may be the basis for smart contract terms 530, which are then stored on the blockchain.For example, sensor thresholds stored in a smart contract can be used as the basis for whether a service needs to be detected and when and where the service should be performed.

[0115] In one embodiment, examples of blockchain logic include blockchain application interfaces as APIs or plug-in applications that link computing devices and execution platforms for specific transactions. A blockchain configuration may include one or more applications linked to application programming interfaces (APIs) to access and execute stored program / application code (e.g., smart contract executable code, smart contracts, etc.), which may be created according to customized configurations desired by participants, maintain their own state, control their own assets, and receive external information, which may be deployed and installed as entries by appending them to the distributed ledger on all blockchain nodes.

[0116] Smart contract application code provides the foundation for blockchain transactions by establishing application code that, when executed, enables transaction conditions and states. When executed, smart contracts result in the creation of specific approved transactions, which are then transmitted to a blockchain platform. The platform includes a computing device that performs security / authorization and transaction management, and a storage unit as memory for storing transactions and smart contracts in the blockchain.

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

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

[0119] Within smart contract executable code, smart contracts may be authored via high-level application and programming languages ​​and then written into blocks within a blockchain. Smart contracts may include executable code that is registered, stored, and / or replicated using a blockchain (e.g., a decentralized network of blockchain peers). Entry may occur upon execution of smart contract code, which may occur in response to conditions associated with the smart contract being met. Execution of a smart contract may trigger trusted modifications to the state of a digital blockchain ledger. Modifications to the blockchain ledger resulting from smart contract execution may be automatically replicated throughout the decentralized network of blockchain peers via one or more consensus protocols.

[0120] A smart contract may write data to the blockchain in the format of key-value pairs. Additionally, smart contract code may read values ​​stored in the blockchain and use those values ​​during application operation. Smart contract code may write the output of various logical operations into the blockchain. Code may be used to create temporary data structures within a virtual machine or other computing platform. Data written to the blockchain may be public and / or encrypted and kept private. Temporary data used / generated by a smart contract is kept in memory by the provided execution environment and then deleted once the data needed by the blockchain is identified.

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

[0122] FIG. 5C illustrates a blockchain configuration for storing blockchain transaction data, according to an exemplary embodiment. Referring to FIG. 5C, exemplary configuration 500C provides a vehicle 562, a user device 564, and a server 566 that share information with a distributed ledger (i.e., a blockchain) 568. In the event that a known, established user profile attempts to rent a vehicle with an established rating profile, the server may represent a service provider entity that queries a vehicle service provider to share user profile rating information. Server 566 may receive and process data related to the vehicle's service requirements. When a service event occurs, such as vehicle sensor data indicating a need for fuel / charge or maintenance service, a smart contract may be used to invoke rules, thresholds, sensor information collection, etc., that may be used to invoke a vehicle service event. Blockchain transaction data 570 is stored for each transaction, such as an access event, subsequent updates to the vehicle's service status, and event updates. A transaction may include the parties, requirements (e.g., age 18, eligible candidate for service, valid driver's license, etc.), coverage level, distance traveled during the event, registered recipients authorized to access the event and provide vehicle service, rights / permissions, sensor data retrieved during vehicle event operation to log details of the upcoming service event and identify vehicle condition status, and thresholds used to make decisions regarding whether the service event is completed and whether the vehicle condition status has changed.

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

[0124] The system includes a blockchain that stores immutably ordered records in blocks and a state database (current world state) that maintains the current state of the blockchain. One distributed ledger may exist per channel, with each peer maintaining its own copy of the distributed ledger for each channel in which it is a member. The blockchain is an entry log structured as hash-linked blocks, where each block contains a sequence of N entries. Blocks may contain various components, such as those shown in Figure 5D. Block links may be generated by adding a hash of the previous block's header to the current block's block header. In this way, all entries in the blockchain are ordered and cryptographically linked together, preventing tampering with blockchain data without breaking the hash link. Furthermore, because they are linked, the most recent block in the blockchain represents all entries that occurred before it. The blockchain may be stored on a peer file system (local or attached storage) to support append-only blockchain workloads.

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

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

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

[0128] 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 the entries are committed to the network. Unlike cryptocurrency blockchain systems, where ordering occurs through solving cryptographic puzzles or through mining, in this example, the parties to the distributed ledger can choose the ordering mechanism that best suits their network.

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

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

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

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

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

[0134] The distributed ledger 520E includes a blockchain, which stores immutably ordered records in blocks, and a state database 524E (current world state) that maintains the current state of the blockchain 522E. One distributed ledger 520E may exist per channel, and each peer maintains its own copy of the distributed ledger 520E for each channel in which it is a member. The blockchain 522E is a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions. Block links (indicated by arrows in FIG. 5E) may be generated by appending a hash of the previous block's header to the current block's block header. In this way, all transactions in the blockchain 522E are ordered and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because they are linked, the most recent block in the blockchain 522E represents all transactions that occurred before it. The blockchain 522E may be stored on a peer file system (local or attached storage) to support append-only blockchain workloads.

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

[0136] An endorsing node receives transactions from clients and approves the transactions based on the simulated results. The endorsing node holds smart contracts that simulate transaction proposals. When an endorsing node approves a transaction, it creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating its endorsement of the simulated transaction. The manner in which a transaction is approved depends on an endorsement policy, which may be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must approve the transaction." Different channels may have different endorsement policies. The approved transaction is forwarded by the client application to the ordering service 510E.

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

[0138] The ordering service 510E may consist of a cluster of orderers. The ordering service 510E does not process transactions or smart contracts, nor does it maintain a shared ledger. Rather, the ordering service 510E may accept approved transactions and specify the order in which they are committed to the distributed ledger 522E. The architecture of the blockchain network may be designed so that specific implementations of "ordering" are pluggable components.

[0139] 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 the transactions are committed to the network. Unlike cryptocurrency blockchain systems, where ordering occurs through solving cryptographic puzzles or through mining, in this example, the parties to the distributed ledger 520E can choose the ordering mechanism that best suits their network.

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

[0141] Referring to 500F in FIG. 5F , a new data block 530 (also referred to as a data block) stored on a blockchain 522E of a distributed ledger 520E may include multiple data segments, such as a block header 540, block data 550, and block metadata 560. It should be understood that the various blocks and their contents depicted, such as the new data block 530 and its contents shown in FIG. 5F , are merely illustrative and are not meant to limit the scope of the example embodiments. The new data block 530 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) in the block data 550. The new data block 530 may also include a link to a previous block (e.g., on the blockchain 522E in FIG. 5E ) in the block header 540. In particular, the block header 540 may include a hash of the previous block's header. The block header 540 may also include a unique block number, a hash of the block data 550 of the new data block 530, and the like. The block numbers of the new data block 530 are unique and may be assigned in various orders, for example, starting from zero and then increasing / consecutively.

[0142] The block data 550 may store transaction information for each transaction recorded in the new data block 530. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, distributed ledger 520E channel ID (shown in FIG. 5E), transaction ID, epoch, payload visibility, chaincode path (deployment transmission), chaincode name, chaincode version, inputs (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 (e.g., list of keys and versions read by the transaction), write set (e.g., list of keys and values), start key, end key, list of keys, Merkle tree query summary, and the like. Transaction data may be stored for each of the N transactions.

[0143] In one embodiment of the solution, the block data may include data including one or more of: receiving a request to compile a software application; identifying one or more dummy values ​​previously stored in source code of the software application; converting the one or more dummy values ​​into source code using one or more secret values ​​stored in a data store; and compiling, via a device, the source code of the software application into binary code using the secret values.

[0144] In FIG. 5F, blockchain data 563 is depicted in block data 550, but may also be located in block header 540 or block metadata 560.

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

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

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

[0148] 6 illustrates a computing environment according to an exemplary embodiment. FIG. 6 is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the present application described herein. Nevertheless, computing environment 600 may be implemented to perform any of the functions described herein. In computing environment 600, computer system 601 can operate within numerous other general-purpose or special-purpose computing system environments or configurations.

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

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

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

[0152] 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 (e.g., the Internet). The network adapter 603 bridges the computer's internal bus 620 and an external network to exchange data efficiently and reliably. The network adapter 603 may include hardware such as a modem or Wi-Fi signal transceiver, and software that packetizes and / or depacketizes data for transmission over a communications network. The network adapter 603 supports various communications protocols to ensure compatibility with network standards. For Ethernet connections, the network adapter 603 conforms to protocols such as IEEE 802.3, while for wireless communications, the network adapter 603 may support the IEEE 802.11 standard, Bluetooth, Near Field Communication (NFC), or other network radio wave standards.

[0153] Computer system 601 may include removable / non-removable, volatile / non-volatile computer storage devices 610. By way of example only, 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 bus 620. In embodiments where computer system 601 is required to have a large amount of storage (e.g., computer system 601 stores and manages large databases locally), this storage may then be provided by a peripheral storage device 610 designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers.

[0154] Operating system 611 is software that manages the hardware resources of computer system 601 and provides common services for computer programs. Operating system 611 can take several forms, such as various known proprietary operating systems or open-source Portable Operating System Interface type operating systems that employ a kernel.

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

[0156] Memory 630 may be any volatile memory now known or later developed. Examples include dynamic random access memory (RAM 631) or static type RAM 631. Volatile memory is typically characterized by random access, although this is not required unless expressly indicated. In computer system 601, memory 630 is in a single package and internal to computer system 601; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer system 601. By way of example only, memory 630 may be provided to read from and write to non-removable, non-volatile magnetic media (illustrated as storage device 610, commonly referred to as a "hard drive"). Memory 630 may include at least one program product having a set (e.g., at least one) of program modules configured to perform various functions. A typical computer system 601 may include cache 632, a dedicated volatile memory that is generally faster than RAM 631 and generally located closer to processing unit 602. Cache 632 stores frequently accessed data and instructions that are accessed by processing unit 602 to speed up processing time. Computer system 601 may include non-volatile memory 633 in the form of ROM, PROM, EEPROM, and flash memory. Non-volatile memory 633 often contains programming instructions for booting the computer, including the BIOS and information necessary to boot operating system 611.

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

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

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

[0160] The remote server 660 is any computer that provides at least some data and / or functionality to the computer system 601 over a network 650, such as a WAN, a virtual private network (VPN), a private cloud, or via the Internet. These networks 650 may communicate with a LAN to reach users. The user interface may include a web browser or 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 to emulate a desktop session, such as Microsoft RDP (Remote Desktop Protocol) or Citrix ICA (Independent Computing Architecture). Mobile applications may also be used. The remote server 660 also hosts a remote database 661, which may be located on one remote server 660 or distributed across multiple remote servers 660. The remote database 661 is accessible from the remote server 660 in the network 650, other remote servers 660, the user device 651, or a database client application installed locally on the computing system 601.

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

[0162] At least one preferred embodiment of the system, method, and non-transitory computer-readable medium is illustrated in the accompanying drawings and described in the foregoing detailed description; however, it will be understood that the present application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications, and substitutions as set forth 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, including pairs of transmitters, receivers, or both. 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 times and in conjunction with various events internal or external to the modules or components. Furthermore, information transmitted between the various modules may be transmitted between the modules via at least one of a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or multiple protocols. Furthermore, messages sent or received by any of the modules may be transmitted or received directly and / or via one or more of the other modules.

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

[0164] It should be noted that some of the system features described herein are presented as modules to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very large scale integrated (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, or the like.

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

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

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

[0168] Those skilled in the art will readily appreciate that the foregoing may be performed in a different order of steps and / or with hardware elements in different configurations than those disclosed. Thus, while the present application has been described based on these preferred embodiments, certain modifications, variations, and alternative constructions will be apparent to those skilled in the art.

[0169] While preferred embodiments of the present application have been described, it should be understood that the described embodiments are exemplary only, and that the scope of the present application should be determined solely by the appended claims when considered in light of the full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.) to which the claims apply.

Claims

1. receiving a request to compile a software application; identifying one or more dummy values ​​previously stored in the source code of the software application; converting the one or more dummy values ​​into source code using one or more secret values ​​stored in a data store; compiling, via a device, the source code of the software application into binary code using the secret value; A method comprising:

2. In response to receiving the request, replacing the one or more dummy values ​​with the one or more secret values ​​to generate the binary code; mapping the dummy value to the secret value to generate unencrypted data; applying the unencrypted data to the source code; The method of claim 1 , comprising:

3. The method of claim 1 , wherein the dummy value is an obfuscated code that can be decrypted by applying the secret value to the dummy value.

4. retrieving a list comprising the secret values ​​from the data store on a device separate from the device performing the compiling; decrypting the secret value using a key stored on the separate device; The method of claim 1 , comprising:

5. The method of claim 4 , wherein the separate devices include one or more of a vehicle and a mobile device of a vehicle occupant.

6. Identifying that a vehicle equipped with the device is near a location; transferring the software application to the device in the vehicle in response to the vehicle being near; The method of claim 1 , comprising:

7. Identifying a occupant's mobile device being near the location; retrieving the secret value from the mobile device; and The method of claim 6, comprising:

8. 1. A system comprising one or more processors, the one or more processors comprising: receiving a request to compile a software application; identifying one or more dummy values ​​previously stored in the source code of the software application; converting the one or more dummy values ​​into source code using one or more secret values ​​stored in a data store; A system configured to compile the source code of the software application into binary code using the secret value.

9. The one or more processors further include: responsive to receiving the request, replacing the one or more dummy values ​​with the one or more secret values ​​to generate the binary code; mapping the dummy value to the secret value to generate unencrypted data; The system of claim 8 , configured to apply the unencrypted data to the source code.

10. The system of claim 8 , wherein the dummy value is an obfuscated code that can be decrypted by applying the secret value to the dummy value.

11. The one or more processors further include: retrieving a list comprising the secret values ​​from the data store on a device separate from the compiling device; The system of claim 8 , configured to decrypt the secret value using a key stored on the separate device.

12. The system of claim 11 , wherein the separate devices include one or more of a vehicle and a mobile device of a vehicle occupant.

13. The one or more processors further include: Identifying that a vehicle equipped with the device is near a location; The system of claim 8 , configured to transfer the software application to the device of the vehicle in response to the vehicle being nearby.

14. The one or more processors: Identifying that a mobile device of an occupant is near the location; The method of claim 13 configured to retrieve the secret value from the mobile device.

15. A non-transitory computer-readable storage medium configured to store instructions that, when executed, cause a processor to: receiving a request to compile a software application; identifying one or more dummy values ​​previously stored in the source code of the software application; converting the one or more dummy values ​​into source code using one or more secret values ​​stored in a data store; compiling, via a device, the source code of the software application into binary code using the secret value; A non-transitory computer-readable storage medium that causes

16. The processor further comprises: In response to receiving the request, replacing the one or more dummy values ​​with the one or more secret values ​​to generate the binary code; mapping the dummy value to the secret value to generate unencrypted data; applying the unencrypted data to the source code; 16. The non-transitory computer-readable storage medium of claim 15, configured to:

17. 16. The non-transitory computer-readable storage medium of claim 15, wherein the dummy value is an obfuscated code that can be decrypted by applying the secret value to the dummy value.

18. The processor further comprises: retrieving a list comprising the secret values ​​from the data store on a device separate from the device performing the compiling; decrypting the secret value using a key stored on the separate device; 16. The non-transitory computer-readable storage medium of claim 15, configured to:

19. 20. The non-transitory computer-readable storage medium of claim 18, wherein the separate devices include one or more of a vehicle and a mobile device of a vehicle occupant.

20. The processor further comprises: Identifying that a vehicle equipped with the device is near a location; transferring the software application to the device in the vehicle in response to the vehicle being near; 16. The non-transitory computer-readable storage medium of claim 15, configured to:

21. receiving a request to compile a software application; identifying one or more dummy values ​​previously stored in the source code of the software application; converting the one or more dummy values ​​into source code using one or more secret values ​​stored in a data store; compiling, via a device, the source code of the software application into binary code using the secret value; A computer program that causes a processor to perform the following:

Images