A method and system for carbon activity measurement and auditable credit issuance based on vehicle-mounted trusted evidence chain, and a storage medium (vehicle-mounted trusted carbon activity measurement and auditable credit issuance)

Abstract

This invention discloses a reliable carbon activity measurement and credit issuance scheme for vehicle carbon rights confirmation. The onboard terminal collects one or more carbon activity-related data points according to time or mileage windows, including mileage, fuel consumption, estimated fuel injection, engine operating status, battery state of charge, charging amount, discharging amount, regenerative energy, or idling time. A carbon activity window summary is generated and bound to vehicle category identifier, metering version, emission factor version, monotonic counter reference information, and chain reference information, and then integrity protection is performed to form a carbon activity certificate. The server first performs signature verification, continuity verification, and joint review of vehicle category adaptation, metering version validity, and emission factor version availability on the carbon activity certificate. Then, based on the vehicle category identifier, metering version, and emission factor version, carbon rights conversion is performed. Credit confirmation receipts are issued only when the reliability threshold is met and there is no duplicate confirmation, thereby suppressing forgery, duplicate applications, and offline re-transmission of duplicate issuances, and improving the reproducibility and auditability of the conversion results.

Description

Technical Field

[0001] This invention relates to the fields of vehicle networking, trusted metering, carbon rights digitization, and distributed ledger collaboration, and in particular to a method, system, and storage medium for carbon activity metering and auditable credit issuance based on an in-vehicle trusted evidence chain. Background Technology

[0002] In green travel, low-carbon incentives, insurance pricing, automaker user operations, local low-carbon policies, and carbon credit projects, an increasing number of businesses are seeking to issue carbon credits, green benefits, subsidy eligibility, or equivalent incentives to vehicle owners based on actual vehicle operating behavior. Unlike ordinary internet businesses, the establishment of vehicle carbon credits highly depends on real-world operating data, including mileage, fuel consumption, energy consumption, engine running time, charging volume, and regenerative braking energy. If these fundamental data lack reliable sources, subsequent credit confirmation, benefit issuance, dispute review, and distributed transfer will all lack a technological foundation.

[0003] In existing solutions, the common implementation paths mainly fall into the following categories: 1. Relying solely on mobile device location tracking, manually entered mileage, manually entered charging amount, or uploaded receipt screenshots to create low-carbon behavior records. While this method is simple to deploy, it makes it difficult to prove whether the activities actually occurred and also fails to prevent supplementary entries, falsification, and duplicate submissions.

[0004] 2. Calculate points according to business rules only after aggregating vehicle historical data in the cloud. While this approach facilitates unified processing on the platform side, the basic vehicle data lacks reliable protection before uploading, and cannot effectively prevent tampering with intermediate boxes, historical replay, offline batch forgery, or duplicate claims across accounts.

[0005] 3. Directly using carbon credit trading platforms, smart contracts, or on-chain account systems as innovation centers. While these solutions demonstrate strong business acumen, they easily reduce technical issues to trading or financial rules, which is detrimental to patent stability and fails to answer core technical questions such as "on what grounds are carbon rights established and why can't they be claimed repeatedly?"

[0006] Furthermore, vehicle type, energy type, and regulatory scope naturally differ. The measurement fields and emission factors for gasoline-powered vehicles, hybrid vehicles, plug-in hybrid vehicles, and pure electric vehicles are not the same; conversion factors may also be updated under different regions, time periods, and regulatory plans. If the carbon activity certificate does not link the vehicle category, measurement scope version, and emission factor version, the original conversion logic cannot be reconstructed, and dispute audits will be difficult to conduct.

[0007] Therefore, a carbon activity measurement and credit issuance scheme based on a vehicle-mounted trusted evidence chain is needed, so that the establishment of carbon rights depends on trusted activity certificates, versioned conversion and idempotent issuance, rather than on simple platform reporting rules or trading rules. Summary of the Invention

[0008] The purpose of this invention is to provide a carbon activity measurement and auditable points issuance scheme based on a vehicle-mounted trusted evidence chain, in order to solve the problems in the prior art where carbon activity data is easy to forge, easy to re-transmit and duplicate, difficult to trace vehicle category and conversion method, and lack of a credible threshold for points issuance.

[0009] More specifically, the present invention aims to achieve the following objectives: 1. Generate carbon activity certificates at the vehicle end that can be continuously sealed, reissued, and verified, and can be reconstructed by associating with vehicle category identifier, metering caliber version identifier, and emission factor version identifier; 2. Enable the server to first complete vehicle category adaptation and version validity judgment, and then reconstruct the original conversion logic based on vehicle category identifier, metering caliber version identifier and emission factor version identifier; 3. Suppress duplicate confirmations and duplicate issuances within the same active window using idempotent flags; 4. Maintain a consistent audit process across scenarios including offline data transfer, missing fields, data freeze pending review, governance revocation, and historical data reconstruction; 5. To provide a credible entry point for subsequent carbon rights transfers, subsidy disbursements, insurance discounts, or local project settlements.

[0010] IV. Inventive Concept The core concept of this invention is not "designing a carbon credit trading platform," but rather: an in-vehicle terminal generates a carbon activity window summary based on a time window or mileage window, and generates carbon activity certificates through a secure component or trusted chain of evidence; a server first determines the set of vehicle category adaptation fields and the selection boundary of the conversion template based on the vehicle category identifier, then determines the window interpretation, quantification accuracy, and anomaly downgrade rules based on the metering caliber version identifier, and determines the applicable factor set based on the emission factor version identifier, thereby performing a verifiable conversion on the carbon activity certificate; a credit confirmation receipt is issued only if the certificate is credible and has not been repeatedly confirmed; and a unified idempotency and auditing mechanism is maintained in scenarios such as offline re-transmission, conflicting certificates, rule upgrades, and dispute revocation.

[0011] In some embodiments, the present invention does not require a trading market, price matching, or token mechanism as prerequisites for its existence. Even without any trading platform, the present invention can still stand independently as long as there is a need for confirmation of rights based on real vehicle carbon activities.

[0012] In other words, the focus of this invention is not on "how the points account is transferred", but on "how the vehicle-side carbon activity forms a credible measurement certificate, how the server completes the reconstructable conversion based on the vehicle category and the dual version caliber, and makes a technical judgment on whether to issue a points confirmation receipt accordingly". Attached Figure Description

[0013] Figure 1 A schematic diagram of the overall structure for the collaborative execution of carbon activity measurement and credit issuance by vehicle-mounted terminals, mobile terminals, and servers.

[0014] Figure 2 This is a schematic diagram of the carbon activity window summary and carbon activity certificate generation process.

[0015] Figure 3 This is a schematic diagram of the server-side version verification, conversion, and points confirmation receipt issuance process.

[0016] Figure 4 This is a schematic diagram of the offline archiving, batch resending, and idempotent deduplication process.

[0017] Figure 5 A schematic diagram illustrating the process of freezing pending review, revoking governance, and historical reconstruction.

[0018] VI. System Structure like Figure 1 As shown, in one embodiment, the system includes: 1. In-vehicle terminal, used to collect data related to vehicle carbon activities, generate carbon activity window summaries, and form carbon activity vouchers; 2. Server, used to perform verification, review, conversion, idempotent deduplication, and issuance of points confirmation receipts for carbon activity vouchers; 3. Optional mobile terminal for providing supplementary witnessing materials for time, proximity, location summary, refueling event, or charging event within the connection window.

[0019] The preferred vehicle-mounted terminal includes: 1. Vehicle bus interface, used to collect mileage, vehicle speed, RPM, battery status or other operating fields from the vehicle bus; 2. Processor, used to perform window construction, normalization encoding, credential generation, and archive control; 3. Memory for locally appending and writing sealed carbon activity certificates and interim summaries; 4. Security components, used to provide protected keys and perform integrity protection operations; 5. Optional short-range communication module for exchanging auxiliary witness references with the mobile terminal within the connection window.

[0020] Preferred server options include: 1. Receiving module, used to receive carbon activity certificates, supplementary transmission records, and optional supporting witness materials; 2. The verification module is used to perform signature verification, field integrity checks, and chain continuity checks; 3. The review module is used to perform vehicle category adaptation, version adaptation, consistency checks, and anomaly detection; 4. Conversion module, used to calculate carbon credit results based on the measurement caliber version identifier and emission factor version identifier; 5. Issuance module, used to output points confirmation receipts, idempotent receipts, freeze pending review requests, or supplementary certificate requests.

[0021] VII. Carbon Activity-Related Data and Vehicle Category Adaptation In some embodiments, carbon activity-related data may include at least one or more of the following: 1. Mileage, mileage increment, vehicle speed, engine speed, and engine running time; 2. Fuel rate, estimated injection quantity, injection pulse width, and estimated mass airflow rate; 3. Battery state of charge, battery current, battery voltage, charge amount, discharge amount, and regenerative braking energy; 4. Idle time, operating condition classification information, anomaly markers, and missing bitmaps; 5. Optional connection window references, auxiliary witness references, phase anchor references, and region identifier references.

[0022] In some embodiments, different vehicle types require different fields. For example, gasoline vehicles may prioritize fuel rate, fuel injection estimate, and engine run time; pure electric vehicles may prioritize battery current, battery voltage, SOC change, and charge amount; and plug-in hybrid vehicles may use both fuel consumption-related fields and energy consumption-related fields.

[0023] VIII. Construction of the Carbon Activity Window 8.1 Window Definition The vehicle-mounted terminal preferably summarizes carbon activity-related data according to a preset time window, preset mileage window, or preset event window. The window can be a fixed-duration window or an adaptive window triggered by mileage increments. The selection of the window boundaries is determined by the metering caliber version identifier.

[0024] 8.2 Window Summary Binding Fields In some embodiments, the carbon activity window summary is bound to at least several of the following fields: 1. window_id; 2. vehicle_class_id; 3. calc_spec_ver; 4. factor_ver; 5. counter_ref; 6. chain_ref; 7. field_bitmap; 8. anchor_ref; 9. region_id; 10. energy_type_ref or event_type_ref.

[0025] In some embodiments, normalized coding defines at least the following: 1. Field order; 2. Field units and quantization precision; 3. Timestamp representation method; 4. Representation of missing fields; 5. Value table for Boolean and enumeration flags; 6. How to reference the mapping table between vehicle categories and energy types.

[0026] The above-mentioned standardized encoding can reduce the problem of inconsistent summaries caused by differences in implementation across different terminals.

[0027] IX. Generation of Carbon Activity Certificates like Figure 2 As shown, after the vehicle terminal performs normalized encoding on the carbon activity window digest, it calls a security component to perform an integrity protection operation on the encoding result or its digest to generate a carbon activity credential. The integrity protection operation can be a digital signature, a message authentication code, or an equivalent protected digest operation.

[0028] In some embodiments, the vehicle terminal locally stores carbon activity certificates using an append-only write method. The advantages of append-only writing are: 1. It can reduce the risk of historical records being overwritten; 2. Can continuously accumulate reissueable vouchers under conditions of disconnection, weak network, or delayed connection; 3. Facilitates the reconstruction of continuity on the server side based on chained references.

[0029] In some embodiments, the vehicle terminal may also generate phased summary summaries in stages and perform integrity protection operations on the phased summary summaries to form phase-anchored credentials, thereby enhancing the auditability of batch reissue after long-term offline status.

[0030] 10. Construction of Idempotency Symbols To prevent duplicate applications and issuances, it is preferable to construct an idempotent identifier for each carbon activity certificate. The idempotent identifier can be calculated deterministically by encoding at least three of the following: 1. The normalized coding result of the carbon activity window summary or its summary; 2. Vehicle category identification; 3. Measurement caliber version identification; 4. Emission factor version identifier; 5. Monotonic counter reference information; 6. Window icon; 7. Stage anchoring reference information.

[0031] In this way, even if the vehicle terminal repeatedly reports the same window after going offline, the server can determine it as a duplicate retransmission of the same active window, rather than a new issuance request.

[0032] XI. Server Verification and Conversion like Figure 3 As shown, after receiving the carbon activity certificate, the server preferably executes the following steps in sequence: 1. Verification of signatures and field integrity checks; 2. Chain continuity check; 3. Vehicle category compatibility check; 4. Verification of the validity of the measurement caliber version; 5. Emission factor version availability check; 6. Optional auxiliary witness material consistency check; 7. Idempotency check; 8. After approval, perform carbon credit conversion and issue a credit confirmation receipt.

[0033] In some embodiments, the server conversion does not directly apply a uniform rule to any active window, but instead uses vehicle_class_id, calc_spec_ver, and factor_ver to jointly determine the conversion context. The server only enters the credit confirmation receipt issuance path when the conditions of vehicle category adaptation, valid metering caliber, and available emission factor version are all met simultaneously.

[0034] 11.1 Vehicle Category Compatibility Check Server optimization judgment: 1. Does the current set of fields apply to the vehicle category? 2. Is the "pure electric" field being used incorrectly in the context of gasoline-powered vehicles? 3. Is the fuel consumption field incorrectly used for pure electric vehicles? 4. Does the plug-in hybrid vehicle model omit one of the energy-side field sets?

[0035] 11.2 Inspection of Measurement Calibration Version and Emission Factor Version The server preferentially selects the appropriate conversion rule based on calc_spec_ver and factor_ver. Different versions may correspond to the following: 1. Different quantization precision; 2. Different anomaly degradation rules; 3. Different energy factors; 4. Carbon conversion baselines under different jurisdictions or regulatory projects.

[0036] In some embodiments, the set of emission factors corresponding to `factor_ver` is not limited to static single-value factors, but can also correspond to time-segmented factor sets subdivided by time interval, dynamic intensity factor sets subdivided by regional power grid status, or parameter package sets issued according to regulatory project standards. For carbon activity windows with charging events, discharging events, grid connection response events, or other time-related events, the server can further select the corresponding sub-factor set from the parameter package referenced by `factor_ver` for conversion based on the time interval identifier, regional identifier, energy type identifier, or event type identifier corresponding to the activity window, thereby improving the accuracy of reconstructing carbon activity results under different time periods, regions, and energy structures.

[0037] 11.3 Consistency check of supporting witnessing materials In some embodiments, if supplementary witnessing materials generated by the mobile terminal within the connection window exist, the server may also perform a consistency review based on one or more of the following: time reference, proximity contact information, refueling event witnessing, charging event witnessing, or location summary. These supplementary witnessing materials are only used to enhance credibility or resolve disputes and are not a necessary prerequisite for the establishment of carbon activity certificates.

[0038] 11.4 Carbon Credit Conversion Process In some embodiments, after passing signature verification, continuity checks, and compatibility checks, the server performs carbon credit conversion according to the following process: 1. Read the vehicle class identifier (vehicle_class_id) to determine whether the vehicle belongs to a gasoline vehicle, hybrid vehicle, plug-in hybrid vehicle, pure electric vehicle, or other preset categories; 2. Read calc_spec_ver to determine the field caliber, quantization precision, anomaly degradation rules, and window interpretation rules used in this activity window; 3. Read factor_ver and determine the corresponding emission factor set based on region_id, policy_id, energy type identifier, and time interval identifier; 4. Recover the minimum set of fields used for the conversion from the carbon activity window summary; 5. Perform degradation processing, interpolation prohibition processing, or direct rejection processing on missing fields; 6. Calculate carbon equity results based on the conversion template corresponding to the vehicle category; 7. Write the conversion result, conversion version reference, idempotency status, and issuance status together into the confirmation record.

[0039] In some embodiments, the conversion result may not directly represent the tradable points value, but may also be: 1. Estimated emission reductions; 2. Green behavior confirmation value; 3. The underlying equity value awaiting the second settlement; 4. Intermediate confirmation quantity for secondary mapping by upper-level business systems only.

[0040] By fixing the conversion process "after the voucher is established", this invention can be distinguished from purely commercial points rules.

[0041] 11.5 Example of conversion template for vehicle categories In some embodiments, the conversion template for gasoline vehicles is preferably based on one or more of the following fields: 1. Fuel efficiency; 2. Estimated fuel injection quantity; 3. Engine running time; 4. Idle time; 5. Mileage increment; 6. Operating condition classification information.

[0042] In some embodiments, the conversion template for pure electric vehicles is preferably based on one or more of the following fields: 1. Battery current; 2. Battery voltage; 3. Charge amount; 4. Discharge quantity; 5. Changes in SOC; 6. Regenerative braking energy.

[0043] In some embodiments, the conversion template for plug-in hybrid vehicles preferably adopts a dual-channel conversion method: 1. Apply a set of fuel factors to fuel consumption-related fields; 2. Apply a set of energy factors to fields related to energy consumption; 3. Finally, the two sets of results will be aggregated into a unified carbon equity outcome; 4. For windows with only one-sided fields, process them according to the degradation rules and record the degradation source in the results.

[0044] 11.6 Handling Missing Fields and Degradation In some embodiments, the server may perform the following non-limited processing for missing fields: 1. If the missing field is an optional enhanced field, continue the transformation and record the degradation flag in the result; 2. If the missing field is a necessary field under the current calc_spec_ver, then the issuance will be rejected or the application will be frozen pending review. 3. If a field can be equivalently replaced by a similar field, such as a missing fuel rate but an estimated fuel injection quantity, then convert it according to the substitution path and record the substitution identifier; 4. If a field is missing consecutively for more than the preset number of windows, the risk level will be increased or subsequent automatic issuance will be suspended.

[0045] In some embodiments, the degradation rule is determined by calc_spec_ver or a separate degrade_spec_ver reference, thereby ensuring consistent processing across different terminals and at different times.

[0046] 12. Points Confirmation Receipt and Deduplication like Figure 4 As shown, in scenarios of offline archiving, communication recovery, and batch reissue, the server does not only perform idempotent deduplication on duplicate windows, but also performs phase consistency verification on the entire batch of reissued data in combination with phase anchored credentials, thereby outputting different receipts between the first confirmation, duplicate reissue, and abnormal pending review.

[0047] When the server confirms: 1. Carbon activity certificate verification passed; 2. The chain continuity requirement is met; 3. Vehicle category, metering version, and emission factor version are matched; 4. Idempotency labels have not yet been issued; The server then calculates the carbon credit result and outputs a credit confirmation receipt.

[0048] When the server detects: 1. The idempotency flag already exists; 2. The same active window has already been confirmed; 3. The current report is merely a supplementary transmission of historical data; The server will then return an OK_DUP or an equivalent idempotent receipt, without reissuing points.

[0049] 12.1 Example of Receipt Type In some embodiments, the receipt type returned by the server includes at least one or more of the following: 1. OK indicates that the initial confirmation and issuance have been completed; 2. OK_DUP indicates that the same idempotency flag has been processed, and this is a duplicate transmission. 3. REJECT_SCHEMA indicates that the field structure, field bitmap, or version number does not meet the requirements; 4. REJECT_SIGNATURE indicates that the signature verification failed or the integrity protection failed. 5. HOLD_REVIEW indicates that the application has been frozen and is pending review. 6. NEED_SUPPLEMENT indicates that supplementary witnesses or additional fields are required; 7. REVOKED_ACK indicates that the corresponding active window has been canceled or cannot be confirmed again.

[0050] In some embodiments, the receipt may also carry: 1. `next_retry_after` is used to suggest the next retry time for the terminal; 2. reason_code, used to explain the reason for rejection, freeze, or need for supplementary documentation; 3. `confirmed_at` is used to record the time of the first confirmation; 4. issuance_ref, used to identify the corresponding points confirmation record or rights confirmation record.

[0051] 12.2 Engineering Implementation of Idempotent Deduplication In some embodiments, the server may create a unique index or unique constraint table based on an idempotent identifier, and simultaneously record the following status information: 1. first_seen_at; 2. first_confirmed_at; 3. current_status; 4. calc_spec_ver; 5. factor_ver; 6. issuance_ref; 7. revoke_ref.

[0052] With the above status information, the server can complete the issuance upon the first arrival and quickly return a consistent receipt upon subsequent repeated reports, without having to re-enter the complete conversion process.

[0053] XIII. Conflicts, Freezes and Revocations like Figure 5 As shown, when the server detects field conflicts, source conflicts, version incompatibility, or contradictions that cannot be eliminated even after supplementary certification, the corresponding activity window can be redirected to the frozen pending review, revocation, or historical reconstruction path to maintain the traceable association between points confirmation receipts, revocation records, and re-evaluation records.

[0054] In some embodiments, the server may also maintain a state machine for carbon activity credentials, including at least: 1. To be verified; 2. Confirmed; 3. Duplicate transmission; 4. Frozen pending trial; 5. Revoked; 6. Incompatibility rejection.

[0055] When the server detects one or more of the following situations, it can output at least one of the following actions: rejection of issuance, freeze pending review, request for supplementary certificate, or downgrade confirmation: 1. Field conflict; 2. Conflict of origin; 3. Account binding conflict; 4. Reversal state conflict; 5. Rule versions are incompatible; 6. Inconsistency between batch reissue and stage anchoring information.

[0056] 13.1 Further Explanation of Conflict Types In some embodiments, field conflicts may include at least: 1. The vehicle category and the field set do not match clearly; 2. A logical contradiction exists between the electricity and fuel data fields, which are defined under the same criteria; 3. The time window boundaries are inconsistent with the counter reference information; 4. The field_bitmap does not match the actual field content; 5. The combination of factor_ver and region_id is not supported.

[0057] In some embodiments, a source conflict may include at least: 1. The same idempotent identifier can correspond to multiple different terminal identifiers; 2. The same activity window can correspond to multiple different account binding identifiers; 3. The vehicle category historically bound to the terminal is inconsistent with the current vehicle category; 4. The supporting witness materials are inconsistent with the timeline of the main voucher.

[0058] 13.2 Freezing and Withdrawal Process In some embodiments, when the server determines that a carbon activity certificate requires further review, it may set its status to frozen pending review and perform at least one of the following processes: 1. Suspend the issuance of points confirmation receipts; 2. Record the reason code for the freeze; 3. Issue a request for supplementary documentation; 4. Wait for manual auditing or automatic review of the task results; 5. Mark it as non-transferable in the upper-level business system.

[0059] In some embodiments, the revocation process includes at least: 1. Record the reason for the revocation, such as rule rollback, fraud confirmation, incorrect mapping, or account dispute; 2. Establish an association between the original `issuance_ref` and `revoke_ref`; 3. Broadcast the cancellation status to the terminal or upper-level system; 4. Return REVOKED_ACK or an equivalent status upon subsequent retransmissions; 5. Rollback, freeze, or dispute marking of rights already used by downstream users.

[0060] By incorporating the freeze and revocation processes into the same state machine, this invention can cover real-world business scenarios where "confirmation precedes anomaly detection."

[0061] 13.3 Rule Upgrades and Historical Reconstruction In some embodiments, when calc_spec_ver or factor_ver is upgraded, the server does not automatically recalculate the historical confirmed records according to the latest version, but instead prioritizes maintaining the principle of "rebuilding according to the original version". That is: 1. Each confirmed active window retains its original calc_spec_ver and factor_ver; 2. During subsequent dispute audits, the results will be reconstructed based on the original version. 3. If a reassessment is required in accordance with the new regulations, a separate reassessment record will be generated, without overwriting the original confirmation record; 4. The original confirmation record and the reassessment record are linked through revision_ref or an equivalent association identifier.

[0062] This can prevent the problem of historical rights records becoming untraceable due to rule updates.

[0063] XIV. Examples 14.1 Example of a gasoline-powered vehicle In one embodiment, the onboard terminal constructs a window every 30 seconds, summarizing mileage increments, engine running time, fuel ratio, and idling time, and generates a carbon activity window summary. The server calculates the corresponding carbon credit results based on fuel type, region identifier, and factor_ver, and outputs a credit confirmation receipt after the idempotency check passes.

[0064] 14.2 Pure Electric Vehicle Example In one embodiment, the on-board terminal aggregates SOC changes, battery current, battery voltage, charging amount, and regenerative energy. The server calculates energy consumption and refueling behavior based on the regional electricity emission factor version and outputs the corresponding carbon credit confirmation results.

[0065] 14.3 Plug-in Hybrid Vehicle Examples In one embodiment, the server applies different factor versions to fuel consumption and electricity consumption respectively, and generates a combined carbon credit result within the same activity window. By simultaneously binding the vehicle category identifier, metering version identifier, and emission factor version identifier to the carbon activity certificate, it is possible to restore the original conversion logic in case of subsequent disputes.

[0066] 14.4 Offline Retransmission Example In one embodiment, the vehicle is in a weak network area for 5 consecutive days. During this period, the on-board terminal continuously generates carbon activity window summaries in 1-minute windows and calls the security component to generate carbon activity credentials. All credentials are appended and stored locally. After network connectivity is restored, the terminal reissues the credentials in batches according to time sequence. The server first checks whether the batch of data is continuous in time and chain references by anchoring the credentials in stages, and then deduplicates each data item according to the idempotency flag. For the first occurrence of a window, the server performs a conversion and returns OK; for windows that are repeatedly sent due to network jitter, the server directly returns OK_DUP without reissuing the credit confirmation receipt.

[0067] 14.5 Example of Dispute Review In one embodiment, a car owner claims to have completed specific green travel tasks within a certain natural week and applies for subsidies, but the platform discovers that the combination of `factor_ver` and `region_id` for some windows is abnormal. The server freezes the relevant activity windows pending review and requests supplementary charging event witness summaries generated by the mobile terminal within the connection window. If the supplementary materials and the master certificate are simultaneously valid in terms of time and event type, the server unfreezes the window and reconfirms it according to the original `calc_spec_ver`; if the supplementary materials conflict with the master certificate, the server maintains the freeze or performs a revocation.

[0068] 14.6 Example of Account Conflict In one embodiment, the same activity window is submitted with claim requests by two separate accounts. Upon detecting a conflict through idempotency identifiers and terminal binding relationships, the server does not directly issue duplicates based on a first-come, first-served basis, but instead: 1. Set the window status to frozen pending review; 2. Record the binding requests for the two accounts; 3. Check vehicle binding history, terminal binding history, and initial confirmation records; 4. Confirm valid accounts according to preset rules or transfer to manual processing; 5. Return a rejection receipt for invalid accounts.

[0069] This embodiment illustrates that the present invention can not only prevent duplicate resubmissions, but also handle duplicate applications across accounts.

[0070] XV. Example Data Structures and State Machines 15.1 Example of Carbon Activity Certificate Fields In some embodiments, carbon activity certificates may use the following non-limited set of fields: 15.2 Server State Machine Example In some embodiments, the server may maintain the following non-limited state machine: 1. RECEIVED: Received, awaiting verification; 2. VERIFIED: Verification passed, pending further review; 3. ELIGIBLE: Review passed, awaiting conversion; 4. ISSUED: Confirmation receipt has been issued; 5. DUPLICATED: Duplicate transmission, no further issuance; 6. HOLD: Frozen pending review; 7. REVOKED: Revoked; 8. REJECTED: Rejected processing.

[0071] State transitions may include at least: 1. RECEIVED -> VERIFIED -> ELIGIBLE -> ISSUED; 2. RECEIVED -> REJECTED; 3. VERIFIED -> HOLD; 4. ISSUED -> REVOKED; 5. Any existing idempotent state -> DUPLICATED.

[0072] 15.3 Example of conversion and issuance of pseudo-process In some embodiments, the server may process the data according to the following non-limiting pseudo-flow: 1. Read the voucher; 2. Verify the signature; 3. Check chain_ref and counter_ref; 4. Check if vehicle_class_id, calc_spec_ver, and factor_ver are available; 5. Calculate the status corresponding to evidence_id; 6. If it already exists and its status is ISSUED, then return OK_DUP; 7. If the status is HOLD or REVOKED, return the corresponding freeze or cancellation receipt; 8. Otherwise, the conversion will be performed according to the vehicle category; 9. Write the issuance_ref; 10. Return OK.

[0073] 15.4 Example of Vehicle Category and Field Mapping In some embodiments, different vehicle categories may use the following non-limited field mapping relationship: Through the above mapping relationship, the server can quickly determine whether the current field_bitmap meets the minimum conversion requirements after reading vehicle_class_id.

[0074] 15.5 Example of Emission Factor Version and Geographic Binding In some embodiments, factor_ver not only represents an abstract version number, but can also be bound to one or more of the following fields: 1. region_id, used to identify the country, region, province, or power grid area; 2. energy_type_id, used to identify the energy type: gasoline, diesel, natural gas, electricity, or a hybrid energy source; 3. policy_id, used to identify specific carbon credit projects, insurance projects, automaker credit projects, or regulatory plans; 4. `valid_from` and `valid_to` are used to limit the valid time period of a factor version; 5. factor_pack_digest, used to reference a summary of a specific parameter pack.

[0075] In some embodiments, the server can select the corresponding parameter package using both factor_ver and region_id, and write a summary of the parameter package into the record corresponding to issuance_ref, so that the conversion basis at that time can be restored in case of subsequent disputes.

[0076] Preferably, when the parameter package corresponding to factor_ver contains multiple time segments or multiple dynamic factor subsets, the server can also write the time interval identifier reference, sub-factor set reference, or segment parameter summary actually used in this activity window into the corresponding record of issuance_ref. Thus, in subsequent scenarios of frozen pending audit, historical reconstruction, or cross-cycle audit, it can not only reconstruct "which version of the factor package was used", but also "which set of time periods or dynamic sub-factors in the factor package was used".

[0077] 15.6 Example of a Terminal Local State Machine In some embodiments, the vehicle terminal may maintain the following non-limited local state machine: 1. IDLE indicates waiting for a new window to open; 2. COLLECTING indicates that carbon activity-related data within the current window will be collected; 3. ENCODING indicates that normalized coding is performed; 4. SIGNING indicates that the security component is invoked to generate carbon activity credentials; 5. SEALED indicates that a local append write has been performed; 6. QUEUED indicates waiting for a report to be submitted; 7. SENT indicates that the report has been submitted and a response is pending. 8. ACKED indicates that OK or OK_DUP has been received; 9. HOLD_LOCAL indicates that an anomaly was detected locally and is awaiting further processing.

[0078] In some embodiments, the terminal state may flow at least as follows: 1. IDLE -> COLLECTING -> ENCODING -> SIGNING -> SEALED; 2. SEALED -> QUEUED -> SENT -> ACKED; 3. SENT returns to QUEUED after a timeout to perform a backoff retry; 4. When a field is found to be missing beyond the threshold, or when there is an abnormality in the storage medium or a counter, the process is redirected to HOLD_LOCAL.

[0079] By making the local state machine explicit, the consistency of terminal behavior can be improved in weak network and network outage scenarios.

[0080] 15.7 Example of auxiliary witness material structure In some embodiments, if a mobile terminal participates in assisted witnessing, its witnessing materials may use the following set of non-limited fields: In some embodiments, supporting witness materials serve only as a means of enhancing credibility or reviewing disputes, and do not change the system structure of "priority of vehicle terminal master credential".

[0081] 15.8 Examples of Witnessing Refueling and Charging Events In some embodiments, the supporting witnessing materials can be generated for typical carbon activity scenarios: 1. Refueling event witnessing: The mobile terminal records the gas station session identifier reference, time reference, and proximity contact information within the connection window, and binds them to the main credential window reference; 2. Charging event witnessing: The mobile terminal records the charging pile session number reference, connection establishment time, end time or electricity ticket summary, and binds it to the main certificate on the power side; 3. Maintenance Event Witness: When a vehicle is in a maintenance scenario, it is only used to illustrate the source of window switching or data anomalies, and does not directly generate carbon credits.

[0082] In some embodiments, refueling event witnesses and charging event witnesses can be entered into the server verification module along with the master credential, thereby providing supplemental consistency material in the presence of tickets, session records, or user appeals.

[0083] 15.9 Example of a pseudo-formula for conversion template The following pseudo-formulas are only used to illustrate the conversion structure of this invention and are not intended to limit the specific mathematical model: 1. For gasoline-powered vehicles, the basic fuel-side results can be calculated as fuel_amount × fuel_factor; 2. For pure electric vehicles, the basic results on the power side can be calculated as electric_amount × electric_factor; 3. For plug-in hybrid electric vehicles, the result can be combined as fuel_result + electric_result; 4. For situations such as idling, regenerative braking, and abnormal degradation, the weights can be increased, decreased, or reduced according to the correction items specified by calc_spec_ver.

[0084] This invention does not require a specific formula to constitute the inventive point itself. The inventive point is that the above conversion is carried out under the constraints of trusted carbon activity certificates, versioning factors, and idempotent issuance.

[0085] 15.10 Example of Storage and Audit Record Structure In some embodiments, the server may write the following non-limited audit log for each acknowledgment: 1. evidence_id; 2. issuance_ref; 3. vehicle_class_id; 4. calc_spec_ver; 5. factor_ver; 6. status; 7. first_confirmed_at; 8. confirm_reason_code; 9. assist_ref; 10. revision_ref; 11. revoke_ref.

[0086] Based on the above records, the server can quickly answer the following questions during subsequent audits: 1. Based on which version of the definition was a certain rights and interests outcome generated? 2. Has a particular active window been repeatedly uploaded? 3. Has a record been frozen, reassessed, or revoked? 4. Are there supporting witness materials for a particular record? 5. Whether a certain benefit outcome is replaced by a subsequent revision_ref.

[0087] XVI. Optional Alternative Implementation 16.1 Reporting and Batch Processing In some embodiments, the terminal may employ a backoff and retry mechanism when reporting carbon activity certificates to reduce the pressure of repeated transmissions in weak network environments. The backoff and retry mechanism may include at least: 1. After the first failure, wait for the first retreat time; 2. When consecutive failures occur, increase the waiting time by using exponential or segmented backoff. 3. Upon receiving next_retry_after, prioritize retrying according to the server's suggested time. 4. Records that have received OK_DUP should be dequeued immediately without retrying; 5. Suspend automatic reporting for records in HOLD_LOCAL state.

[0088] In some embodiments, a terminal can batch report credentials from multiple consecutive windows, but batch reporting does not change the fact that each active window corresponds to an independent idempotent identifier. The server can receive the credentials in batches first, and then process each credential within a batch one by one, thereby balancing throughput and idempotency consistency.

[0089] 16.2 Resource Constraints and Edge Implementation Boundaries This invention is preferably applicable to resource-constrained vehicle terminals; therefore, the terminal implementation should preferably satisfy one or more of the following constraints: 1. Limited storage constraints: Prioritize long-term storage of normalized summaries, citation information, and credentials, rather than long-term storage of the full original data; 2. Limited computing power constraints: Prefer deterministic rules, fixed field encoding, and lightweight digest algorithms over heavy model inference; 3. Limited energy consumption constraint: Prioritize unified encoding and signing at the end of the window, rather than signing each original sampling point separately; 4. Limited communication constraints: Prioritize batch reissue of digests and credentials when the network is weak, and use the original data only as partial supplementary evidence in dispute scenarios.

[0090] Through the above design, the present invention can be implemented in low-cost aftermarket devices, embedded controllers, or restricted edge nodes.

[0091] 16.3 Abnormal Attack Surface and Suppression Methods In some embodiments, the present invention can suppress attacks on the following surfaces: 1. History Replay: Attackers resend old credentials, and the server identifies duplicates using idempotent flags and a state machine; 2. Batch forgery: After being offline for a long time, the attacker attempts to forge a batch of windows. The server performs continuity verification through chain_ref, counter_ref, and phase anchor credentials. 3. Cross-account arbitrage: When multiple accounts apply for the same activity window, the server uses account binding relationships and initial confirmation records to suppress duplicate issuance; 4. Rule switching arbitrage: Attackers attempt to use old fields in conjunction with new version factors to obtain abnormal profits. The server suppresses this by checking the consistency between calc_spec_ver and factor_ver. 5. Event spoofing: Attackers forge and bind irrelevant charging or refueling events to the master credential. The server identifies this through timeline, session identifier references, and secondary witness consistency.

[0092] It should be emphasized that this invention does not require all attacks to be completely blocked at the client side. Instead, it reduces the success rate of attacks through a combination of "creating trusted credentials at the client side + performing version verification and idempotent control at the server side".

[0093] 16.4 Audit and Derivation Boundaries In some embodiments, to balance privacy and auditing, data exported or provided externally by the server is preferably layered: 1. First level: Only export the integration confirmation results, version references, and minimum necessary summary; 2. The second layer involves exporting carbon activity vouchers, receipt types, and status transition records in dispute scenarios; 3. At the third level, auxiliary witness summaries, partial raw indexes, or revision_ref associated records are exported only under authorized auditing.

[0094] This avoids exposing too many details of vehicle operation in routine business while retaining sufficient capacity for dispute review.

[0095] 16.5 Time Synchronization and Boundary Error Handling In some embodiments, the time bases of the vehicle terminal and the server may deviate; therefore, a time boundary error handling mechanism is preferably introduced. The mechanism may include at least: 1. Record local time references and their quality levels on the terminal side; 2. Allow a preset time deviation window on the server side; 3. Supporting witness materials are only required to be simultaneously valid in time, not necessarily perfectly consistent at the millisecond level; 4. When the time deviation exceeds the threshold, the process of supplementing certification, downgrading, or freezing pending review will begin.

[0096] The above mechanism can reduce the impact of weak timing environment on system availability.

[0097] 16.6 Examples of Industrial Deployment Methods In some embodiments, the present invention may be deployed in one or more of the following ways: 1. The vehicle-mounted terminal is directly connected to the server, and the terminal independently generates and reports carbon activity certificates; 2. The vehicle-mounted terminal reports via a mobile terminal relay; the mobile terminal only forwards the information and may attach supplementary supporting documentation. 3. The vehicle-mounted terminal first reports to the edge node, where it performs caching and batch aggregation before forwarding to the server; 4. Multi-server layered deployment: upstream is responsible for signature verification and idempotency, while downstream is responsible for project definition conversion and business mapping.

[0098] Regardless of the deployment method used, as long as the main chain of "establishing trusted credentials first, performing versioned calculations, and issuing idempotent certificates before outputting" is maintained, it does not deviate from the main purpose of this invention.

[0099] Without departing from the spirit of this invention, the following alternative implementations are also possible: 1. Replace fixed time windows with event windows; 2. Replace time-based triggering with mileage-based triggering; 3. Replace digital signatures with message authentication codes; 4. Replace some of the monotonic counter reference information with hardware counters or trusted time sources; 5. Use charging pile session credentials, gas station session credentials, or maintenance terminal witness summaries as supplementary witnessing materials; 6. Cloud-edge collaborative conversion is used instead of pure server conversion, but the final confirmation is still controlled by the trusted signing module.

[0100] Technical effect Compared with the prior art, the present invention has at least the following beneficial effects: 1. By establishing a reliable chain of evidence on-vehicle devices, carbon activity certificates can be verified, reissued, and audited, thereby improving the credibility of basic data; 2. Improve the reproducibility of conversion results by linking vehicle category identifiers, metering caliber version identifiers, and emission factor version identifiers; 3. By using idempotent flags and state machine control, the risks of offline re-upload, duplicate submission, and duplicate claims across accounts are reduced; 4. Improve the verification capability in dispute scenarios by using optional auxiliary witnessing materials consistency checks; 5. Provide a credible entry point for subsequent carbon rights transfer, subsidy distribution, insurance discounts, automaker credits, or local low-carbon projects.

Claims

1. A method for carbon activity measurement and auditable point issuance based on vehicle-mounted trusted evidence chains, characterized in that, The method, executed collaboratively by an in-vehicle terminal and a server, includes a vehicle bus interface, a processor, a memory, and a security component for providing protected keys. The method comprises: acquiring at least one type of vehicle carbon activity-related data within a preset time window or a preset mileage window and generating a carbon activity window summary; wherein the vehicle carbon activity-related data includes one or more of the following: mileage-related information, engine fuel consumption, estimated fuel injection, engine running time, idling time, battery state of charge, charging capacity, discharging capacity, regenerative braking energy, and operating condition classification information; encoding the carbon activity window summary according to standardized encoding rules, and binding the carbon activity window summary to at least a window identifier, vehicle category identifier, metering version identifier, emission factor version identifier, monotonic counter reference information, and chained reference information of preceding window summaries or preceding credentials; controlling the security component to perform integrity protection operations on the carbon activity window summary to generate a carbon activity credential; and the method further comprises... The server receives the carbon activity certificate, verifies its signature, and performs a review based on chain continuity, field integrity, suitability of the field set corresponding to the vehicle category identifier, validity of the window interpretation and quantification rules corresponding to the metering caliber version identifier, availability of the factor set corresponding to the emission factor version identifier, and preset consistency constraints. If the review is successful and the idempotent identifier corresponding to the carbon activity certificate has not been confirmed and issued, the server calculates the carbon rights result according to the vehicle category conversion template corresponding to the vehicle category identifier, and based on the metering caliber version identifier and the emission factor version identifier, and issues a points confirmation receipt. If the idempotent identifier already exists, the carbon activity certificate is in a re-transmission state, or the activity window corresponding to the carbon activity certificate has been confirmed, the server returns an idempotent receipt without re-issuing points. The vehicle terminal continuously stores the carbon activity certificate during communication interruption and re-sends it after communication is restored.

2. A carbon activity measurement and auditable points issuance system based on an on-board trusted evidence chain, characterized in that, The system includes an in-vehicle terminal and a server; wherein the in-vehicle terminal includes a vehicle bus interface, a processor, a memory, and security components; the server includes a receiving module, a verification module, a review module, a conversion module, and an issuance module; the in-vehicle terminal is used to generate a carbon activity window summary and a carbon activity certificate, and the server is used to perform review, conversion, and issuance of points confirmation receipts for the carbon activity certificates; the in-vehicle terminal and the server are configured to collaboratively execute the method of claim 1.

3. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the method of claim 1.

4. The method according to claim 1, wherein the carbon activity-related data includes at least one or more of the following: cumulative mileage, mileage increment, vehicle speed, engine speed, fuel rate, mass airflow estimate, fuel injection pulse width, battery current, battery voltage, and charging station session power output from the vehicle bus.

5. The method according to claim 1, wherein the metering caliber version identifier is used to distinguish at least two types of vehicles among fuel vehicles, hybrid vehicles, plug-in hybrid vehicles and pure electric vehicles, and corresponds to at least one of different field selection rules, window interpretation rules, quantization accuracy rules, anomaly degradation rules or conversion template selection rules.

6. The method according to claim 1, wherein the server further verifies the consistency between the carbon activity certificate and the auxiliary witnessing materials generated by the mobile terminal in the connection window before issuing the points confirmation receipt, and the auxiliary witnessing materials include at least one or more of time reference information, close contact information, charging event witnessing information, refueling event witnessing information, or location summary.

7. The method according to claim 1, wherein the idempotency identifier is calculated by deterministically encoding at least three of the following: the normalized coding result of the carbon activity window summary or its summary, the vehicle category identifier, the metering version identifier, the emission factor version identifier, and the monotonic counter reference information.

8. The method according to claim 1, wherein when the server detects that the carbon activity certificate has one or more of the following: field conflict, source conflict, account binding conflict, revocation status conflict, or rule version incompatibility, the server outputs at least one of the following processing results: refusal to issue, freeze pending review, request for supplementary certificate, or downgrade confirmation; wherein the rule version incompatibility includes at least the following: the vehicle category identifier does not match the metering caliber version identifier, or the emission factor version identifier does not match one or more of the following: regional identifier, time interval identifier, energy type identifier, or regulatory plan identifier.

9. The method according to claim 1, wherein the emission factor version identifier is bound to at least one or more of a region identifier, a time interval identifier, an energy type identifier, or a regulatory plan identifier, so that the server can reconstruct the carbon rights results according to the corresponding version caliber; and the emission factor version identifier may also be associated with at least one of a parameter package summary reference, a sub-factor set reference, or a segmented parameter summary, and the server selects the corresponding sub-factor set from the parameter package referenced by the emission factor version identifier to perform conversion based on the time interval identifier, region identifier, energy type identifier, or event type identifier corresponding to the activity window, and retains at least one of the parameter package summary reference, sub-factor set reference, or segmented parameter summary actually used in the confirmation record to support subsequent freeze pending review, historical reconstruction, or cross-cycle audit.

10. The method according to claim 1, wherein the vehicle terminal locally stores the carbon activity certificate by appending a write method, and performs integrity protection on the phase summary summary to generate a phase anchor certificate, and the server uses the phase anchor certificate to perform consistency verification on the batch reissue data after long-term offline status.

Images