A green intelligent ticket generation and settlement system supporting real-time deduction of carbon credits

Abstract

The application provides a green intelligent ticket generation and settlement system supporting real-time deduction of carbon credits, and relates to the field of digital data processing, comprising a carbon emission reduction quantification module, a ticket carbon credit linkage settlement module, a user and credit account management module, a travel data access module and a payment channel module, the carbon emission reduction quantification module takes private car travel as the benchmark emission reference, calculates the carbon emission reduction of actual travel of the user, and adopts a group scarcity dynamic conversion mechanism to convert the carbon emission reduction into carbon credits, the ticket carbon credit linkage settlement module defines ticket payment, carbon credit deduction and ticket generation as three-atomic commit units, synchronously executes through a concurrent pre-occupation mechanism, and uniformly submits to generate a ticket voucher after successful pre-occupation of the three parties; the application realizes real-time linkage of carbon emission reduction quantification and ticket settlement, and fundamentally solves the problems of lack of dynamic and reliable mechanism for carbon credit conversion and inconsistent state caused by step-by-step settlement of tickets and credits.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing, specifically to a green intelligent ticketing generation and settlement system that supports real-time carbon credit deduction. Background Technology

[0002] With the increasing severity of global climate change, reducing carbon emissions has become a common goal of the international community. In the transportation sector, promoting green travel is considered one of the important pathways to achieving the "dual carbon" goal. In recent years, various technical solutions have emerged both domestically and internationally to quantify green travel behaviors into carbon credits and provide incentives. However, existing technologies have significant shortcomings in terms of the dynamic reliability of carbon credit conversion mechanisms and the consistency of ticketing and credit settlement.

[0003] In the field of carbon credit formation and application, Chinese invention patent application CN104766237A discloses a method and system for carbon credit formation and trading. This patent proposes calculating carbon emission reductions based on users' low-carbon behavior data and forming carbon credits, which can be traded and exchanged within a platform. However, the carbon credit conversion method used in this patent is a fixed-ratio conversion, that is, directly converting carbon emission reductions into credits using a preset fixed coefficient. The conversion result depends only on the absolute emission reduction of the user's current trip and is unrelated to the overall travel status of other users on the platform. This static conversion method has two fundamental flaws: First, the fixed conversion coefficient cannot reflect the scarcity of green travel behavior within the same time period. In periods or areas with low green travel density, the marginal social emission reduction value of individual travel should be higher, but the fixed coefficient cannot reflect this difference, resulting in a lack of time-sensitivity in the credit incentive mechanism. Second, the fixed conversion rules are easily predicted and exploited, lacking an inherent mechanism to prevent coordinated manipulation, making it difficult to guarantee the fairness of credit distribution. Furthermore, the formation and use of points in this patent are independent processes, with points being issued first and consumption deductions following. There is no atomic binding between the two, and in the ticketing scenario, the consistency between the point deduction and ticket generation cannot be guaranteed.

[0004] In the field of combining carbon credits with electronic ticketing, US Patent No. US8930236B2 discloses a system and method for aggregating and distributing carbon emission reduction credits through electronic coupons. This patent links carbon credits with electronic coupons, allowing users to earn carbon emission reduction credits when participating in specific marketing activities. These credits can be disseminated through social networks and used for consumption discounts. However, this patent has the following shortcomings: First, the generation of carbon credits depends on the triggering of marketing activities, rather than being calculated based on the actual carbon emission reductions from user travel, lacking a reliable quantitative correlation between the source of credits and actual emission reduction behavior; second, the credit conversion also uses preset fixed rules, without introducing any dynamic adjustment mechanism; third, in this patent, the generation of tickets (coupons) and the processing of credits are separate operations in the system architecture. Credits are only recorded or deducted after coupons are generated, creating a risk of inconsistency between the two operations. When the system malfunctions between these two steps, an abnormal state may occur where coupons have been issued but credits have not been correctly processed, and this patent does not provide any compensation mechanism for such intermediate states.

[0005] In summary, existing technologies in the field of carbon credits for green travel have the following two main shortcomings: First, carbon credit conversion generally adopts a static fixed ratio, which cannot dynamically adjust the conversion coefficient in real time according to the scarcity of green travel groups within the platform. The credit incentive mechanism lacks time-varying differences and anti-manipulation guarantees, resulting in limited credibility and incentive effect of carbon credits. Second, ticket generation and carbon credit processing are both step-by-step asynchronous operations in existing systems, and there is no atomic constraint between the two. When the system fails at any stage, it may fall into an inconsistent intermediate state, and there is a lack of a systematic compensation mechanism for the asymmetry of the rollback path between the monetary ledger and the carbon credit ledger.

[0006] To address the aforementioned shortcomings, this invention proposes a green intelligent ticketing generation and settlement system that supports real-time carbon credit deduction. It solves the dynamic reliability problem of carbon credit conversion through a group scarcity dynamic conversion mechanism, and solves the state consistency problem of ticketing and credit linkage through a ternary atomic submission structure and a heterogeneous ledger asymmetric compensation mechanism. Summary of the Invention

[0007] The purpose of this invention is to address the shortcomings by proposing a green and intelligent ticketing generation and settlement system that supports real-time carbon credit deduction.

[0008] The present invention adopts the following technical solution:

[0009] A green and intelligent ticketing generation and settlement system that supports real-time carbon credit deduction includes a carbon emission reduction quantification module, a ticketing carbon credit linkage settlement module, a user and credit account management module, a travel data access module, and a payment channel module.

[0010] The carbon emission reduction quantification module uses private car travel as the baseline emission reference, collects the user's actual travel mode, travel distance, real-time vehicle occupancy rate and energy consumption factor, calculates the carbon emission reduction of this trip through the difference algorithm, and converts the carbon emission reduction into carbon credits through the group scarcity dynamic conversion mechanism.

[0011] The group scarcity dynamic conversion mechanism adopts a two-layer sliding time window to continuously count the green travel density within the platform. The short window is updated in a preset time unit to capture the real-time travel density at the current moment. The long window provides a stable density benchmark reference based on historical data of the same time period of a preset natural day. The current density reference value is obtained by weighting the short window density and the long window mean. Then, the scarcity index is obtained by comparing this value with the platform's historical peak density. The conversion coefficient and the scarcity index adopt a non-linear mapping relationship. The lower the scarcity index, the higher the conversion coefficient. When the scarcity index approaches 1, the conversion coefficient converges to the preset benchmark value.

[0012] The conversion coefficient has upper and lower limits. The amount of points issued to a single user during a high coefficient period has an independent upper limit to prevent users from colluding to create false scarcity and obtain high coefficients.

[0013] The final carbon credit is determined by the carbon emission reduction amount and the current conversion factor.

[0014] Furthermore, the carbon emission reduction quantification module uses private car travel over the same distance as a carbon emission benchmark. It obtains the actual mode of travel, route distance, real-time passenger load factor of the vehicle and corresponding energy consumption factor from the travel data access module. It calculates the actual per capita carbon emission of the trip according to the ratio of carbon emission per unit distance to passenger load factor. Then, it subtracts the actual per capita carbon emission from the standard carbon emission of private cars over the same distance to obtain the carbon emission reduction of the trip, in grams of carbon dioxide equivalent.

[0015] When real-time passenger load data is unavailable, the historical average passenger load for that route and time period is used as a downgraded alternative input to ensure continuous availability of the calculation.

[0016] Furthermore, when the scarcity index experiences an abnormal decline beyond the normal fluctuation range within a preset time window, the carbon emission reduction quantification module uses a preset benchmark conversion factor instead of the dynamic conversion factor for integral calculation, suspends the normal operation of the group scarcity dynamic conversion mechanism, and resumes the dynamic conversion logic after the abnormality is verified and eliminated.

[0017] The determination of the abnormal state is based on the historical fluctuation baseline of the scarcity index. When the abnormal state exceeds a preset multiple of the baseline, the substitution mechanism is triggered.

[0018] Furthermore, after the carbon credits calculation is completed, the carbon emission reduction quantification module will package the travel data, real-time passenger load factor or downgrade replacement value, current scarcity index and its corresponding two-layer window statistical results, and final conversion factor, together with the user identity identifier and the timestamp uniformly issued by the server, into a credit traceability record.

[0019] The timestamp is issued by the server rather than generated locally on the client, ensuring that in scenarios where travel data uploads are delayed in weak network environments, the anchor time reflects the moment when the server confirms the data integrity rather than the user's device's local time.

[0020] The traceability records are stored in association with the corresponding ticket vouchers using hash values ​​as unique indexes, so that the source, calculation process, and group background of each carbon credit can be independently verified afterward.

[0021] Furthermore, the ticketing carbon credit linkage settlement module redefines the three operations of ticket payment, carbon credit deduction, and ticket generation as the three constituent conditions of an atomic submission unit. After receiving a user's ticket purchase request, the system simultaneously initiates a pre-reservation operation to the payment channel, carbon credit account, and ticket generation service. If all three pre-reservations are successful, a unified submission is triggered. If any pre-reservation fails, all three are released simultaneously.

[0022] Payment-side pre-holding is the freezing of funds for the monetary difference after deducting carbon credits from the ticket price; carbon credit-side pre-holding is the temporary locking of the corresponding number of credits, which cannot be used by other transactions during the locking period; ticketing-side pre-holding is the reservation of ticketing resources corresponding to this trip to prevent concurrent and duplicate allocation.

[0023] The ticket voucher is generated the moment it is successfully submitted, and its generation timestamp is strictly consistent with the transaction submission timestamp. The traceability record hash value is written to the ticket voucher after successful submission, so that the ticket carries a verifiable index pointing to the complete carbon calculation process.

[0024] Furthermore, the ticketing carbon credit linkage settlement module clearly distinguishes between two abnormal states: failure and timeout without response.

[0025] Explicit failure means that one party returns a failure response before the timeout window expires. In this case, the system immediately sends a synchronization release command to all three parties to terminate the transaction.

[0026] Timeout without response means that one party has not returned any response when the timeout window expires. At this time, the system sends a forced release command to the non-responding party and waits for confirmation. If the forced release confirmation times out, the transaction will be marked as suspended and handed over to the compensation mechanism for processing.

[0027] When initiating a pre-occupancy, the system synchronously sends the uniformly calculated lock validity period as a parameter to the pre-occupancy command to all three parties, ensuring that the lock validity periods of the three parties are aligned under the same base time, and preventing inconsistencies such as some pre-occupancy being automatically released while others remain locked.

[0028] Furthermore, the ticketing carbon credit linkage settlement module maintains an independent status tracking table for each ternary atomic transaction, recording the current status of the three parties' pre-occupation, the sending status of the submission instruction, and the confirmation results of each party. The update operation of the status tracking table ensures atomicity and maintains a version number for each record.

[0029] The compensation mechanism scans suspended transactions in a polling manner and identifies four intermediate states by actively querying the current status of the three parties and comparing it with the status tracking table: the pre-allocation of currency has been released but the pre-allocation of carbon credits is still locked; the pre-allocation of carbon credits has been released but the pre-allocation of currency is still frozen; neither has been released but the ticket reservation is valid; and both have been released but the ticket reservation has not been released synchronously. An independent compensation path is executed for each state.

[0030] The compensation path involving monetary refunds is executed in a fixed order of carbon credit release, ticket resource release, and monetary refund. If a refund request fails, it will be retried a preset number of times. After the number of retries is exceeded, it will be transferred to the manual processing queue.

[0031] Furthermore, the ticketing carbon credit linkage settlement module generates a globally unique identifier for each compensation operation. When the three parties receive a compensation instruction, they use this identifier as the key to perform idempotency verification. For compensation operations that have already been processed, they directly return success without repeating the execution, ensuring that retries do not lead to the duplicate release of funds or credits.

[0032] Before performing compensation operations, the compensation mechanism checks whether the version number of the corresponding record in the status tracking table has changed, to prevent compensation operations from being performed based on expired status.

[0033] Furthermore, when a user's available carbon credits are insufficient to fully offset the amount, the number of carbon credits pre-allocated is capped at the actual available balance in the account, and the pre-allocated amount on the payment side is adjusted accordingly to the monetary difference between the ticket price and the value of the actual deductible carbon credits.

[0034] Partial deduction and full deduction are completely consistent in the three-element atomic transaction structure, and the system does not need to maintain different processing logic for the two scenarios;

[0035] Before the ternary atomic structure is activated, the carbon integral has been calculated by the carbon emission reduction quantification module, and the calculation result, along with the source traceability record hash value, is transmitted to this module.

[0036] Furthermore, the user and points account management module is responsible for user registration, identity authentication, and the establishment and maintenance of carbon points accounts, records the dynamic changes in points balance, provides an identity anchoring basis for the carbon emission reduction quantification module, and provides data support for the linkage settlement module to query available points and update balance.

[0037] The travel data access module connects to transportation operators, navigation platforms or in-vehicle devices to obtain users’ original travel data in real time. When real-time passenger load factor is not available, it provides historical average data as a downgraded alternative input and serves as the data input source for the carbon emission reduction quantification module.

[0038] The payment channel module connects to a third-party payment system to handle the freezing, clearing, and refunding of the monetary portion of the ticket price, forming a hybrid payment closed loop together with carbon credit deduction.

[0039] The beneficial effects achieved by this invention are:

[0040] This system fundamentally solves the problem of static and fixed carbon credit conversion coefficients in existing technologies, which cannot reflect the marginal social value of individual travel behavior, through a dynamic conversion mechanism based on group scarcity. By using a two-layer sliding time window to statistically analyze the density of green travel within the platform in real time and calculate the scarcity index, the conversion coefficient can be dynamically adjusted according to changes in the group's travel status. Higher credit incentives are given in periods and areas with low green travel density, and converge to the benchmark value when the density is high. This ensures that the number of carbon credits issued truly reflects the marginal contribution of individual travel behavior to overall social emission reduction, significantly improving the time sensitivity and social equity of the carbon credit incentive mechanism.

[0041] This system, through a combination of upper and lower limit constraints on the conversion factor and an independent upper limit for each credit issuance, along with automatic identification of abnormal fluctuations in the scarcity index and a benchmark factor substitution mechanism, blocks the manipulation path of users colluding to create false scarcity to obtain high coefficients. While maintaining the flexibility of dynamic conversion, it ensures the fairness of credit issuance and system stability, and solves the inherent defect of existing dynamic pricing mechanisms in carbon credit scenarios that lack anti-manipulation design.

[0042] This system uses a dual anchoring mechanism of server-side unified timestamp issuance and user identity identification to establish an immutable correspondence between the source of each carbon credit and specific travel behavior. The timestamp issuance authority is centralized on the server and cannot be bypassed by the client, fundamentally eliminating the risk of client-side local timestamps being forged or retrospectively tampered with in weak network environments. This ensures that the source, calculation process, and group background of carbon credits can be independently verified afterward, effectively guaranteeing the credibility of the credits.

[0043] This system defines ticket payment, carbon credit deduction, and ticket generation as three atomic submission units and executes them synchronously using a concurrent pre-occupancy mechanism. This breaks the linear structure of the existing technology, which involves asynchronous step-by-step operations for ticket generation and credit processing. It fundamentally eliminates the time gap between the two operations, ensuring that the ticket voucher is generated only the instant after all three parties have successfully pre-occupied and submitted in a unified manner. There is no outflow of any ticket carrying intermediate state information, which completely solves the problem of inconsistent states in the existing system in the scenario of ticket and credit linkage.

[0044] To further understand the features and technical content of the present invention, please refer to the following detailed description and drawings of the present invention. However, the drawings provided are for reference and illustration only and are not intended to limit the present invention. Attached Figure Description

[0045] Figure 1 This is a schematic diagram of the overall structural framework of the present invention;

[0046] Figure 2 This is a schematic diagram of the internal process of the carbon emission reduction quantification module of the present invention;

[0047] Figure 3 This is a schematic diagram of the ternary atomic settlement process of the present invention;

[0048] Figure 4 This is a schematic diagram of the heterogeneous ledger compensation state machine of the present invention;

[0049] Figure 5 This is a schematic diagram of the interactive interface (UI) of the present invention. Detailed Implementation

[0050] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can understand the advantages and effects of the present invention from the content disclosed in this specification. The present invention can be implemented or applied through other different specific embodiments, and various details in this specification can also be modified and changed based on different viewpoints and applications without departing from the spirit of the present invention. Furthermore, the accompanying drawings of the present invention are for simple illustrative purposes only and are not depictions of actual dimensions; this is stated beforehand. The following embodiments will further describe the relevant technical content of the present invention in detail, but the disclosed content is not intended to limit the scope of protection of the present invention.

[0051] Example 1.

[0052] This embodiment provides a green intelligent ticketing generation and settlement system that supports real-time carbon credit deduction, combined with... Figure 1 It includes a carbon emission reduction quantification module, a ticketing carbon credits linkage settlement module, a user and credits account management module, a travel data access module, and a payment channel module;

[0053] The carbon emission reduction quantification module uses private car travel as the baseline emission reference, collects the user's actual travel mode, travel distance, real-time vehicle occupancy rate and energy consumption factor, calculates the carbon emission reduction of this trip through the difference algorithm and converts it into carbon credits. The calculation results are doubly anchored by user identity and timestamp, forming an immutable correspondence between each carbon credit and the specific travel behavior, ensuring the authenticity and credibility of the credit source from the source.

[0054] The ticketing carbon credit linkage settlement module encapsulates ticket payment and carbon credit deduction into a single atomic transaction. Both are submitted simultaneously, and if the simultaneous submission is successful, the settlement is completed. If either fails, the entire transaction is rolled back, eliminating the risk of inconsistent status in traditional step-by-step settlement. After the settlement is completed, a ticket voucher is generated in real time, and the actual payment amount after deduction and the carbon emission reduction data are loaded on the ticket, so that the ticket has the dual attributes of payment voucher and carbon behavior record.

[0055] The user and points account management module is responsible for user registration, identity authentication, and the establishment and maintenance of carbon points accounts. It records the dynamic changes in points balance, provides an identity anchoring basis for the carbon emission reduction quantification module, and provides data support for the linkage settlement module to query available points and update balance.

[0056] The travel data access module connects to transportation operators, navigation platforms or in-vehicle devices to obtain raw data such as users' travel modes, routes and distances in real time, which serve as the data input source for the carbon emission reduction quantification module.

[0057] The payment channel module connects to a third-party payment system to process the settlement of funds for the monetary portion of the ticket price, forming a hybrid payment closed loop together with carbon credit deduction;

[0058] The carbon emission reduction quantification module uses private car travel over the same distance as the carbon emission benchmark. When a user initiates a trip, the system obtains the actual mode of travel, route distance, real-time passenger load factor of the vehicle and corresponding energy consumption factor from the travel data access module. The actual per capita carbon emission of the trip is calculated according to the ratio of carbon emission per unit distance to passenger load factor. The actual per capita carbon emission is then subtracted from the standard carbon emission of private cars over the same distance to obtain the carbon emission reduction of the trip, in grams of carbon dioxide equivalent. When real-time passenger load factor data is unavailable, the system uses the historical average passenger load factor of the route and time period as a downgraded alternative input to ensure the continuous availability of the calculation.

[0059] The carbon emission reduction quantification module uses a dual-layer sliding time window to continuously count the density of green travel within the platform. The short window is updated in 15-minute increments to capture the real-time travel density at the current moment. The long window is based on historical data from the same time period over the past 7 natural days to provide a stable density benchmark. The current density reference value is obtained by weighting the short window density and the long window mean. This value is then compared with the platform's historical peak density to obtain a scarcity index in the range of 0 to 1.

[0060] The lower the scarcity index, the fewer users choose green travel at the current moment, and the higher the marginal social emission reduction value of individual travel behavior. The system will increase the conversion coefficient accordingly. When the scarcity index approaches 1, the conversion coefficient converges to the preset benchmark value. The conversion coefficient and the scarcity index adopt a non-linear mapping relationship. The coefficient rises rapidly in the extremely low scarcity interval, which forms a strong incentive for low-density periods and low-coverage areas. The final carbon score is obtained by multiplying the carbon emission reduction amount of this time by the current conversion coefficient.

[0061] To prevent users from colluding to create false scarcity in order to obtain high coefficients, the system sets upper and lower limits for the conversion coefficient, and sets an independent upper limit for the amount of points issued to a single user during a high coefficient period, thus blocking malicious manipulation paths from the mechanism level.

[0062] After the carbon credits are calculated, the system will package the travel data used in the calculation, real-time load factor or downgrade replacement value, current scarcity index and its corresponding two-layer window statistical results, final conversion factor, along with the user's identity identifier and the timestamp uniformly issued by the server, into an immutable credit traceability record. The timestamp is issued by the server rather than generated locally by the client. This ensures that in scenarios where travel data is delayed in a weak network environment, the anchor time reflects the moment when the server confirms the integrity of the data, rather than the local time of the user's device, thus preventing the timestamp from being forged or retrospectively tampered with. This traceability record is stored in association with the corresponding ticket voucher, so that the source, calculation process and group background of each carbon credit can be independently verified afterward.

[0063] The carbon emission reduction quantification module calculates the current density reference value according to the following formula. :

[0064] ;

[0065] in, For short window weighting coefficients, To provide real-time green travel density in a short window, The density is the historical average value over a long window.

[0066] The carbon emission reduction quantification module calculates the scarcity index according to the following formula. :

[0067] ;

[0068] in, This represents the platform's historical peak density.

[0069] The carbon emission reduction quantification module calculates the conversion factor according to the following formula. :

[0070] ;

[0071] in, This is the lower limit of the conversion factor. The base conversion factor is used. For nonlinear curvature parameters;

[0072] The final carbon credit P issued is:

[0073] ;

[0074] in, For carbon emission reductions, This is the maximum number of points that can be awarded in a single transaction.

[0075] The ticketing carbon credit linkage settlement module redefines the three operations of ticket payment, carbon credit deduction, and ticket generation as three constituent conditions of an atomic submission unit. This breaks the linear sequence structure of traditional ticketing settlement, where payment is completed and credit processing is triggered sequentially, followed by ticket generation. Logically, there is no sequential order among the three. After receiving a user's ticket purchase request, the system simultaneously initiates a pre-reservation operation to the payment channel, carbon credit account, and ticket generation service. Once all three pre-reservations are successful, submission is triggered uniformly. If any pre-reservation fails, all three are released simultaneously. The ticket voucher is generated the moment submission is successful, rather than after payment or credit processing is completed.

[0076] The implementation of the ternary atomic structure relies on a concurrent pre-allocation mechanism. Payment-side pre-allocation is manifested as freezing the monetary difference between the ticket price and the carbon credits in the user's payment account. Carbon credits-side pre-allocation is manifested as temporarily locking the corresponding number of carbon credits in the user's carbon credits account. During the lock period, these credits cannot be used by other transactions. Ticketing-side pre-allocation is manifested as reserving the ticketing resources corresponding to this trip to prevent the same resource from being requested and allocated repeatedly by concurrent requests. The three-party pre-allocation operations are executed concurrently. The system waits for the convergence of the three-party pre-allocation results and uses the moment of the last returned result as a benchmark to determine whether the overall pre-allocation is successful within a preset timeout window.

[0077] After all three parties have successfully pre-booked, the system sends a submission instruction to all three parties simultaneously. Upon receiving the submission instruction, the ticket generation service writes the travel information, the actual payment amount after deduction, the carbon emission reduction, the current scarcity index, and the conversion factor into the ticket voucher, generating a final ticket with carbon attributes. The generation timestamp of the ticket voucher is strictly consistent with the submission timestamp of the ternary atomic transaction, ensuring that the information on the ticket corresponds completely to the settlement status and that no ticket carrying intermediate state information is leaked out.

[0078] The prerequisite for the activation of the ternary atomic structure is that the carbon integral quantity has been calculated by the carbon emission reduction quantification module. The calculation result, along with the traceability record hash value, is transmitted to this module. The amount of carbon integral pre-occupied and locked is based on the calculation result. After successful submission, the traceability record hash value is written to the ticket voucher, so that the ticket not only records the deduction result, but also carries a verifiable index pointing to the complete carbon calculation process, realizing a strong association between the ticket and the carbon behavior record.

[0079] When a user's available carbon credits are insufficient to fully offset the amount, the ternary atomic structure remains unchanged, and only two pre-allocation parameters are adjusted: the amount of carbon credits pre-allocated is capped at the actual available balance in the account, and the pre-allocation amount on the payment side is adjusted accordingly to the difference in currency after deducting the value of the actual deductible credits from the ticket price. Partial deduction and full deduction are completely consistent in transaction structure, and the system does not need to maintain different processing logic for the two scenarios.

[0080] During the concurrent execution of the three-party pre-emptive transaction, the system needs to distinguish between two states: "explicit failure" and "timeout without response" and adopt different handling strategies. Explicit failure means that one party returns a failure response before the timeout window expires. At this time, the system immediately sends a synchronous release instruction to all three parties to terminate the transaction. Timeout without response means that one party still does not return any response when the timeout window expires. At this time, the system sends a forced release instruction to the non-responding party and waits for confirmation. If the confirmation of the forced release instruction also times out, the transaction is marked as suspended and handed over to the compensation mechanism for processing. It is not allowed to directly determine failure or success based on the non-responding state.

[0081] After successful pre-acquisition by all three parties, the system enters the stage of waiting for the commit instruction. The system sets an independent lock validity period for each pre-acquisition operation. The lock validity period of all three parties is uniformly set, and its duration is slightly longer than the maximum allowed time from the initiation of the pre-acquisition to the arrival of the commit instruction. If any party does not receive the commit or release instruction within the lock validity period, its pre-acquisition lock will be automatically released. In order to prevent inconsistencies caused by the inconsistency of the lock validity periods of the three parties, such as some pre-acquisitions being automatically released while other parties are still locked, the system will send the uniformly calculated lock validity period as a parameter of the pre-acquisition instruction to all three parties when initiating the pre-acquisition, so as to ensure that the lock validity periods of the three parties are aligned under the same base time.

[0082] Combination Figure 4When a ternary atomic transaction fails during the commit phase, the rollback paths of the two types of ledgers—the monetary ledger relies on external payment channels for rollback and the carbon credit ledger is operated directly within the system—are fundamentally different, and the system may fall into four different intermediate states.

[0083] The first scenario is that the pre-allocated currency has been released, while the pre-allocated carbon credits remain locked.

[0084] The second scenario involves carbon credits pre-allocated but monetary pre-allocated credits remaining frozen.

[0085] The third scenario is that neither the pre-allocation of currency nor carbon credits has been fully released, and the reservation of ticketing resources remains valid.

[0086] The fourth type is where both monetary and carbon credits have been pre-allocated, but ticketing resources have not been released simultaneously, resulting in the ineffective allocation of resources.

[0087] The four intermediate states have different causes and corresponding compensation paths. The system needs to identify and process each state independently, and cannot use a uniform rollback command to handle them all at once.

[0088] The system maintains an independent state tracking table for each ternary atomic transaction, recording the current state of the three parties' pre-emptive status, the sending status of the commit instruction, and the confirmation results of each party. The compensation mechanism periodically scans the transactions in the suspended state in a polling manner, actively queries the current status of the three parties and compares it with the records in the state tracking table to identify which of the four intermediate states it belongs to. Then, it selects the corresponding compensation path to execute based on the identification result. The update operation of the state tracking table itself guarantees atomicity, preventing the compensation mechanism from repeatedly triggering compensation operations for the same suspended transaction in concurrent scenarios.

[0089] For the first scenario, the monetary side has already completed the release. The system only needs to send a release instruction to the carbon credit account to unlock the credits and release the ticketing resources at the same time, resulting in the shortest compensation path.

[0090] In the second scenario, the carbon credits have been released. The system needs to send a refund request to the payment channel to unfreeze the funds. The refund request may be delayed or fail. The system will continuously track the execution result of the refund request. If the refund request fails, it will be retried. After the number of retries exceeds the preset number, it will be upgraded to the manual processing queue, and the ticketing resources will be released.

[0091] In the third scenario, where none of the three parties have completed the release, the system will execute the process in a fixed order: carbon credit release, ticket resource release, and monetary refund. Priority will be given to operations that are controllable within the system, and monetary refunds that rely on external channels will be processed last, thereby reducing the probability of overall compensation failure.

[0092] In the fourth scenario, both currency and points have been released. The system only needs to send a resource release command to the ticketing service to remove the reservation and prevent ticketing resources from being occupied for a long time, thus affecting other users' normal ticket purchases.

[0093] Because the compensation mechanism uses a polling retry strategy, the same compensation operation may be triggered multiple times. The system generates a globally unique compensation operation identifier for each compensation operation. When the three parties receive the compensation instruction, they use this identifier as the key to perform idempotent verification. For compensation operations that have already been processed, they directly return success without repeating the execution, ensuring that retries will not lead to the duplicate release of funds or points.

[0094] Example 2:

[0095] This embodiment should be understood to include at least all the features of any of the foregoing embodiments, and to further improve upon them;

[0096] Combination Figure 2 The carbon emission reduction quantification module includes a difference calculation processor, a two-layer time window statistical unit, a scarcity index calculation unit, a parameter memory, an anti-manipulation monitoring unit, a timestamp issuance unit, and a traceability record memory.

[0097] The difference calculation processor is responsible for receiving parameters such as actual travel mode, route distance, real-time passenger load factor, and energy consumption factor from the travel data access module. It calculates the actual per capita carbon emissions for this trip based on the ratio of carbon emissions per unit distance to passenger load factor. Then, it calculates the carbon emission reduction for this trip by subtracting the standard carbon emissions of private cars for the same distance. The processor has a built-in degradation and substitution logic judgment unit. When real-time passenger load factor data is unavailable, it automatically switches to historical average input to ensure that the calculation is not interrupted. Since each user trip requires an independent triggering of a complete difference calculation process, the processor needs to have sufficient concurrent processing capabilities to respond to a large number of user calculation requests simultaneously during peak hours without causing queue backlog.

[0098] The dual-time window statistical unit is responsible for maintaining two independent sets of green travel density statistics, one for short windows and one for long windows, and continuously updating their statistical results for use in calculating conversion factors. The short window updates in 15-minute increments, counting the number of green trips that occur on the platform at the current moment. The unit is equipped with a high-speed read / write cache, keeping the current statistical value of the short window resident in memory, ensuring that the latest density value can be obtained directly without waiting for storage retrieval each time a conversion calculation is initiated. The long window is based on historical data from the same time period over the past 7 natural days. This part of the data is large, so the statistical unit is equipped with a dedicated time-series data storage device, indexed by date and time period, supporting quick retrieval of historical travel density data for specific time periods to calculate the mean. The statistical results of the two windows are weighted and merged by this unit, and the current density reference value is output for use by the scarcity index calculation unit.

[0099] The scarcity index calculation unit receives the current density reference value output by the dual-layer time window statistics unit and performs a ratio calculation with the platform's historical peak density stored in the parameter memory. It outputs the scarcity index in real time within the range of 0 to 1. This unit is also responsible for calculating the current conversion factor based on the scarcity index through a nonlinear mapping relationship. The curvature parameter of the mapping function, the baseline conversion factor, and the upper and lower limits of the conversion factor are all read from the parameter memory. It supports dynamic updating of parameter configuration without restarting the unit. The unit has built-in boundary verification logic, which automatically verifies whether the conversion factor is within the preset upper and lower limit range before each output of the conversion factor to prevent the conversion factor from going out of bounds due to abnormal parameter configuration.

[0100] The parameter storage is used to persistently store all configuration parameters required for the operation of the carbon emission reduction quantification module, including the benchmark value of carbon emissions per unit distance for various modes of travel, the standard carbon emission reference value for private cars, the short window weight coefficient, the upper and lower limits of the conversion coefficient, the nonlinear curvature parameter, and the upper limit of single-time points issuance, etc. The parameter storage supports online parameter updates, that is, it receives parameter update instructions issued by the management terminal during system operation and takes effect immediately. At the same time, it retains the record of historical parameter versions. If an anomaly occurs after the parameter update, it can quickly roll back to the previous valid version. The parameter storage also stores the historical average passenger load data for each route and time period, which is used by the difference calculation processor in the downgrade and replacement scenario.

[0101] The anti-manipulation monitoring unit operates independently of the difference calculation processor and the scarcity index calculation unit. It is specifically responsible for real-time monitoring of users' points acquisition behavior within the platform and identifying abnormal patterns of users colluding to create false scarcity. Specifically, this unit continuously calculates the total points accumulated by each user during the current high-coefficient period. When a user's accumulated points approach the single points distribution limit, an interception signal is sent to the points distribution process to prevent the distribution of points beyond the limit. This unit also monitors abnormal fluctuations in the overall scarcity index of the platform. When the scarcity index drops abnormally in a short period of time, an early warning is triggered, and the relevant period is marked as a suspected anomaly. The system then uses a conservative base conversion coefficient instead of the dynamic conversion coefficient to calculate points. After the anomaly is verified, the normal conversion logic is restored.

[0102] The timestamp issuance unit maintains synchronization and calibration with the standard time source through a hardware clock module. It is responsible for uniformly issuing server timestamps after the carbon credit calculation is completed. The timestamps are issued by this unit on the server side rather than generated locally by the client. This ensures that in scenarios where travel data upload is delayed in weak network environments, the anchor time reflects the moment when the server confirms the integrity of the data rather than the local time of the user's device. This unit generates a unique issuance record for each issuance operation to prevent the same calculation result from being issued with different timestamps repeatedly.

[0103] The traceability record storage is specifically used to store the traceability records of carbon credits generated after the calculation is completed. Each record contains the travel data on which the calculation was based, real-time load factor or downgrade replacement value, two-layer window statistical results, scarcity index, conversion factor, user identity identifier, server timestamp, and final number of credits. The hash value is used as the unique index of the record. The traceability record storage adopts an append-only write and no-overwrite storage strategy, that is, any written record cannot be modified or deleted, ensuring the immutability of the traceability records from the storage hardware level. The storage provides a read-only query interface. When the ticketing carbon credit linkage settlement module generates a ticket voucher, it obtains the hash value of the corresponding traceability record through this interface and writes it onto the ticket.

[0104] Combination Figure 3 The ticketing carbon credit linkage settlement module includes a transaction scheduling processor, a hardware timing unit, a status tracking memory, a compensation mechanism processing unit, a ticketing generation unit, and an idempotent verification cache.

[0105] The transaction scheduling processor is responsible for receiving a user's ticket purchase request and simultaneously initiating pre-reservation instructions to the payment channel, carbon credit account, and ticket generation service. It waits for the pre-reservation results from the three parties to converge and decides whether to trigger a commit or a release based on the convergence result. The processor supports multi-threaded concurrent scheduling and can independently maintain the ternary atomic transaction state for multiple different users' ticket purchase requests at the same time. The transactions of different users are isolated from each other and do not interfere with each other. The processor has a built-in timeout window timing logic, which starts timing from the moment the pre-reservation instruction is issued and uses the moment the last result is returned as the benchmark to determine whether the overall pre-reservation is completed within the timeout window.

[0106] The hardware timing unit is responsible for independently timing the pre-emption timeout window and lock validity period of each ternary atomic transaction. Since there may be a large number of concurrent transactions during peak periods, each transaction requires an independent timer. The hardware timing unit is equipped with multi-channel concurrent timing capability, which supports maintaining the timing status of multiple transactions at the same time. The unified release parameter of the lock validity period is calculated synchronously by this unit when the pre-emption instruction is issued and appended to the instruction to ensure that the three parties are aligned with the starting point of the lock validity period under the same base time, eliminating the validity period deviation caused by different instruction arrival delays.

[0107] The state tracking memory maintains an independent state tracking table for each ternary atomic transaction, recording the current state of the three parties' pre-occupation, the sending status of the commit instruction, and the confirmation results of each party. It serves as the data basis for the compensation mechanism to identify the four intermediate states. The state tracking memory provides atomicity guarantees for write operations, that is, each state update operation either writes completely or does not write at all, preventing the compensation mechanism from making incorrect judgments when reading a state record that has been partially written in a concurrent scenario. The memory also maintains a version number for each state record. Before executing the compensation operation, the compensation mechanism checks whether the version number has changed, preventing the current compensation operation from being executed based on an expired state when the state has been updated by other processes between multiple polls.

[0108] The compensation mechanism processing unit is deployed as an independent hardware node, running in parallel with the transaction scheduling processor. It is specifically responsible for periodically scanning the status tracking memory for transactions in a suspended state using a polling method. Upon detecting a suspended transaction, the unit proactively queries the third party for the current actual status, compares the query results with the status tracking table records, identifies which of the four intermediate states it belongs to, and sends release or refund instructions sequentially according to the corresponding compensation path. This unit is equipped with a compensation operation identifier generator, generating a globally unique identifier for each compensation operation and writing the processed identifiers into an idempotency verification cache. In retry scenarios, idempotency verification is quickly completed to prevent the same compensation operation from being executed repeatedly, leading to duplicate releases of funds or points. For compensation scenarios requiring a refund request to the payment channel, this unit is equipped with a retry scheduling queue, automatically managing the resubmission of refund requests according to a preset retry interval and maximum number of retries. After exceeding the retry limit, the corresponding transaction is transferred to a manual processing queue for manual intervention.

[0109] After receiving the submission instruction from the transaction scheduler, the ticket generation unit is responsible for writing the travel information, the actual payment amount after deduction, the carbon emission reduction, the current scarcity index, the conversion factor, and the traceability record hash value into the ticket voucher, generating a final ticket with carbon attributes. The ticket generation unit and the transaction scheduler are directly connected through an internal dedicated communication bus to ensure that the delay in the submission instruction reaching the ticket generation unit is within a controllable range, and that the generation timestamp of the ticket voucher does not deviate from the transaction submission timestamp due to communication delay. The unit has an internal ticket voucher storage to persistently store all generated ticket vouchers and establish an association index between the ticket voucher and the traceability record hash value, supporting the direct retrieval of the corresponding carbon credit calculation traceability record through the ticket voucher during post-event verification.

[0110] The idempotent check cache stores all compensation operation identifiers that have been executed by the compensation mechanism processing unit. High-speed storage media is used to support fast querying of the compensation mechanism in retry scenarios. The cache adopts a periodic cleanup strategy to remove historical identifiers that have exceeded their validity period from the cache to free up storage space. The cleanup period must be set longer than the maximum allowed time from the initiation to the final completion of any ternary atomic transaction in the system to ensure that operation identifiers that are still valid are not accidentally deleted when the cleanup operation occurs.

[0111] The user and points account management module includes an identity authentication processor, an account database storage, and a points balance cache.

[0112] The identity authentication processor is responsible for executing the identity authentication logic when a user logs in. It verifies the authentication information submitted by the user and generates an identity token. The identity token serves as the unique credential of the user's identity during this session and is used by the carbon emission reduction quantification module for identity anchoring operations. The processor is equipped with multi-factor authentication support capabilities, which can simultaneously process the verification of multiple authentication elements such as passwords and SMS verification codes in the same authentication process, and support a large number of concurrent authentications during peak periods without significant delays.

[0113] The account database storage uses a relational database storage medium that supports transaction operations to persistently store user identity information, carbon credit account balance, and credit change transaction records. Each change operation of the account balance is executed in a transactional manner to ensure that there is no over-deduction or under-deduction in concurrent deduction scenarios. The credit change transaction records record the complete details of each credit issuance and deduction operation in an append-only manner. Even if the account balance data is abnormal, the correct balance can be reconstructed through the transaction records.

[0114] The points balance cache keeps the current balance of the user's points account in memory, so that the carbon emission reduction quantification module can directly obtain the response from the cache when initiating identity anchoring query and the linkage settlement module can directly obtain the response from the cache when initiating available points query. This avoids the delay caused by accessing persistent storage for each query. The cache is kept synchronized with the account database storage, and the cache value is updated synchronously every time the points balance changes, ensuring the consistency between cached data and persistent storage data.

[0115] The travel data access module includes a protocol data access gateway, a passenger load factor collection unit, and a data cleaning and processing unit;

[0116] The multi-protocol data access gateway is equipped with multiple communication interfaces, supporting communication connections with dedicated lines of transportation operators, standard interfaces of navigation platforms, and in-vehicle IoT devices. Each interface works independently, and communication interruption of one data source does not affect the normal access of other data sources. The gateway has a built-in data buffer storage unit to temporarily store data to be processed when there is a delay in response from external data sources, preventing upstream delays from causing interruptions in carbon emission reduction quantification calculations.

[0117] The passenger load factor collection unit is deployed on the vehicle and collects the number of passengers in the carriage in real time through gravity sensors or infrared counters. After local preliminary verification, the data is reported to the data access gateway through the wireless communication module. The unit is equipped with a local buffer to temporarily store the collected data along with the collection timestamp during wireless signal interruption. The data is reported in batches after communication is restored to ensure that the data is not lost due to signal interruption.

[0118] The data cleaning and processing unit performs format standardization, outlier filtering, and missing value filling on the multi-source data collected by the gateway. It filters out abnormal data caused by sensor failures or communication errors to ensure that the travel data input to the carbon emission reduction quantification module meets the calculation requirements.

[0119] The payment channel module includes a payment interface server, a payment status tracking and storage unit, and a channel health monitoring unit;

[0120] The payment interface server is specifically responsible for establishing secure communication connections with external third-party payment systems. It is equipped with a hardware encryption processing unit to encrypt and decrypt all communication data, ensuring that fund operation instructions are not intercepted or tampered with during transmission. The server is connected to the transaction scheduler processor through an internal dedicated communication bus, isolating the external dependencies of currency settlement on independent hardware nodes, so that the operation of the currency ledger does not occupy the computing resources of the transaction scheduler processor.

[0121] The payment status tracking memory records the current status and historical change flow of each fund freeze, unfreeze, and refund operation. This information is used by the compensation mechanism processing unit to query the actual execution progress of the monetary operation when processing intermediate states involving monetary ledger rollback, and serves as the basis for determining whether a refund request needs to be re-initiated.

[0122] The channel health monitoring unit continuously sends probe requests to the external payment system to monitor the connectivity status and response latency of the channel. When the channel response latency exceeds the preset threshold, it issues an early warning to the transaction scheduling processor, enabling the system to obtain the prediction information of channel abnormality before the timeout window expires. This allows for a more accurate timeout determination during the pre-occupancy phase, reducing the probability of transactions entering a suspended state due to payment channel abnormalities.

[0123] The user interface of this system is as follows: Figure 5 As shown.

[0124] The content disclosed above is only a preferred and feasible embodiment of the present invention, and is not intended to limit the scope of protection of the present invention. Therefore, all equivalent technical changes made based on the content of the present invention specification and drawings are included within the scope of protection of the present invention. Furthermore, the elements therein can be updated as technology develops.

Claims

1. A green intelligent ticketing generation and settlement system supporting real-time carbon credit deduction, characterized in that, It includes a carbon emission reduction quantification module, a ticketing carbon credits linkage settlement module, a user and credits account management module, a travel data access module, and a payment channel module; The carbon emission reduction quantification module uses private car travel as the baseline emission reference, collects the user's actual travel mode, travel distance, real-time vehicle occupancy rate and energy consumption factor, calculates the carbon emission reduction of this trip through the difference algorithm, and converts the carbon emission reduction into carbon credits through the group scarcity dynamic conversion mechanism. The group scarcity dynamic conversion mechanism adopts a two-layer sliding time window to continuously count the green travel density within the platform. The short window is updated in a preset time unit to capture the real-time travel density at the current moment. The long window provides a stable density benchmark reference based on historical data of the same time period of a preset natural day. The current density reference value is obtained by weighting the short window density and the long window mean. Then, the scarcity index is obtained by comparing this value with the platform's historical peak density. The conversion coefficient and the scarcity index adopt a non-linear mapping relationship. The lower the scarcity index, the higher the conversion coefficient. When the scarcity index approaches 1, the conversion coefficient converges to the preset benchmark value. The conversion coefficient has upper and lower limits. The amount of points issued to a single user during a high coefficient period has an independent upper limit to prevent users from colluding to create false scarcity and obtain high coefficients. The final carbon credit is determined by the carbon emission reduction amount and the current conversion factor.

2. The green intelligent ticketing generation and settlement system supporting real-time carbon credit deduction as described in claim 1, characterized in that, The carbon emission reduction quantification module uses private car travel of the same distance as the carbon emission benchmark. It obtains the actual mode of travel, route distance, real-time passenger load factor and corresponding energy consumption factor of the trip from the travel data access module. It calculates the actual per capita carbon emission of the trip according to the ratio of carbon emission per unit distance to passenger load factor. Then, it subtracts the actual per capita carbon emission from the standard carbon emission of private cars of the same distance to obtain the carbon emission reduction of the trip, in grams of carbon dioxide equivalent. When real-time passenger load data is unavailable, the historical average passenger load for that route and time period is used as a downgraded alternative input to ensure continuous availability of the calculation.

3. The green intelligent ticketing generation and settlement system supporting real-time carbon credit deduction as described in claim 2, characterized in that, When the scarcity index experiences an abnormal drop beyond the normal fluctuation range within a preset time window, the carbon emission reduction quantification module uses a preset benchmark conversion factor instead of the dynamic conversion factor for integral calculation, suspends the normal operation of the group scarcity dynamic conversion mechanism, and resumes the dynamic conversion logic after the abnormality is verified and eliminated. The determination of the abnormal state is based on the historical fluctuation baseline of the scarcity index. When the abnormal state exceeds a preset multiple of the baseline, the substitution mechanism is triggered.

4. The green intelligent ticketing generation and settlement system supporting real-time carbon credit deduction as described in claim 3, characterized in that, After the carbon credits calculation is completed, the carbon emission reduction quantification module will package the travel data, real-time passenger load factor or downgrade replacement value, current scarcity index and its corresponding two-layer window statistical results, and final conversion factor, together with the user identity identifier and the timestamp uniformly issued by the server, into a credit traceability record. The timestamp is issued by the server rather than generated locally on the client, ensuring that in scenarios where travel data uploads are delayed in weak network environments, the anchor time reflects the moment when the server confirms the data integrity rather than the user's device's local time. The traceability records are stored in association with the corresponding ticket vouchers using hash values ​​as unique indexes, so that the source, calculation process, and group background of each carbon credit can be independently verified afterward.

5. A green intelligent ticketing generation and settlement system supporting real-time carbon credit deduction as described in claim 4, characterized in that, The ticketing carbon credit linkage settlement module redefines the three operations of ticket payment, carbon credit deduction, and ticket generation as the three constituent conditions of an atomic submission unit. After receiving a user's ticket purchase request, the system simultaneously initiates a pre-reservation operation to the payment channel, carbon credit account, and ticket generation service. If all three pre-reservations are successful, a unified submission is triggered. If any pre-reservation fails, all three are released simultaneously. Payment-side pre-holding is the freezing of funds for the monetary difference after deducting carbon credits from the ticket price; carbon credit-side pre-holding is the temporary locking of the corresponding number of credits, which cannot be used by other transactions during the locking period; ticketing-side pre-holding is the reservation of ticketing resources corresponding to this trip to prevent concurrent and duplicate allocation. The ticket voucher is generated the moment it is successfully submitted, and its generation timestamp is strictly consistent with the transaction submission timestamp. The traceability record hash value is written to the ticket voucher after successful submission, so that the ticket carries a verifiable index pointing to the complete carbon calculation process.

6. A green intelligent ticketing generation and settlement system supporting real-time carbon credit deduction as described in claim 5, characterized in that, The ticketing carbon credit linkage settlement module clearly distinguishes between two abnormal states: failure and timeout without response. Explicit failure means that one party returns a failure response before the timeout window expires. In this case, the system immediately sends a synchronization release command to all three parties to terminate the transaction. Timeout without response means that one party has not returned any response when the timeout window expires. At this time, the system sends a forced release command to the non-responding party and waits for confirmation. If the forced release confirmation times out, the transaction will be marked as suspended and handed over to the compensation mechanism for processing. When initiating a pre-occupancy, the system synchronously sends the uniformly calculated lock validity period as a parameter to the pre-occupancy command to all three parties, ensuring that the lock validity periods of the three parties are aligned under the same base time, and preventing inconsistencies such as some pre-occupancy being automatically released while others remain locked.

7. A green intelligent ticketing generation and settlement system supporting real-time carbon credit deduction as described in claim 6, characterized in that, The ticketing carbon credit linkage settlement module maintains an independent status tracking table for each ternary atomic transaction, recording the current status of the three parties' pre-occupation, the sending status of the submission instruction, and the confirmation results of each party. The update operation of the status tracking table ensures atomicity and maintains a version number for each record. The compensation mechanism scans suspended transactions in a polling manner and identifies four intermediate states by actively querying the current status of the three parties and comparing it with the status tracking table: the pre-allocation of currency has been released but the pre-allocation of carbon credits is still locked; the pre-allocation of carbon credits has been released but the pre-allocation of currency is still frozen; neither has been released but the ticket reservation is valid; and both have been released but the ticket reservation has not been released synchronously. An independent compensation path is executed for each state. The compensation path involving monetary refunds is executed in a fixed order of carbon credit release, ticket resource release, and monetary refund. If a refund request fails, it will be retried a preset number of times. After the number of retries is exceeded, it will be transferred to the manual processing queue.

8. A green intelligent ticketing generation and settlement system supporting real-time carbon credit deduction as described in claim 7, characterized in that, The ticketing carbon credit linkage settlement module generates a globally unique identifier for each compensation operation. When the three parties receive a compensation instruction, they use this identifier as the key to perform idempotency verification. For compensation operations that have already been processed, they directly return success without repeating the execution, ensuring that retries do not lead to the duplicate release of funds or credits. Before performing compensation operations, the compensation mechanism checks whether the version number of the corresponding record in the status tracking table has changed, to prevent compensation operations from being performed based on expired status.

9. A green intelligent ticketing generation and settlement system supporting real-time carbon credit deduction as described in claim 8, characterized in that, When a user's available carbon credits are insufficient to fully offset the amount, the number of carbon credits pre-allocated is capped at the actual available balance in the account, and the pre-allocated amount on the payment side is adjusted accordingly to the monetary difference between the ticket price and the value of the actual deductible carbon credits. Partial deduction and full deduction are completely consistent in the three-element atomic transaction structure, and the system does not need to maintain different processing logic for the two scenarios; Before the ternary atomic structure is activated, the carbon integral has been calculated by the carbon emission reduction quantification module, and the calculation result, along with the source traceability record hash value, is transmitted to this module.

10. A green intelligent ticketing generation and settlement system supporting real-time carbon credit deduction as described in claim 9, characterized in that, The user and points account management module is responsible for user registration, identity authentication, and the establishment and maintenance of carbon points accounts. It records the dynamic changes in points balance, provides an identity anchoring basis for the carbon emission reduction quantification module, and provides data support for the linkage settlement module to query available points and update balance. The travel data access module connects to transportation operators, navigation platforms or in-vehicle devices to obtain users’ original travel data in real time. When real-time passenger load factor is not available, it provides historical average data as a downgraded alternative input and serves as the data input source for the carbon emission reduction quantification module. The payment channel module connects to a third-party payment system to handle the freezing, clearing, and refunding of the monetary portion of the ticket price, forming a hybrid payment closed loop together with carbon credit deduction.

Images