System and method for authenticating electric vehicles using hardware-based identifiers

Abstract

A system and method for authenticating an electric vehicle using a hardware-based identifier is disclosed. A charging station can receive a connection request from an electric vehicle. The charging station can request a unique identifier from a NOR flash memory device in the electric vehicle. The charging station can receive the unique identifier from the electric vehicle. The charging station can transmit the unique identifier to a cloud service. The charging station can receive an authorization response from the cloud service based on verifying the unique identifier against a deny list database. The charging station can selectively enable or disable charging power to the electric vehicle based on the authorization response.

Description

[0001] Related applications

[0002] This application claims priority to Provisional U.S. Patent Application No. 63 / 760,948, filed February 20, 2025, the entire disclosure of which is hereby incorporated by reference. Technical Field

[0003] This application generally relates to electronic devices, and more specifically, to a system and method for authenticating electric vehicles using hardware-based identifiers. Background Technology

[0004] Driven by environmental concerns and technological advancements, electric vehicles (EVs) have gained a significant market share in the automotive industry. As the EV market grows, charging infrastructure has expanded to include numerous public charging stations available for any compatible vehicle. These charging stations provide both power delivery and data communication capabilities to support modern charging protocols.

[0005] Public charging stations typically require some form of authentication or payment verification before providing charging services. Common authentication methods include Radio Frequency Identifier (RFID) cards, mobile applications, or credit card payments at the charging terminal. These methods primarily focus on payment processing rather than vehicle security.

[0006] Vehicle identification has traditionally relied on physical markings, such as the U.S. Vehicle Identification Number (VIN) printed on the chassis or an external license plate. While these identifiers play an important role in vehicle registration and tracking, they are primarily physical in nature and designed for visual inspection rather than digital authentication.

[0007] NOR flash memory devices are commonly used in automotive applications due to their reliability and fast read speeds. These memory devices store firmware and configuration data required for vehicle operation. Like many electronic components, NOR flash devices incorporate various standard features to support system integration and manufacturing processes. Summary of the Invention

[0008] One aspect of this application relates to a method comprising: receiving a connection request from an electric vehicle via a charging station; requesting a unique identifier from a NOR flash memory device in the electric vehicle via the charging station; receiving the unique identifier from the electric vehicle via the charging station; transmitting the unique identifier to a cloud service via the charging station; receiving an authorization response from the cloud service via the charging station after verifying the unique identifier against a rejection list database; and selectively enabling or disabling charging power to the electric vehicle via the charging station based on the authorization response.

[0009] Another aspect of this application relates to a non-transitory computer-readable storage medium for tangibly storing computer program instructions that can be executed by a computer processor to perform the method.

[0010] Another aspect of this application relates to an apparatus configured to perform the method. Attached Figure Description

[0011] Figure 1 This is a block diagram illustrating a system for authenticating electric vehicles using memory-based identifiers according to some embodiments.

[0012] Figure 2 This is a sequence diagram illustrating a method for authenticating an electric vehicle during charging operation according to some embodiments.

[0013] Figure 3 This is a flowchart illustrating a method for reading and verifying a unique identifier (UID) from a NOR flash memory according to some embodiments.

[0014] Figure 4 This is a flowchart illustrating a method for verifying the authorization status of a vehicle using its unique identifier (UID) according to some embodiments.

[0015] Figure 5 This is a flowchart illustrating a method for registering a NOR memory UID and associating it with a vehicle during a manufacturing process, according to some embodiments.

[0016] Figure 6 This is a block diagram of a computing device according to some embodiments of the present disclosure. Detailed Implementation

[0017] In some implementations, the technology described herein relates to a method comprising: receiving a connection request from an electric vehicle via a charging station; requesting a unique identifier from a NOR flash memory device in the electric vehicle via the charging station; receiving the unique identifier from the electric vehicle via the charging station; transmitting the unique identifier to a cloud service via the charging station; receiving an authorization response from the cloud service via the charging station after verifying the unique identifier against a rejection list database; and selectively enabling or disabling charging power to the electric vehicle via the charging station based on the authorization response.

[0018] In some implementations, the techniques described herein relate to a method in which requesting the unique identifier includes sending a READ ID command to the NOR flash memory device to retrieve a device identification data structure.

[0019] In some implementations, the techniques described herein relate to a method in which receiving the unique identifier comprises: receiving a 20-byte device identification data structure; and extracting a 14-byte unique identifier from the device identification data structure.

[0020] In some implementations, the technology described herein relates to a method in which transmitting the unique identifier comprises: formatting the unique identifier according to a charging protocol; and transmitting the unique identifier and context data to the cloud service, the context data comprising one or more of a charging station identifier and a location.

[0021] In some implementations, the technology described herein relates to a method in which receiving the authorization response comprises: receiving a signed authorization token when the unique identifier is not found in the rejection list database; and receiving a rejection message and issuing an alert to the authorities when the unique identifier is found in the rejection list database.

[0022] In some implementations, the technology described herein relates to a method that further includes: caching the authorization response at the charging station for a certain time period; and using the authorization response to authorize a charging request at the charging station during the time period when a network connection to the cloud service is unavailable.

[0023] In some implementations, the technology described herein relates to a method that further includes: monitoring power delivery parameters during charging via the charging station; periodically verifying that the authorization response remains valid via the charging station; and terminating power delivery via the charging station if the authorization response becomes invalid during charging.

[0024] In some implementations, the technology described herein relates to a non-transitory computer-readable storage medium for tangibly storing computer program instructions executable by a computer processor, the computer program instructions defining the steps of: receiving a connection request from an electric vehicle via a charging station; requesting a unique identifier from a NOR flash memory device in the electric vehicle via the charging station; receiving the unique identifier from the electric vehicle via the charging station; transmitting the unique identifier to a cloud service via the charging station; receiving an authorization response from the cloud service via the charging station based on verifying the unique identifier against a rejection list database; and selectively enabling or disabling charging power to the electric vehicle via the charging station based on the authorization response.

[0025] In some implementations, the techniques described herein relate to a non-transitory computer-readable storage medium in which requesting the unique identifier includes sending a READ ID command to the NOR flash memory device to retrieve a device-identifying data structure.

[0026] In some implementations, the technology described herein relates to a non-transitory computer-readable storage medium, wherein transmitting the unique identifier includes: formatting the unique identifier according to a charging protocol; and transmitting the unique identifier and context data to the cloud service, the context data including one or more of a charging station identifier and a location.

[0027] In some implementations, the technology described herein relates to a non-transitory computer-readable storage medium, wherein receiving the authorization response comprises: receiving a signed authorization token when the unique identifier is not found in the rejection list database; and receiving a rejection message and issuing an alert to the authorities when the unique identifier is found in the rejection list database.

[0028] In some implementations, the technology described herein relates to a non-transitory computer-readable storage medium, the steps further comprising: caching the authorization response at a charging station for a certain time period; and using the authorization response to authorize a charging request at the charging station during the time period when a network connection to the cloud service is unavailable.

[0029] In some implementations, the technology described herein relates to a non-transitory computer-readable storage medium, the steps further comprising: monitoring power delivery parameters during charging via the charging station; periodically verifying that the authorization response remains valid via the charging station; and terminating power delivery via the charging station if the authorization response becomes invalid during charging.

[0030] In some implementations, the technology described herein relates to an apparatus comprising: a processor; and a storage medium thereon for tangibly storing program logic executable by the processor, the program logic comprising the steps of: receiving a connection request from an electric vehicle; requesting a unique identifier from a NOR flash memory device in the electric vehicle; receiving the unique identifier from the electric vehicle; transmitting the unique identifier to a cloud service; receiving an authorization response from the cloud service based on verification of the unique identifier against a rejection list database; and selectively enabling or disabling charging power to the electric vehicle based on the authorization response.

[0031] In some implementations, the technology described herein relates to an apparatus in which requesting the unique identifier includes sending a READ ID command to the NOR flash memory device to retrieve a device identification data structure.

[0032] In some implementations, the technology described herein relates to an apparatus in which receiving the unique identifier comprises: receiving a 20-byte device identification data structure; and extracting a 14-byte unique identifier from the device identification data structure.

[0033] In some implementations, the technology described herein relates to an apparatus in which transmitting the unique identifier includes: formatting the unique identifier according to a charging protocol; and transmitting the unique identifier and context data to the cloud service, the context data including one or more of a charging station identifier and a location.

[0034] In some implementations, the technology described herein relates to an apparatus in which receiving the authorization response comprises: receiving a signed authorization token when the unique identifier is not found in the rejection list database; and receiving a rejection message and issuing an alert to the authorities when the unique identifier is found in the rejection list database.

[0035] In some implementations, the technology described herein relates to an apparatus in which the steps further include: caching the authorization response for a certain time period; and using the authorization response to authorize a charging request when a network connection to the cloud service is unavailable during the time period.

[0036] In some implementations, the technology described herein relates to an apparatus in which the steps further include: monitoring power delivery parameters during charging; periodically verifying that the authorization response remains valid; and terminating power delivery if the authorization response becomes invalid during charging.

[0037] Figure 1 This is a block diagram illustrating a system for authenticating electric vehicles using memory-based identifiers according to some embodiments.

[0038] In the system described, electric vehicle 102 is communicatively coupled to charging station 104, which in turn communicates with cloud service 106.

[0039] Electric vehicle 102 includes several components for safety authentication. In some embodiments, NOR memory 108 stores a unique identifier (UID) that is permanently programmed during manufacturing. The UID serves as an immutable identifier for the vehicle. Vehicle MCU / ECU 110 is communicatively coupled to NOR memory 108 and can read the UID using standard memory access commands. MCU / ECU 110 controls battery system 112, which receives charging power when authorized.

[0040] Charging station 104 includes a charging port 114 that provides both power delivery to EVs and data connectivity. Charging port 114 is coupled to a control computer 116 that manages the charging operation and authentication process. Control computer 116 communicates via network interface 118 to exchange authentication data with a remote service.

[0041] Cloud service 106 provides centralized authentication capabilities through multiple coordination components. The denial list database 120 maintains records of UIDs associated with stolen or unauthorized vehicles. API service 122 provides a secure interface for querying the denial list database and processing authentication requests. Authorization service 124 makes a final determination on whether charging is permitted based on the UID verification result.

[0042] During operation, when the electric vehicle 102 connects to the charging station 104 via the charging port 114, a power and data connection is established. The control computer 116 of the charging station 104 initiates an authentication sequence by requesting a UID from the vehicle's NOR memory 108 via the MCU / ECU 110. Upon receiving the UID, the control computer 116 transmits the UID verification request to the cloud service 106 via the network interface 118.

[0043] Within cloud service 106, API service 122 receives the verification request and queries the rejection list database 120 to determine whether the UID is associated with an unauthorized vehicle. Authorization service 124 processes the database response and generates an appropriate authorization decision. This decision is then transmitted back to charging station 104 as an authorization response.

[0044] If the authorization response indicates that the UID is valid (i.e., not listed in the denial list), then charging station 104 delivers power to battery system 112 via charging port 114. However, if the UID is found in the denial list database 120, then the authorization response denies charging privileges and charging station 104 prevents power delivery to the vehicle.

[0045] The system architecture ensures secure authentication through several features. First, the UID stored in the NOR memory 108 cannot be modified or tampered with because it can be programmed during manufacturing in a one-time programmable memory area. Second, the control computer 116 of the charging station 104 must receive positive authentication before power delivery is enabled, thus preventing unauthorized access to charging resources. Finally, a cloud-based authentication service provides a centralized, continuously updated database of unauthorized UIDs that can be quickly queried during the charging process.

[0046] This system architecture provides real-time authentication for electric vehicles while leveraging existing charging infrastructure. The integration of hardware-based identifiers with connected charging stations offers a robust method for preventing unauthorized vehicles from accessing charging services. Furthermore, cloud-based services enable rapid updates to the denial-of-service database, ensuring the system can quickly respond to newly reported unauthorized vehicles.

[0047] The system is scalable to support additional features beyond basic authentication. For example, Authorization Service 124 can implement tiered access levels, allowing certain UIDs to receive limited charging capabilities instead of complete denial of service. The system can also integrate with law enforcement systems to automatically notify authorities when a listed vehicle is denied charging access.

[0048] Figure 2 This is a sequence diagram illustrating a method for authenticating an electric vehicle during charging operations according to some embodiments. The sequence illustrates the complete authentication process that occurs whenever an electric vehicle attempts to initiate a charging session at a public charging station.

[0049] The sequence diagram illustrates the interactions between three main participants: electric vehicles (“EVs”), charging stations (“CS”), and cloud services (“Cloud”). Each participant represents a system of interconnected components that work together to ensure safe and reliable charging authorization. An EV includes NOR flash memory containing a UID, an MCU / ECU for control operations, and a battery management system. A charging station includes power delivery hardware, a control computer, and network interfaces. Cloud services encompass database systems, API services, and authorization logic.

[0050] In step 202, the sequence begins when the EV connects the charging cable to the charging station. This physical connection establishes both power delivery capability and a data communication channel between the EV and the charging station. The data connection can be established using the control guide (CP) and proximity guide (PP) pins in the charging connector to establish initial communication. In some implementations, the data communication channel may utilize standard charging protocols that support bidirectional communication, such as ISO 15118 or CHAdeMO. These protocols provide standardized message formats and sequences for negotiating charging parameters and exchanging authentication data.

[0051] In step 204, upon detecting a physical connection, the charging station initiates an authentication sequence by sending a device identification request to the EV. This request prompts the EV to provide its unique identifier for verification. The request typically includes a protocol version identifier and supported authentication methods. In some implementations, the request may include a challenge-response mechanism to ensure the authenticity of the communication channel. The challenge may include a random number or a timestamp to prevent replay attacks. The charging station may also include its own identifier and capabilities in this request to support mutual authentication.

[0052] In step 206, the EV responds by transmitting its NOR UID to the charging station. This step involves several internal operations within the EV. First, the EV's MCU / ECU performs a READ ID operation on the NOR flash memory to retrieve the 14-byte UID. This operation utilizes standardized memory access commands typically implemented across NOR flash devices. The READ ID operation is an unsigned command that is typically completed in less than 1 microsecond. The UID itself consists of manufacturing data such as diffusion batch number, wafer number, die coordinates, production timestamp, and a random number to ensure uniqueness. Once retrieved, the UID is formatted according to the charging protocol specifications and transmitted to the charging station via an established data channel. In some implementations, this transmission may be encrypted using a session key established during the initial handshake.

[0053] In step 208, the charging station forwards the received UID to the cloud service for verification. This step initiates the authentication process by requesting the cloud service to verify the UID's status. The verification request typically includes contextual information such as: the charging station's unique identifier, geographic location, timestamp, session identifier, charging capabilities (power level, supported protocols), and optionally, the battery status detected by the vehicle. This additional information helps prevent fraud and enables a detailed audit trail. In some implementations, the charging station may cache recently authorized results to handle temporary network outages, but cached results will have a limited validity period.

[0054] In step 210, the cloud service performs internal validation on its denial list database. This crucial step involves querying a distributed database system that maintains records of unauthorized UIDs. The database is continuously updated with information from various sources, including law enforcement agencies, vehicle manufacturers, and charging network operators. Each database record may contain: the denial UID, the reason for the denial, the timestamp of the denial, the geographic scope of the denial, and any special handling instructions. Database queries may employ matching algorithms to handle partial UIDs or type-based denials. In some implementations, the database may also maintain an allowed list of known good UIDs or those with special access privileges.

[0055] After database verification, the sequence differs based on the UID's status. In step 212, the system determines whether the UID is denied listing, resulting in two possible execution paths. This decision point can incorporate multiple factors beyond a simple denial list status, such as regional restrictions, time-based permissions, or tiered access levels.

[0056] If the UID is not found in the rejection list database, the authorization path begins at step 214, where the cloud service sends an authorization grant message to the charging station. This message indicates that the EV has been authorized to receive charging services. The authorization message typically includes: a tamper-proof digital signature, an authorization token for the charging session, permitted charging parameters (maximum power, duration, energy), pricing information, and an expiration timestamp. In some implementations, the authorization may include specific constraints or monitoring requirements based on the vehicle's history or status.

[0057] Upon successful authorization, in step 216, the charging station initiates the charging process by delivering power to the EV. This step involves configuring the power delivery parameters of the charging port according to the EV's capabilities and any limitations specified in the authorization message. The charging station continuously monitors the power delivery and periodically verifies the status of the authorization token. The station may also collect detailed charging metrics for billing and analysis purposes.

[0058] Alternatively, if a UID is found in the rejection list database, the sequence follows the rejection path that begins at step 218. This path implements secure handling of unauthorized charging attempts and may gather intelligence about stolen or damaged vehicles. In step 220, the cloud service sends an authorization rejection message to the charging station. This message contains a rejection reason code and any special handling instructions. The rejection message is digitally signed to prevent tampering and may trigger automatic alerts to relevant stakeholders.

[0059] Upon receiving a rejection message, in step 224, the charging station refuses to initiate the charging operation and communicates this rejection to the EV. The charging station ensures that all power delivery circuits remain disabled and logs the rejection event. In some implementations, this communication may include a reason for the rejection, allowing the EV to display appropriate information to the user. The station may implement gradual delays or temporary blocking for repeated unauthorized attempts.

[0060] Optionally, in step 226, the charging station may issue an alert to the relevant authorities regarding the refusal to allow a listed vehicle to attempt charging. This notification may include comprehensive details such as: UID, timestamp, location coordinates, charging station identifier, any vehicle information collected during the session, and optionally, image captures from the station's cameras (if equipped). The alert can be routed via cloud services to appropriate law enforcement channels, enabling real-time tracking of unauthorized vehicles. Some implementations may activate nearby charging stations to create a monitoring network for tracking vehicle movement patterns.

[0061] The sequence diagram illustrates several aspects of the authentication system. First, it demonstrates how the system leverages existing charging infrastructure by utilizing the data communication capabilities of modern charging connections. Second, it shows how a hardware-based UID serves as a security identifier throughout the authentication process, providing a level of security similar to a mobile device's IMEI code. Third, it illustrates the real-time nature of the verification process, allowing for immediate response to unauthorized vehicle charging attempts while maintaining normal charging operations for authorized vehicles.

[0062] In some implementations, the sequence may include additional security measures to enhance the robustness of the authentication process. The UID transmission in step 206 may employ multiple encryption layers: session-specific encryption of the communication channel and an additional encryption layer for the UID itself. The charging station may implement a timeout mechanism that balances security and user experience—for example, allowing longer timeouts during peak network congestion periods while maintaining stricter timeouts during normal operation. The system supports multiple retries with an exponential backoff period to handle temporary communication failures with the cloud service, but the number of retries is strictly limited to prevent abuse.

[0063] The sequence can also implement various fallback mechanisms for abnormal scenarios. For example, in areas with unreliable network connectivity, charging stations can maintain a local cached copy of the rejection list database, updated periodically when connectivity becomes available. This cache will have a limited validity period and may only enable limited charging capabilities. Similarly, in emergency situations, there may be overridden protocols that allow emergency service vehicles to charge regardless of their UID state, but such overriding will require special authentication credentials and will trigger immediate logging and notifications.

[0064] In other implementations, the sequence can support tiered responses based on a list of reasons for denial. Unpaid vehicles may receive limited charging capacity (e.g., enough to reach a service center) rather than a complete denial. Vehicles recalled by the manufacturer may receive normal charging capacity but the owner will be notified of the required service. Stolen vehicles will be completely denied service and immediately trigger an official notification. This granular control allows the system to implement nuanced strategies while maintaining security.

[0065] The sequence also supports integration with vehicle manufacturer systems to enhance functionality. Manufacturers can use the UID verification process to track warranty status, push software updates, or implement recall notices. The charging session can serve as a trusted communication channel between the vehicle and manufacturer systems, enabling secure over-the-air updates and diagnostics.

[0066] Throughout the entire sequence, comprehensive logging and auditing mechanisms record every step of the process. These logs include timestamps, encrypted proof of authenticity for each message, and detailed contextual information. The logging system provides accountability and enables forensic analysis of any security incidents, while protecting user privacy through appropriate data anonymization techniques.

[0067] therefore, Figure 2 The authentication sequence described herein provides a robust, scalable, and flexible framework for ensuring electric vehicle charging operations. By leveraging the immutable nature of NOR flash UIDs combined with real-time cloud-based authentication, the system creates a highly secure yet user-friendly charging authentication mechanism that can adapt to various security requirements and operational scenarios.

[0068] Figure 3 This is a flowchart illustrating a method for reading and verifying a unique identifier (UID) from NOR flash memory according to some embodiments. The method demonstrates a detailed process for retrieving the UID, which serves as the basis for a vehicle authentication system. This process is performed within the vehicle's MCU / ECU system whenever UID verification is required for charging authentication.

[0069] In step 302, the method begins by initializing the READ ID command. This initialization involves preparing a standardized sequence of commands identifiable by the NOR flash memory device. The READ ID operation is an unsigned command supported across different NOR memory manufacturers, ensuring broad compatibility. Command initialization includes setting the appropriate opcode (e.g., 0x9F for the READ ID operation), preparing the memory bus for operation, and configuring any necessary timing parameters. The initialization process also includes setting the appropriate chip select signal in the case of multiple memory devices on the same bus.

[0070] In step 304, an initialization command is sent to the NOR memory device. Command transmission is performed via the memory bus interface, typically using the standard SPI or Quad-SPI protocol. For SPI mode, this involves managing the serial clock (SCK), chip select (CS), data input (DI), and data output (DO) signals according to the memory device's specifications. In Quad-SPI mode, commands utilize four data lines for higher throughput. In some implementations, this step includes appropriate timing management to ensure reliable command transmission according to the memory device's specifications. Commands are transmitted using the memory device's native command protocol, which can operate at frequencies up to several hundred megahertz.

[0071] In step 306, the method reads 20 bytes of device ID data from memory. This data is stored in a dedicated one-time programmable (OTP) array outside the main memory array to ensure its immutability. The 20-byte sequence contains complete device identification information, including: manufacturer ID (1 byte), memory type (1 byte), memory capacity (1 byte), remaining ID length (1 byte), extended device information (1 byte), device configuration (1 byte), and unique identifier data (14 bytes). In some implementations, this read operation is completed in less than 1 microsecond, making it highly efficient for real-time authentication scenarios. The read operation includes built-in error detection to ensure data integrity during transmission via the memory bus.

[0072] In step 308, the method extracts the last 14 bytes from the device ID data to obtain the UID. These bytes contain custom factory data that ensures uniqueness across all manufacturing devices. The UID includes several elements: diffusion batch number (4 bytes), wafer number (1 byte), die XY coordinates (2 bytes each), production timestamp (3 bytes), and an additional random value (2 bytes). This combination of manufacturing data and random elements ensures that no two devices share the same UID. The extraction process includes byte alignment checks to ensure proper data boundaries are maintained.

[0073] In step 310, the extracted UID is formatted for transmission according to the requirements of the charging protocol. This formatting may include: byte order adjustment (e.g., conversion between big-endian and little-endian representations), checksum calculation using CRC-32 or a similar algorithm, adding protocol-specific headers or footers, and preparing any necessary metadata (e.g., timestamps or serial numbers). In some implementations, the formatting step may also include encrypting the UID data to protect it during transmission. Formatting ensures that the UID data will be correctly interpreted by the charging station's control system.

[0074] In step 312, the method verifies the formatted UID to ensure its integrity. This verification step includes several checks: verifying that the UID length is exactly 14 bytes, confirming that all bytes contain valid values ​​within the expected range, verifying any internal consistency flags, verifying checksums or error detection codes, and verifying that the manufacturer ID and device type fields match the expected values. Verification also ensures that no bytes remain at fixed values ​​(all 0s or all 1s), which could indicate a hardware failure. Some implementations may also verify that the production timestamp falls within the valid manufacturing date range.

[0075] If verification is successful, the method proceeds to step 314, where the verified UID is returned to the charging control system. The return value contains the formatted UID along with any required metadata or status information. This metadata may include a verification timestamp, the number of retries required (if any), and memory device status information. The UID is then cached in volatile memory for potential reuse during the same charging session, thereby reducing the need for repeated reads from the NOR device.

[0076] If verification fails, the method proceeds to step 316, whereby the method reports an appropriate error condition. The error report contains detailed information about the nature of the verification failure, such as invalid length, checksum mismatch, formatting error, or timing violation. Error data includes diagnostic information, such as the original device ID data, the specific verification check that failed, and any relevant system status information. In some implementations, error handling may include retry attempts for transient failures or logging of persistent errors for diagnostic purposes. Critical errors may trigger a system notification to the vehicle's diagnostic systems.

[0077] Figure 3 The method described herein illustrates several aspects of the UID retrieval process. First, it demonstrates how the system utilizes standard NOR memory commands to access the UID, thereby ensuring compatibility across different memory devices. Second, it explains multiple verification steps to ensure the integrity of the UID before it is used for authentication. Finally, it demonstrates how the process can be optimized to improve performance while maintaining reliability through comprehensive error checking and handling mechanisms.

[0078] Figure 4 This is a flowchart illustrating a method for verifying the authorization status of a vehicle using its unique identifier (UID) according to some embodiments. The method is executed within a cloud service infrastructure and implements a complete verification workflow from an initial UID to a final authorization decision. This verification process is designed to provide fast and reliable authentication while maintaining security and supporting various authorization policies.

[0079] In step 402, the method begins when the cloud service receives the UID from the charging station. The received data encapsulation typically includes a 14-byte UID along with contextual information such as the charging station identifier, timestamp, geographic location, session parameters, power level requirements, and initial battery state information. This data arrives via a secure API endpoint implementing TLS 1.3 encryption and client certificate authentication. This endpoint is load-balanced across multiple zones to ensure high availability and low latency response.

[0080] In step 404, the method verifies the format of the received UID. This verification includes verifying that the UID length is exactly 14 bytes, checking that the byte format matches the expected manufacturing format, verifying the checksum, and ensuring that all required context data is present and properly formatted. The verification process also verifies that the charging station's credentials are up-to-date, that the request complies with the API rate-limiting policy, and that the timestamp is within acceptable synchronization limits. The method implements error detection to identify potential tampering or data corruption during transmission.

[0081] If verification fails, the method proceeds to step 406, whereby the method generates an error response and returns it to the charging station. The error response includes a specific error code mapped to each verification check, detailed diagnostic information about the failure, and suggested corrective actions. The method also uses context data to log verification failures for security analysis. The method then terminates, requesting the charging station to retry with valid data if necessary. Multiple consecutive verification failures from the same charging station may trigger additional security measures.

[0082] If verification is successful, the method proceeds to step 408, whereby the method queries the rejection list database. This query operation is optimized using database indexes and a multi-level caching strategy to ensure fast response times, typically below 50 milliseconds. Depending on the deployment architecture, the query may span multiple database fragments or zones and has automatic failover capabilities. The database implementation includes a caching hierarchy of local memory caches, distributed caches, and persistent storage. In some implementations, the query includes fuzzy matching capabilities to capture subtle changes in the UID representation or detect type-based fraud attempts.

[0083] In step 410, the method evaluates whether a UID exists in the rejection list database. This validation considers not only exact matches but also type-based rules that may indicate a range of UIDs or a specific manufacturing batch. The evaluation includes verifying the time validity of any rejection list entry, as some entries may have expiration dates or time-based restrictions. The validation also considers geographical restrictions that may limit rejection list enforcement to specific regions or jurisdictions.

[0084] If a UID is denied listing, the method follows a denial path that begins at step 412, whereby the method marks the UID as denied listing in the current session context. This flag contains details about which denial list rule was triggered, the original denial listing date, the organization requesting the denial listing, and any associated metadata regarding the reason for the denial listing. The flag may also contain special handling instructions based on the denial listing type. In step 414, the method logs a verification event with full context for auditing purposes, including all request parameters, matching denial list rules, and timing information.

[0085] Next, the method proceeds to step 416, whereby the method notifies relevant agencies based on a list of reasons for the refusal. These notifications can be routed to law enforcement agencies, vehicle manufacturers, or other stakeholders through various channels, including REST APIs, message queues, email alerts, or integration with emergency response systems. The notification includes the vehicle's current location, timestamp, charging station details, and historical charging attempts (if available). In step 418, the method generates an authorization refusal response and returns it to the charging station, containing any specific handling instructions or user messages.

[0086] If the UID is not rejected for listing, the method checks in step 420 whether additional verification is required. Additional verification may be triggered by factors such as geographic location, time of day, specific security protocols, or risk scores calculated from historical charging patterns. These verifications provide additional security for high-risk scenarios or advanced charging locations.

[0087] If additional verification is required, the method proceeds to step 422, where supplementary verifications are performed. These may include verifying the UID against the manufacturer's database, verifying recent suspicious activity patterns, verifying regional authorization requirements, performing real-time risk assessments, or verifying payment pre-authorization. Each verification has a configurable timeout period and rollback policy. The results of these verifications are evaluated in step 424 using configurable policy rules.

[0088] If the additional verification fails, the method logs the failure details in step 426 before proceeding to authorization denial. This log entry contains specific verification failure information, time-series data, and policy evaluation details to support later analysis and policy refinement. The logged data is fed into a machine learning model that continuously improves the risk assessment system.

[0089] If the additional verification passes, or if no additional verification is required, the method proceeds to step 428. Here, the method generates an authorization token for the charging session. This token contains a cryptographic signature using an HSM-supported key, a validity timeframe, maximum power level, energy limit, and any special monitoring requirements. The token may also contain parameters for tiered access or emergency overdrive.

[0090] In step 430, successful authorization is fully logged for auditing purposes and performance monitoring. The log includes complete request details, processing timestamps, all authorization decisions, and any special conditions applied. These logs are fed into an analytics system that tracks authorization patterns and system performance.

[0091] Finally, in step 432, the method returns an authorization grant response to the charging station. This response contains a signed authorization token, session parameters, charging limits, and any specific instructions for the charging session. The charging station can then continue power delivery based on the authorization parameters.

[0092] Throughout this process, the method implements various optimization techniques, such as caching frequently accessed rejection list entries, parallel processing of additional checks, and asynchronous notification handling. The method also maintains a comprehensive log of the security audit trail and implements appropriate data retention and privacy protection measures consistent with regional data protection regulations.

[0093] Figure 5 This is a flowchart illustrating a method, according to some embodiments, for registering a NOR memory UID and associating it with a vehicle during the manufacturing process. This registration process ensures that each vehicle has a properly recorded and verified unique identifier before leaving the manufacturing plant.

[0094] In step 502, the method begins by reading the UID from the NOR flash memory device after it has been soldered to the vehicle's control board. This read operation is performed using an automated test apparatus (ATE) that interfaces with the board via a test point or boundary scan chain. The read operation uses the standard READ ID command supported by the NOR device and retrieves the complete 20-byte device identification data. The test apparatus verifies that the read operation was successfully completed and that all data bits were properly captured.

[0095] In step 504, the method verifies the uniqueness of the extracted 14-byte UID portion of the device ID. This verification process queries a manufacturing database that maintains records of all UIDs used in production. Verification not only ensures that the UID has never been used before, but also ensures that it conforms to the expected format based on manufacturing data: correct batch number format, valid wafer coordinates, and a reasonable timestamp value. Verification also checks that the random portion of the UID maintains sufficient entropy.

[0096] If uniqueness verification fails, the method proceeds to step 508, whereby a detailed error report is logged. The error report includes: duplicate or invalid UIDs, current vehicle production information, any conflicting vehicle records, detailed test conditions, and equipment identification data. This error triggers a manufacturing halt requiring a quality control investigation before vehicle production can continue. The error may also initiate analysis of the NOR memory programming process to identify any systemic problems.

[0097] If the uniqueness verification passes, the method proceeds to step 506, whereby the verified UID is stored in the vehicle's manufacturing records. These records are maintained in a Safety Manufacturing Execution System (MES) database and contain comprehensive production data, such as assembly dates, production line identifiers, test results, component serial numbers, and quality control checkpoints. The UID becomes part of the vehicle's permanent manufacturing history.

[0098] In step 510, the method associates the verified UID with the vehicle's core identity information. This association includes linking the UID to basic vehicle data, such as the Vehicle Identification Number (VIN), model information, production configuration, and initial owner data (if available). The association process creates an encrypted signature record that binds the UID to the vehicle identity, thereby preventing unauthorized modification of these associations.

[0099] In step 512, the method registers the UID and its associations in a secure database system that will serve as an authoritative source for vehicle authentication. This registration involves creating multiple database records, including, but not limited to, a primary UID record containing the original identifier and its verification history, a vehicle association record linking the UID to a vehicle identifier, an authentication policy record specifying any initial restrictions or special handling requirements, and an audit trail documenting the registration process. In some implementations, the database implements a strong consistency model to prevent race conditions during registration and maintains geographically distributed copies for high availability.

[0100] The registration process incorporates several security features. First, all database transactions are cryptographically signed using a Hardware Security Module (HSM) to ensure authenticity. Second, registration uses append-only logs to create an immutable audit trail. Third, the system implements access controls that restrict which manufacturing systems can create or modify UID registrations.

[0101] Throughout the registration process, the method maintains a detailed log of each operation. These logs capture timing information, system status, operator identification (if manual intervention is required), and cryptographic proof of each transaction. These logs are crucial for quality control, security auditing, and regulatory compliance.

[0102] The method supports several manufacturing scenarios. In normal production, the process is fully automated and integrated with the manufacturing execution system of the vehicle assembly line. However, the method also supports manual registration processes for parts replacement or service operations, but these require additional authentication and documentation.

[0103] Error handling is particularly robust because registration failures can impact production line efficiency. The method implements retry mechanisms for transient failures, rollback processes for system interruptions, and explicit escalation paths for situations requiring human intervention. Each error condition is categorized and tracked to identify systemic problems in the registration process.

[0104] This registration method ensures that each vehicle has a properly verified and securely documented UID when it enters service, thus laying the foundation for a vehicle authentication system. The comprehensive verification, association, and registration pathways of this method create a trustworthy vehicle identity that can be reliably used for charging authentication and other safety-related operations throughout the vehicle's entire lifespan.

[0105] Figure 6 This is a block diagram of a computing device according to some embodiments of the present disclosure.

[0106] As described, device 600 includes a processor or central processing unit (CPU), such as CPU 602, that communicates with memory 604 via bus 614. The device also includes one or more input / output (I / O) or peripheral devices 612. Examples of peripheral devices include, but are not limited to, network interfaces, audio interfaces, display devices, keypads, mice, keyboards, touchscreens, illuminators, haptic interfaces, GPS receivers, cameras, or other optical, thermal, or electromagnetic sensors.

[0107] In some embodiments, CPU 602 may include a general-purpose CPU. CPU 602 may include a single-core or multi-core CPU. CPU 602 may include a system-on-a-chip (SoC) or a similar embedded system. In some embodiments, a graphics processing unit (GPU) may be used in place of CPU 602, or in combination with CPU 602. Memory 604 may include a memory system comprising dynamic random access memory (DRAM), static random access memory (SRAM), flash memory (e.g., NAND flash memory), or combinations thereof. In one embodiment, bus 614 may include a peripheral component interconnect (PCIe) bus. In some embodiments, bus 614 may include multiple buses instead of a single bus.

[0108] Memory 604 describes an example of a non-transitory computer storage medium used to store information such as computer-readable instructions, data structures, program modules, or other data. Memory 604 may store the Basic Input / Output System (BIOS) in read-only memory (ROM) (e.g., ROM 608) for low-level operation of the control device. The memory may also store the operating system in random access memory (RAM) for operation of the control device.

[0109] Application 610 may include computer-executable instructions that, when executed by a device, perform any of the methods (or portions thereof) previously described in the preceding figures. In some embodiments, software or programs implementing the method embodiments may be read from a hard disk drive (not shown) and temporarily stored in RAM 606 by CPU 602. Then, CPU 602 may read the software or data from RAM 606, process it, and again store it in RAM 606.

[0110] The device may optionally communicate with a base station (not shown) or directly with another computing device. One or more network interfaces in peripheral device 612 are sometimes referred to as transceivers, transceiver devices, or network interface cards (NICs).

[0111] The audio interface in peripheral device 612 generates and receives audio signals, such as human speech. For example, the audio interface may be coupled to a speaker and microphone (not shown) to enable remote communication with other devices or to generate audio confirmation of an action. The display in peripheral device 612 may include a liquid crystal display (LCD), a gas plasma display, a light-emitting diode (LED), or any other type of display device used with a computing device. The display may also include a touch-sensitive screen arranged to receive input from an object such as a stylus pen or numbers from a human hand.

[0112] The keypad in peripheral device 612 may include any input device arranged to receive input from a user. Illuminators in peripheral device 612 may provide status indication or provide light. The device may also include an input / output interface in peripheral device 612 that communicates with external devices using communication technologies such as USB, infrared, Bluetooth®, or similar. A haptic interface in peripheral device 612 provides haptic feedback to the user of the client device.

[0113] The GPS receiver in peripheral device 612 determines the physical coordinates of the device on the Earth's surface, typically outputting the location as latitude and longitude values. The GPS receiver may also employ other geolocation mechanisms (including, but not limited to, triangulation, assisted GPS (AGPS), E-OTD, CI, SAI, ETA, BSS, or the like) to further determine the device's physical location on the Earth's surface. However, in one embodiment, the device may communicate with other components to provide additional information that can be used to determine the device's physical location, including, for example, a Media Access Control (MAC) address, an Internet Protocol (IP) address, or the like.

[0114] Depending on the deployment or use of the device, it may contain more or fewer components than those shown. For example, a server computing device (such as a rack server) may not include an audio interface, display, keypad, lighting, haptic interface, GPS receiver, or camera / sensor. Some devices may include additional components not shown, such as a graphics processing unit (GPU), cryptographic coprocessor, artificial intelligence (AI) accelerator, or other peripherals.

[0115] However, the subject matter disclosed above can be embodied in various different forms, and therefore, the subject matter covered or claimed is intended to be construed as not being limited to any of the exemplary embodiments set forth herein; exemplary embodiments are provided merely for illustrative purposes. Similarly, a reasonably broad scope of the subject matter claimed or covered is intended. Furthermore, the subject matter can be embodied, for example, as a method, apparatus, component, or system. Thus, embodiments can be exemplified as hardware, software, firmware, or any combination thereof (other than software itself). Therefore, the foregoing detailed description is not intended to be interpreted in a limiting sense.

[0116] Throughout this specification and claims, terms may have subtle meanings beyond their expressly defined meanings, which may be suggested or implied in the context. Similarly, the phrase "in an embodiment" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment" as used herein does not necessarily refer to different embodiments. For example, the claimed subject matter is intended to encompass combinations of all or some of the exemplary embodiments.

[0117] Generally, terms can be understood at least in part from their usage in the context. For example, terms such as “and,” “or,” or “and / or,” as used herein, can contain a variety of meanings that can depend at least in part on the context in which such terms are used. Typically, if “or” is used in an associative list (e.g., A, B, or C), then it is intended to mean A, B, and C (used herein in an inclusive sense), and A, B, or C (used herein in an exclusive sense). Additionally, as used herein, depending at least in part on the context, the term “one or more” can be used to describe any feature, structure, or characteristic in a singular sense or to describe a combination of features, structures, or characteristics in a plural sense. Similarly, depending at least in part on the context, terms such as “a,” “an,” or “described” can again be understood to convey either a singular or a plural usage. Furthermore, again depending at least in part on the context, the term “based on” can be understood to not necessarily convey an exclusive set of factors, but may allow for the presence of additional factors that are not necessarily explicitly described.

[0118] This disclosure is described with reference to block diagrams and operating instructions of methods and apparatus. It should be understood that each block of the block diagram or operating instruction, and combinations of blocks in the block diagram or operating instruction, can be implemented by analog or digital hardware and computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer to modify its functionality as detailed herein, a special-purpose computer, an application-specific integrated circuit (ASIC), or other programmable data processing apparatus, such that the instructions, executed via a processor of the computer or other programmable data processing apparatus, implement the function / action specified in the block diagram or operating block or several operating blocks. In some alternative embodiments, the functions or actions indicated in the blocks may not appear in the order indicated in the operating instructions. For example, depending on the functionality or action involved, two blocks shown consecutively may be performed substantially simultaneously, or sometimes the blocks may be performed in reverse order.

Claims

1. A method comprising: Receive connection requests from electric vehicles via charging stations; The charging station requests a unique identifier from the NOR flash memory device in the electric vehicle. The unique identifier is received from the electric vehicle via the charging station; The unique identifier is transmitted to the cloud service via the charging station; The charging station receives an authorization response from the cloud service by verifying the unique identifier against a rejection list database. and The charging station selectively enables or disables charging power to the electric vehicle based on the authorized response.

2. The method of claim 1, wherein requesting the unique identifier includes sending a READ ID command to the NOR flash memory device to retrieve a device-identifying data structure.

3. The method of claim 2, wherein receiving the unique identifier comprises: Receive 20 bytes of device identification data structure; and Extract a 14-byte unique identifier from the device's identification data structure.

4. The method of claim 1, wherein transmitting the unique identifier comprises: The unique identifier is formatted according to the charging protocol; and The unique identifier and context data are transmitted to the cloud service, wherein the context data includes one or more of the charging station identifier and location.

5. The method of claim 1, wherein receiving the authorization response comprises: Receive a signed authorization token if the unique identifier is not found in the rejection list database; and When the unique identifier is found in the rejection list database, a rejection message is received and an alert is sent to the authorities.

6. The method of claim 1, further comprising: The charging station caches the authorization response at high speed for a certain period of time. and During the time period, when the network connection to the cloud service is unavailable at the charging station, the authorization response is used to authorize the charging request.

7. The method of claim 1, further comprising: The power delivery parameters are monitored during charging at the charging station. The authorization response is periodically verified to remain valid through the charging station. and If the authorization response becomes invalid during charging, then power delivery is terminated through the charging station.

8. The method of claim 1, wherein the authorization response includes tiered access authorization granting limited charging capability based on reason codes in the denial list database.

9. A non-transitory computer-readable storage medium for tangibly storing computer program instructions executable by a computer processor to perform the method according to claims 1 to 8.

10. An apparatus configured to perform the method according to claims 1 to 8.

Images