A city digital right intelligent distribution method based on multi-source data fusion

Abstract

The present application relates to the technical field of urban right interest intelligent distribution, more specifically, the present application relates to a kind of urban digital right interest intelligent distribution method based on multi-source data fusion, platform is based on user state determines target digital right interest, performance path and resource demand;For not closed cross-system operation, according to the received event role and operation state conversion relationship establishes feasible terminal state resource contribution vector set, and is combined to form resource uncertain scene set and corresponding scene resource account book.Only when resource demand meets pre-occupancy condition in all valid scene account books, register resource pre-occupation and exclusive stable share synchronously, generate scene witness token. After the arrival of late event, shrink incompatible scene, when actual terminal state already exists in reserved scene, only confirm its resource contribution, when exceeding preset terminal state range, form resource gap and execute resource recovery. After token verification, write digital right interest into user account and associate performance path.

Description

Technical Field

[0001] This invention relates to the field of intelligent distribution technology of urban rights and interests, and more specifically, to an intelligent distribution method of urban digital rights and interests based on multi-source data fusion. Background Technology

[0002] With the development of city digital business cards, local life services, and smart cultural tourism platforms, digital coupons, scenic spot service benefits, digital tour guide benefits, travel photography benefits, and digital cultural and creative benefits are gradually being distributed collaboratively by user platforms, benefit platforms, merchant systems, and government and enterprise operation systems. The distribution of these digital benefits is not only affected by the user's current location, current stage of travel, and applicable conditions, but also by resource status constraints such as benefit inventory, merchant fulfillment capacity, regional distribution quotas, and service hours.

[0003] Existing platforms typically read inventory quantities, reserved capacity, or quota balances reported by each business system separately, and complete the distribution of benefits or resource pre-allocation when preset conditions are met. Because each system operates independently, related events may experience delays, out-of-order delivery, duplication, or omissions during transmission. The benefit inventory status and merchant capacity status read by the platform may not be complete states from the same business operation, leading to situations where benefits have been distributed but fulfillment capacity has not been confirmed, or capacity has been occupied but benefit inventory has not been deducted.

[0004] Some solutions involve setting safety margins, waiting for missing events, or readjusting resource status after a delayed event. Safety margins are typically set independently for individual resources, making it difficult to reflect the combined changes in equity inventory, merchant capacity, and regional quotas for the same reservation operation. Furthermore, the same operation may have multiple mutually exclusive final states, such as fulfillment by different acceptors, reservation failure, or transfer to an alternative service path. If resources are reserved separately based on the maximum adverse change for each resource, it's easy to include resource occupancy that cannot occur simultaneously, leading to excessive freezing of allocable resources.

[0005] Furthermore, when a late event occurs, existing solutions often rewrite the actual resource changes into the resource ledger, but the previously reserved amount for that event is not simultaneously cancelled, easily leading to duplicate deductions for the same resource change. If the latest state is directly overwritten with the original state, it is difficult to trace the cross-system operations and other related events corresponding to the change. When resources are insufficient, some platforms typically revoke all related rights or re-execute all distribution calculations, making it difficult to retain distribution tasks that still meet the performance conditions.

[0006] Therefore, we propose an intelligent distribution method for urban digital rights based on multi-source data fusion to solve the above problems. Summary of the Invention

[0007] In order to overcome the above-mentioned defects of the prior art, embodiments of the present invention provide a method for intelligent distribution of urban digital rights based on multi-source data fusion, so as to solve the problems mentioned in the background art.

[0008] To achieve the above objectives, the present invention provides the following technical solution: a method for intelligent distribution of urban digital rights based on multi-source data fusion, comprising: acquiring user-side state data and resource events sent by multiple resource systems, wherein the resource events carry cross-system operation identifiers, event roles, resource change vectors, and event states; determining the target digital rights, the current fulfillment path, and the corresponding resource demand vector based on the user-side state data; establishing unclosed operation records for cross-system operations that have not yet received final state events, determining the final states that cross-system operations can still enter and the resource contribution vectors corresponding to each final state based on the received event roles and preset operation state transition relationships, forming a set of feasible resource contribution vectors; selecting one resource contribution vector from each set of feasible resource contribution vectors of unclosed operations and combining them to form a set of resource uncertainty scenarios; establishing a scenario resource ledger for each resource uncertainty scenario, wherein the scenario resource ledger records the amount of closed resources, the total resource contribution amount of each unclosed operation in the scenario, the amount occupied, the amount pre-occupied, and the amount of allocable resources; and determining the resource demand vector in all resource uncertainty scenarios. When the pre-occupancy conditions are met in all corresponding scenario resource ledgers, the resource pre-occupancy of the current digital rights distribution task and its exclusive stable share that does not overlap with other tasks are simultaneously registered in each scenario resource ledger. A scenario witness token is generated that binds the version of the resource uncertainty scenario set, the registration index of each scenario resource ledger, and the current fulfillment path. In response to the arrival of late resource events or final state events of unclosed operations, the corresponding feasible resource contribution vector set is updated using cross-system operation identifiers and event roles, and resource uncertainty scenarios that are incompatible with resource events are deleted. When the resource contribution vector corresponding to the actual final state already exists in the retained resource uncertainty scenario, the resource contribution vector is changed from the candidate state to the confirmed state without superimposing the resource change vector again. When the actual resource contribution exceeds the feasible resource contribution vector set, a resource gap vector is formed and resource recovery processing is triggered. When the digital rights distribution task corresponding to the scenario witness token is still registered in all valid scenario resource ledgers, the resource pre-occupancy is in the submitted state, and there is no unprocessed resource gap, the target digital rights are written to the target user's digital rights account and associated with the current fulfillment path.

[0009] In a preferred embodiment, the resource event also carries a source system identifier, a source event sequence number, an event occurrence time, a platform reception time, and a resource object identifier; a resource event sequence is established according to the source system identifier and the resource object identifier, and duplicate events and sequence number gaps are identified using the source event sequence number; when the event corresponding to the sequence number gap can be attributed to an existing unclosed operation through a cross-system operation identifier, the sequence number gap is written into the corresponding unclosed operation record; when it cannot be attributed to the resource object involved in the target digital rights, the allocatable resource amount in the scenario resource ledger is not deducted based on the sequence number gap.

[0010] In a preferred embodiment, the preset operation state transition relationship includes: the initial state, candidate intermediate state, and final state of cross-system operation; the event roles required for each state transition; the resource contribution vector corresponding to each final state; and the mutual exclusion relationship between final states. The unclosed operation record also includes a set of received event roles and a set of event roles to be received. When a received event role causes a candidate final state to no longer meet the corresponding state transition condition, the resource contribution vector corresponding to the candidate final state is deleted from the set of feasible resource contribution vectors.

[0011] In a preferred embodiment, forming a resource uncertainty scenario set includes: combining a feasible resource contribution vector of each unclosed operation with feasible resource contribution vectors of other unclosed operations to form a total resource contribution vector; merging resource uncertainty scenarios with the same total resource contribution vector; when the total resource occupancy of the first resource uncertainty scenario is not less than the total resource occupancy of the second resource uncertainty scenario in each resource dimension, retaining the first resource uncertainty scenario and deleting the second resource uncertainty scenario; and using the retained resource uncertainty scenarios to form a resource uncertainty scenario set version.

[0012] In a preferred embodiment, the current digital rights distribution task is simultaneously registered in the resource ledgers of each scenario, including: reading the resource uncertainty scenario set version and the ledger version of each scenario resource ledger; writing pre-occupancy preparation records and dedicated stable share preparation records associated with the same digital rights distribution task identifier into each scenario resource ledger; when the allocable resources in each scenario resource ledger cover the resource demand vector and dedicated stable share, and the resource uncertainty scenario set version and ledger version have not changed, all preparation records are submitted uniformly; when any preparation record fails to meet the submission conditions, preparation records in other scenario resource ledgers are revoked, and no scenario witness token is generated.

[0013] In a preferred embodiment, updating the set of feasible resource contribution vectors includes: locating the corresponding unclosed operation record using the cross-system operation identifier of the late resource event, and updating the set of received event roles using event roles; redetermining the still reachable final state based on the updated set of received event roles; deleting resource contribution vectors whose corresponding final state is no longer reachable, and deleting resource uncertainty scenarios that contain at least one resource contribution vector; when a cross-system operation enters a unique final state, marking the resource contribution vector corresponding to the unique final state as a confirmed resource contribution vector, and closing the corresponding unclosed operation record.

[0014] In a preferred embodiment, when the actual resource change vector of a late resource event is consistent with the confirmed resource contribution vector, only the corresponding candidate resource contribution status is changed to the confirmed status; when the actual resource change vector is less than the confirmed resource contribution vector, the difference between the two is returned to the allocable resource amount in the reserved scenario resource ledger; when the actual resource change vector is greater than or does not meet the confirmed resource contribution vector, the difference between the two is used to form a corrected resource vector, and each valid scenario resource ledger is updated according to the corrected resource vector; when any scenario resource ledger cannot maintain the existing resource pre-occupancy after the update, the corresponding insufficient amount is written into the resource gap vector.

[0015] In a preferred embodiment, the resource recovery process includes: retrieving an alternative fulfillment path that can complete user qualification verification, service delivery, and write-off confirmation according to the fulfillment constraints carried by the scenario witness token; after completing the registration of resource pre-allocation and dedicated stable share in all valid scenario resource ledgers corresponding to the alternative fulfillment path, updating the fulfillment path bound to the scenario witness token and releasing the resource pre-allocation corresponding to the original fulfillment path; if there is still a resource gap after the fulfillment path is updated, determining the revocation set from the affected scenario witness tokens whose sum of resource release vectors is not less than the resource gap vector and contains the fewest tokens, and releasing the resource pre-allocation and dedicated stable share corresponding to the revocation set.

[0016] In a preferred embodiment, the scenario witness token further includes a digital rights distribution task identifier, a resource uncertainty scenario set version, a resource ledger registration index for each scenario, a resource pre-occupancy identifier, a single-use serial number, and a token validity period. Before writing the target digital rights into the target user's digital rights account, it is verified that each valid scenario resource ledger in the current resource uncertainty scenario set has a valid registration corresponding to the digital rights distribution task identifier, the resource pre-occupancy is in a submitted state, and the single-use serial number has not been used. When the target digital rights are completed and cancelled, the corresponding resource pre-occupancy is changed to an occupied state and the digital rights distribution task is closed. When the target digital rights are cancelled, expired, or the scenario witness token is revoked, the task registration in each valid scenario resource ledger is deleted, and the corresponding resource pre-occupancy and exclusive stable share are released. When the same resource event or task status event is received repeatedly, the status change is performed only once based on the cross-system operation identifier, event role, and source event sequence number.

[0017] The technical effects and advantages of this invention are as follows: This invention addresses situations where cross-system resource events are not fully closed. It establishes unclosed operation records on a per-system basis and saves the resource contribution vector corresponding to each feasible final state. Equity inventory, fulfillment service capacity, and other related resources are jointly expressed by the same resource contribution vector, which can preserve the mutual exclusion relationship between different final states and avoid duplicate counting of multiple resource occupancy events that cannot occur simultaneously.

[0018] This invention combines the feasible resource contribution vectors of each unclosed operation into a set of resource uncertainty scenarios and establishes a scenario resource ledger for each scenario. The digital rights distribution task only registers resource pre-allocation and dedicated stable shares when the resource requirements are met in all valid scenario resource ledgers, thus avoiding distribution decisions based solely on a single real-time inventory or a single fulfillment capacity.

[0019] Upon arrival of a late resource event or final state event, the feasible final states of the corresponding cross-system operations are shrunk by event roles, and incompatible resource scenarios are deleted. When the resource contribution corresponding to the actual final state is already included in the reserved scenario, only the candidate contribution is converted into a confirmed contribution, without adding resource changes again, which can prevent the same reservation, cancellation, or capacity occupancy from being deducted repeatedly.

[0020] When the actual resource contribution exceeds the pre-saved feasible final state range, the excess portion forms a resource gap, and the resource state is restored through alternative fulfillment paths or selective revocation. This process can preserve distribution tasks that still meet the fulfillment conditions, avoiding the overall revocation of established digital rights due to local resource anomalies.

[0021] The scenario witness token binds to uncertain scenario set versions, resource ledger registrations for each scenario, and current fulfillment paths. Before digital rights are written to a user's account, the task registration and resource pre-occupancy status in all valid scenarios are verified to ensure that the digital rights account status, cross-system resource status, and actual fulfillment paths correspond. Attached Figure Description

[0022] Figure 1 A schematic diagram of the data interaction and processing flow for the intelligent distribution method of urban digital rights. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] Reference Figure 1 A method for intelligent distribution of urban digital rights based on multi-source data fusion includes the following: This implementation method primarily focuses on distributing AI-powered travel photography digital rights within the ancient city scenic area. After a user enters the ancient city scenic area page through the city's digital name card, the user service system sends scenic area browsing events, user location events, and AI travel photography entry access events to the platform. User-side events include user anonymity identifier, status type, event occurrence time, platform reception time, validity period, and status version. The platform associates each user-side event according to the user anonymity identifier, retaining the status of the event with the later occurrence time that is still within the validity period for the same status type.

[0025] When a user's location is within the scenic area's service area, the scenic area is open, and the current time falls within the travel photography service period, the platform will determine the user's current city service status as a scenic area visit status. If a user's location event has expired, location statuses from different sources conflict, or the scenic area's openness has not yet been confirmed, no digital rights distribution tasks relying on that status will be generated.

[0026] The Digital Rights Center returns AI travel photography digital rights that match the scenic spot's visit status, while the redemption entity reservation system returns the service items, service hours, service areas, and fulfillment capacity of redemption entities A and B. After verifying the applicable objects, service hours, user qualifications, and user accessibility conditions, the platform selects the AI ​​travel photography digital rights as the target digital rights and determines the service path corresponding to redemption entity A as the current fulfillment path.

[0027] This digital rights distribution requires one unit of AI travel photography rights inventory, one travel photography service capacity of Acceptance Entity A, and one regional allocation quota for the current scenic spot night tour activity. The platform forms a resource demand vector according to the resource dimension dictionary, with each component corresponding to the AI ​​travel photography rights inventory, the service capacity of Acceptance Entity A, the service capacity of Acceptance Entity B, and the regional allocation quota, respectively. The unused service capacity component of Acceptance Entity B in the current fulfillment path is recorded as zero.

[0028] Resource events sent by the Digital Rights Center, the Acceptance Entity Reservation System, and the Regional Quota System include the source system identifier, resource object identifier, resource object event sequence number, cross-system operation identifier, event role, event status, resource change vector, event occurrence time, platform reception time, and status version.

[0029] Each source system maintains a monotonically increasing event sequence number for each resource object. When a source system uses a global message sequence number, the global message sequence number is only used for transmission deduplication and is not used as a basis for determining whether there is an event gap for the current resource object. The platform only establishes an event gap when the event sequence numbers of adjacent resource objects within the same source system and for the same resource object are not consecutive.

[0030] The platform uses a combination of the source system identifier, resource object identifier, and resource object event sequence number as the idempotency key for resource events. Resource events with the same idempotency key and a completed processing status will not be modified in the resource ledger. When a later event corresponding to the same idempotency key carries a higher state version, it will be treated as a state correction event and will not be repeatedly executed as a new resource event.

[0031] When a missing event sequence number appears in a resource object, the platform queries the source system for the cross-system operation identifier and event status corresponding to the missing sequence number. If the missing event can be attributed to an existing unclosed operation, the event gap identifier is written to the unclosed operation record. If the source system confirms that the missing sequence number does not belong to the current resource object, it does not reduce the allocatable resources of the current resource object.

[0032] After a user submits their travel photography reservation intention, the platform generates a unique cross-system operation identifier corresponding to this reservation and sends this identifier to the Digital Rights Center, the Acceptance Entity Reservation System, and the Regional Quota System. Rights inventory events, acceptance entity capacity events, and regional quota events generated by the same reservation operation all carry this cross-system operation identifier.

[0033] When a reservation operation has not yet reached a definite final state, the platform establishes an unclosed operation record. The unclosed operation record includes cross-system operation identifier, operation type, associated user anonymity identifier, digital rights distribution task identifier, current possible state set, received event role set, pending event role set, reachable final state set, resource contribution vector corresponding to each final state, event gap identifier, record version, and processing status.

[0034] The platform maintains an operation state transition table for AI travel photography booking operations. Each state transition records the previous state, triggering event role, event state conditions, target state, and excluding event role. Each final state also records the set of necessary event roles required to reach that final state, the set of event roles incompatible with that final state, and the corresponding resource contribution vector.

[0035] The event roles in this implementation include reservation requests, equity inventory pre-allocation, capacity pre-allocation by acceptor A, capacity pre-allocation by acceptor B, regional quota pre-allocation, reservation confirmation, reservation failure, reservation cancellation, and alternative performance confirmation.

[0036] The AI ​​travel photography booking process includes four final states: successful fulfillment by Entity A, successful fulfillment by Entity B, booking failure, and booking cancellation. The resource contribution vector corresponding to the successful fulfillment by Entity A is the occupation of one AI travel photography rights inventory, one service capacity of Entity A, and one regional allocation quota. The resource contribution vector corresponding to the successful fulfillment by Entity B is the occupation of one AI travel photography rights inventory, one service capacity of Entity B, and one regional allocation quota. The resource contribution vectors corresponding to the booking failure and booking cancellation final states do not include the final occupation of the aforementioned resources.

[0037] When determining a candidate final state, the platform first checks if the set of received event roles intersects with the set of incompatible event roles for that final state. If an intersection exists, the candidate final state cannot be reached further. If no intersection exists, the platform then checks if there is a path in the current set of possible states that conforms to the state transition table and can lead to that final state. If at least one path exists, the candidate final state is retained, and the missing event roles for that path are added to the set of event roles to be received.

[0038] When all the necessary event roles required for a candidate final state have been received, the current state can enter that final state, and all other candidate final states are excluded due to incompatible event roles or state transition conditions, that final state is confirmed as the unique final state.

[0039] When the platform receives only a reservation request event but not yet a confirmation event from the acceptor, successful performance by acceptor A, successful performance by acceptor B, reservation failure, and reservation cancellation are all reachable final states. The resource contribution vectors corresponding to these final states collectively constitute the set of feasible resource contribution vectors for this open-ended operation.

[0040] After acceptor A returns a rejection event, if the set of incompatible event roles for the rejection event intersects with the set of incompatible event roles for acceptor A's successful performance, the platform will delete the successful performance state for acceptor A. If acceptor B returns a confirmation event, and both the reservation failure and reservation cancellation states have been excluded, the successful performance state for acceptor B will be recognized as the unique final state.

[0041] The platform expands resource-uncertain scenarios sequentially according to the order of cross-system operation identifiers. At the start of expansion, an initial scenario with a resource contribution vector of zero is created. When processing the first unclosed operation, the initial scenario is combined with each candidate final state of that operation; when processing subsequent unclosed operations, the currently valid scenario is combined with each candidate final state of that operation. After each unclosed operation expansion is completed, identical vector merging and dominant scenario pruning are immediately performed before processing the next unclosed operation, without first generating all final state combinations.

[0042] For each resource-uncertain scenario, a total resource contribution vector and a scenario support tuple are stored. The scenario support tuple consists of the cross-system operation identifiers of each unclosed operation and their candidate final state identifiers, indicating which candidate final states form the scenario.

[0043] When different scenarios have the same total resource contribution vector, they are merged into one scenario, and their respective scenario support tuples are written into the support tuple set of the merged scenario. Merging identical vectors does not delete the source record of the candidate final state combination.

[0044] When the total resource consumption of the first scenario is no less than that of the second scenario in every resource dimension, the first scenario imposes a resource constraint on newly distributed tasks that is no less than that of the second scenario. The platform will transfer the second scenario from the current valid scenario set to a covered state and establish a coverage record. The coverage record includes the covered scenario identifier, the covered scenario identifier, the resource contribution vectors of the two scenarios, and the scenario support tuples, without physically deleting the covered scenario.

[0045] When a late event causes a covered scenario to lose all valid scenario support tuples, the platform re-examines the corresponding covered scenario. If the covered scenario still has at least one valid scenario support tuple and is not dominated by other valid scenarios, it is restored to the current set of valid scenarios. This avoids missing potential resource states after the dominant scenario fails.

[0046] When different scenarios have high resource consumption across different resource dimensions, no dominance pruning is performed. For example, if one scenario mainly consumes the service capacity of acceptor A, and another scenario mainly consumes the service capacity of acceptor B, and a one-way dominance relationship cannot be determined between the two, both scenarios are retained as valid scenarios.

[0047] After scene merging and trimming, the platform generates a resource-determined scene set version. The version record includes the currently active scene, covered scenes, supported tuples for each scene, the previous version identifier, and the version change type. New scene set versions are generated when scenes are added, deleted, restored, or when resource contribution vectors change.

[0048] After incremental expansion, merging of identical vectors, and dominance pruning, if the number of current valid scenarios still exceeds the processing limit in the scenario configuration table, the platform stops generating scenario witness tokens for new tasks that depend on this scenario set. Existing tasks continue to be validated according to the original valid scenarios. After new resource events reduce the candidate final states, the platform regenerates the scenario set. The platform does not replace complete valid scenarios with randomly sampled scenarios.

[0049] The platform establishes a scenario resource ledger for each valid scenario. Each resource field in the scenario resource ledger is associated with a resource settlement sequence number. The closed resource quantity represents the allocatable balance of the corresponding resource confirmed by the system at that resource settlement sequence number, which already includes the impact of all closed resource events prior to that settlement sequence number.

[0050] The resource allocation, pre-allocated resource allocation, pre-allocated resource allocation to be submitted, resource contribution from unclosed operations, and dedicated stable share only record the incremental amount of resources after the resource settlement sequence number that has not yet been incorporated into the closed resource amount. When the resource system releases a new closed balance, the platform first identifies the resource events and task records that have been absorbed by the new closed balance, marks the corresponding incremental records as carried forward, and then updates the closed resource amount and resource settlement sequence number. Carried-forward records will no longer participate in the deduction of allocable resource amount.

[0051] The scenario resource ledger should at least record the closed resource quantity, resource settlement sequence number, occupied quantity after the settlement sequence number, submitted pre-occupied quantity, pre-occupied quantity to be submitted, total resource contribution of each unclosed operation in the scenario, existing task-specific stable share, allocable resource quantity, and ledger version.

[0052] The allocatable resource quantity for each resource dimension is determined by the closed resource quantity of that dimension minus the settlement sequence number, the occupied quantity, the submitted pre-occupied quantity, the pre-occupied quantity to be submitted, the resource contribution of unclosed operations in the current scenario, and all valid dedicated stable shares. Each deduction item carries a source event identifier or a digital rights distribution task identifier, and the same identifier can only enter one unsettled deduction item.

[0053] The scenario resource ledger is a parallel logical resource view. Pre-allocation records for the same digital rights distribution task in different scenario resource ledgers all reference the same coupled pre-allocation identifier, indicating the feasibility registration of the same physical pre-allocation in each possible scenario. The external resource system performs an actual pre-allocation only once for this coupled pre-allocation identifier, and does not repeatedly occupy physical resources as the number of scenarios increases.

[0054] The dedicated stable share is independent of resource demand. Resource demand represents the equity inventory, fulfillment capacity, and regional quota that must be actually reserved for the current mission; the dedicated stable share represents the resource volatility tolerance that is reserved solely for this mission before mission closure and cannot be reused by other missions.

[0055] This implementation uses closed-loop tasks with the same resource object within the last thirty days as historical samples. For each historical task, the maximum adverse resource adjustment caused by events other than the task itself during the period from resource pre-allocation submission to task closure is counted and used as a sample value. When the number of samples is not less than thirty, the sample values ​​are sorted in ascending order, and the value covering 95% of the samples is taken as the initial dedicated stable share for the corresponding resource dimension; when the number of samples is less than thirty, the maximum adverse adjustment in the existing samples is taken.

[0056] The resource type configuration table also records the minimum unit of measurement for dedicated stable shares. If the calculated result is not an integer multiple of the minimum unit of measurement, it is rounded up to the adjacent unit of measurement. If no adverse historical adjustments have occurred and resources can be confirmed in real time, the dedicated stable share for this dimension can be zero.

[0057] Each scenario's resource ledger sets a public stable reserve. Dedicated stable shares are transferred from the public stable reserve of the corresponding resource dimension, with each transfer generating a unique share index. The share index records the resource object identifier, digital rights distribution task identifier, initial share, cumulative deduction, remaining share, and share status. The same quantity within the same public stable reserve can only be referenced by one valid share index.

[0058] When a task is closed, canceled, or a token is revoked, the remaining shares in the share index will be returned to the corresponding public stable balance, and the share index will be closed. Shares consumed by resource correction will not be returned.

[0059] The platform checks the resource requirement vector and the proposed dedicated stable share for the current task dimension by dimension in the resource ledger of all valid scenarios. If any resource dimension of any valid scenario cannot simultaneously cover both the resource requirement and the dedicated stable share, the pre-allocation submission process will not begin.

[0060] When all valid scenarios meet the conditions, the platform establishes a unified pre-allocation transaction record. The unified pre-allocation transaction record includes the transaction identifier, the digital rights distribution task identifier, the resource uncertainty scenario set version, the resource ledger version for each scenario, the coupled pre-allocation identifier, the list of external resource objects, and the transaction status.

[0061] The unified pre-allocation transactions are sequentially used in the following states: created, ledger prepared, partially pre-allocated external resources, fully pre-allocated external resources, ledger committed, in compensation, and terminated.

[0062] When a transaction is in the created state, the platform reads the resource uncertainty scenario set version and the resource ledger version for each scenario, and writes a pre-occupancy preparation record and a dedicated stable share preparation record to each valid scenario resource ledger. The preparation record includes the transaction identifier, digital rights distribution task identifier, resource demand vector, share index, ledger version, and preparation status.

[0063] Once all preparation records have been successfully written, and the scenario set version and ledger version remain unchanged, the transaction is changed to the ledger prepared state. If any ledger version changes or resources become insufficient, the written preparation records are revoked and the transaction is marked as terminated.

[0064] When a transaction is in the ledger-ready state, the platform sends resource pre-allocation requests to the Digital Rights Center, the current acceptance entity reservation system, and the regional quota system, respectively, carrying the coupled pre-allocation identifier. The external resource system uses the coupled pre-allocation identifier and the resource object identifier as idempotent keys.

[0065] When partial external resource pre-allocation is successful, the transaction records the successfully acquired resource object and enters the partial external resource pre-allocation state; when all external resources are successfully pre-allocated, the transaction enters the full external resource pre-allocation state.

[0066] After all external resources are pre-allocated, the platform re-checks the versions of the resource uncertainty scenario set and the resource ledger versions for each scenario. If the versions remain unchanged, the preparation records in each scenario resource ledger are uniformly converted to committed records, and the transaction status is changed to ledger committed. Scenario witness tokens are only allowed to be generated after the ledger is successfully committed.

[0067] If any external resource pre-allocation fails, transaction processing times out, or the ledger version changes before commit, the transaction enters a compensation state. The platform sends release requests for external resources that have been successfully pre-allocated, and the release requests continue to use the original coupled pre-allocation identifier. After all successfully pre-allocated resources have been confirmed for release, the preparation records in the resource ledgers of each scenario are revoked, the transferred but unconsumed dedicated stable shares are returned, and the transaction is marked as terminated.

[0068] After the platform resumes operation, it scans transactions in the ledger-prepared, partially reserved, and fully reserved external resource states. The platform queries the current reserved status of each external resource system using the coupled reserved identifier. If all external resources are in the reserved state and the scenario set version and ledger version still meet the commit conditions, the ledger commit continues; otherwise, it enters the compensation process. This avoids the simultaneous existence of partial physical reserved and unknown ledger states after a system interruption.

[0069] Once the unified pre-occupancy transaction is in the ledger committed state, the platform generates a scenario witness token. The scenario witness token includes a digital rights distribution task identifier, a target user anonymity identifier, a target digital rights identifier, a current fulfillment path identifier, a resource uncertain scenario set version, a ledger registration index for each valid scenario resource, a coupled pre-occupancy identifier, a dedicated stable share index, a single-use sequence number, a token validity period, and a token verification value.

[0070] The validity period of the scenario witness token shall not be later than the earliest of the following: the expiration time of the target digital rights, the end time of the current performance path service, and the expiration time of the external resource pre-occupancy.

[0071] When a new version is formed from a set of scenarios with uncertain resources, the platform records the version inheritance relationship between the old and new versions. The new version only deletes scenarios that are incompatible with the received events. If no new scenarios are added and the resource contribution vector of any valid scenario is not increased, it is marked as a contracted version.

[0072] When a scenario witness token is bound to an older version and the current version is a continuously shrinking version of that older version, the token verification service checks whether there is still a valid registration of the corresponding digital rights distribution task in all currently valid scenario resource ledgers. If all registrations exist and there is no resource gap, the old token can continue to be used along the version inheritance relationship.

[0073] When a new version adds a valid scenario, restores an existing covered scenario, or increases the resource contribution of any scenario, it is marked as an extended or revised version. The platform suspends the use of scenario witness tokens bound to the old version and adds task registration to the resource ledger of the newly added or revised scenario. When all newly added or revised scenarios meet the resource conditions, scenario witness tokens bound to the new version are reissued; if they do not meet the conditions, a resource gap is created and resource recovery processing begins.

[0074] When a late resource event corresponding to an unclosed operation arrives, the platform first performs an idempotency check, and then locates the unclosed operation record based on the cross-system operation identifier. Non-final state resource events only update the set of received event roles, the set of current possible states, and the set of reachable final states; they do not directly convert candidate resource contributions into confirmed resource contributions.

[0075] The platform checks each scenario's supporting tuples item by item. If a scenario's supporting tuple contains a candidate final state that has been excluded, the supporting tuple is deleted. A merged scenario remains valid as long as it retains at least one valid scenario supporting tuple; if all supporting tuples are deleted, the scenario is removed from the set of valid scenarios, and its associated covering and covered scenarios are re-checked.

[0076] When a cross-system operation has only one reachable final state, or when the platform receives a final state event that matches the state transition table, it determines and confirms the final state and the actual resource change vector. The platform then locates the candidate resource contribution vector that originally corresponded to the cross-system operation in each valid scenario.

[0077] When the resource contribution vector in the final state is consistent with the original candidate resource contribution vector in the scene, the resource contribution is changed from the candidate state to the confirmed state. In the ledger, this is reflected as the resource contribution field of the unclosed operation being moved to the occupied field after the settlement sequence number, and the allocable resource amount is not deducted a second time.

[0078] When the actual resource change vector and the candidate resource contribution vector are not completely consistent, the platform calculates the difference between the actual occupancy and the candidate occupancy for each resource dimension. A positive difference indicates that the actual occupancy exceeds the candidate occupancy, a negative difference indicates that the candidate occupancy is higher than the actual occupancy, and a difference of zero indicates that no adjustment is needed for that dimension.

[0079] Positive discrepancies are deducted from the allocable resources in the corresponding scenario's resource ledger or the remaining dedicated stable share for the current task. The absolute value of negative discrepancies is returned to the common stable balance or allocable resources in the corresponding scenario's resource ledger. Positive and negative discrepancies across different resource dimensions are processed separately and do not cancel each other out.

[0080] When a real resource change vector contains both positive and negative differences, the platform first transitions the candidate resource contributions of each dimension to the confirmed resource contributions, and then registers resource increase records and resource return records respectively. Each record is associated with a cross-system operation identifier, a final state event idempotent key, and the original scenario support tuple.

[0081] When the actual final state does not belong to the original set of feasible final states, the platform does not select a single candidate resource contribution vector as a unified comparison benchmark. Instead, in each valid scenario, it uses the candidate resource contribution vector originally included for that cross-system operation as the benchmark and calculates the difference between the actual resource change vector and the candidate vector. After each valid scenario is updated, the same vectors are merged and the dominance relationship is reviewed.

[0082] If the resource ledger for any valid scenario cannot maintain the existing resource pre-occupancy and dedicated stable share after processing the positive difference, the corresponding shortfall will be written into the resource gap vector. The components of the resource gap vector correspond to equity inventory, capacity of different accepting entities, and regional quotas, respectively, and do not offset across dimensions.

[0083] When the resource gap vector has a non-zero component, the platform first searches for alternative fulfillment paths. The platform saves fulfillment contract records for each fulfillment path. The fulfillment contract records include at least the service item code, service quantity unit, user qualification verification rule identifier, service time period, service area, reservation interface type, verification voucher type, and cancellation conditions.

[0084] The candidate alternative path meets the performance conditions when the service item code is consistent with the original path, the number of services is not less than that of the original path, the user qualification verification rules are the same or there is a pre-registered equivalent mapping, the service period covers the performance period of the original task, and the cancellation voucher can be identified by the digital rights account system.

[0085] The platform uses the user's last remaining valid location status, candidate alternative fulfillment locations, and route time data to determine the estimated arrival time. If the estimated arrival time plus the fulfillment preparation time is no later than the expiration date of the scenario witness token, the candidate alternative path meets the reachability condition.

[0086] When a candidate alternative path simultaneously meets both the fulfillment content conditions and the reachability conditions, the platform checks the resource requirements and dedicated stable share of the alternative path in the resource ledger of all valid scenarios. If all valid scenarios are satisfied, a new unified pre-allocation transaction is established to first complete the pre-allocation of alternative path resources and registration in the scenario ledger.

[0087] After all alternative path pre-allocations and ledger registrations are submitted, the current fulfillment path and the ledger registration indexes for each scenario in the scenario witness token are updated, and then the resource pre-allocations and remaining dedicated stable shares of the original fulfillment path are released. If the alternative path submission fails, the resources of the original path are not released.

[0088] After the fulfillment path migration, the platform reads the actual release volume of the original path and the newly added occupancy volume of the alternative path according to the resource dimension. The release volume of the original path minus the newly added occupancy volume of the alternative path is the net release volume of the migration in that dimension. The corresponding component of the resource gap vector only deducts the positive net release volume of the migration; when the newly added occupancy volume of the alternative path is greater than the release volume of the original path, the excess part is added to the corresponding resource gap component.

[0089] If a resource gap still exists after migration, a revocation candidate set is established from the scenario witness tokens related to resources with non-zero gaps. Tokens that have already been written off or have entered an irreversible fulfillment state are not included in the candidate set.

[0090] Each candidate token records the resource release vector that can be actually released after its revocation. The platform searches layer by layer from the beginning according to the number of candidate tokens. When searching for a token combination, the resource release vectors of each token in the combination are added together dimension by dimension.

[0091] During the search process, if the sum of the current cumulative release amount and the maximum remaining release amount that the unselected candidate tokens can provide in each dimension still cannot cover the resource gap, the search branch is terminated. After finding a combination that covers the resource gap dimension by dimension for the first time at a certain layer, the search for combinations containing more tokens is stopped, thereby ensuring that the number of tokens in the revocation set is minimized.

[0092] When multiple combinations exist under the same minimum token quantity, the task combination that has not yet been written to the digital rights account or claimed by the user is selected first. When the task stages are the same, the release amount exceeding the gap in each resource dimension is compared, and the combination with the smaller sum of normalized excess release amount is selected. During normalization, the excess release amount in each dimension is divided by the corresponding resource gap amount; dimensions with a resource gap amount of zero are not included in the comparison.

[0093] Once the cancellation set is determined, the platform closes the corresponding scenario witness token, deletes its task registration in the resource ledger of all valid scenarios, and releases the corresponding pre-allocated physical resources and remaining dedicated stable shares. Tasks not included in the cancellation set retain their original scenario registration and token status.

[0094] After receiving a rights write request, the digital rights account system verifies the token verification value, validity period, and single-use serial number of the scenario witness token. It then reads the current resource uncertain scenario set version and its version inheritance relationship with the token-bound version.

[0095] If the current version is a contracted version of the token-bound version, check one by one to ensure that the digital rights distribution task is validly registered in the resource ledger of each valid scenario. If the current version is an extended or revised version and the token has not been reissued, refuse to write rights.

[0096] Account write verification also includes external resource pre-allocation being in a committed state, the dedicated stable share index still being valid, the current fulfillment path being consistent with the token record, no unprocessed resource gaps associated with the task, and the single-use sequence number not being used.

[0097] When all conditions are met, the target digital rights, current fulfillment path, rights validity period, reservation entry, and redemption voucher index will be written into the target user's digital rights account, and the single-use serial number will be marked as used.

[0098] If any condition is not met, the account system will refuse to write and return a failure condition identifier. The platform will not submit write requests repeatedly with the original single-use serial number.

[0099] When a target digital right is redeemed, the corresponding pre-allocated resources will be changed to an occupied state, and the digital right distribution task and scenario witness token will be closed. When a target digital right is canceled, expired, or a scenario witness token is revoked, the task registration in each valid scenario resource ledger will be deleted, and the unused physical resource pre-allocation and remaining exclusive stable share will be released.

[0100] All write-offs, cancellations, invalidations, revocations, and resource events use an idempotent processing key composed of a cross-system operation identifier, event role, resource object event sequence number, and digital rights distribution task identifier. The same idempotent processing key can only be used to execute one ledger status change.

[0101] When a resource object event sequence number is missing for an extended period, the platform sends an event replacement request to the source system. If the source system confirms that the missing event does not exist, the operation has been cancelled, or the event sequence number has been discarded, it returns a sequence number skip confirmation record. The sequence number skip confirmation record includes the source system identifier, resource object identifier, missing event sequence number, cross-system operation identifier, skip reason, source status version, and confirmation time.

[0102] After verifying the sequence number skips the confirmation record, the platform closes the corresponding event gap and continues to advance the event sequence of the resource object. If the source system does not return a sequence number skip confirmation record, it is not directly assumed that the missing event did not occur. If the gap cannot be closed even after reaching the latest token generation time allowed by the relevant task, token generation for new tasks that depend on the event gap is paused.

[0103] When a corresponding old event is received again after a sequence number has been skipped, the platform compares the old event's state version with the source state version in the sequence number skip confirmation record. If the old event's state version is not higher than the skip confirmation version, it will not be executed; if the old event's state version is higher, it will be treated as a state correction event, and the affected tokens will be suspended until the scenario and ledger review is completed.

[0104] In the digital tour guide benefits scenario, shared resources include the digital tour guide benefits inventory, the concurrent capacity of tour guide service nodes, and the scenic area quota. Candidate final states include tour guide service node A, tour guide service node B, and activation failure. Different service nodes correspond to mutually exclusive fulfillment paths, which are still handled according to the feasible final state resource contribution vector, resource uncertainty scenarios, and full-scenario pre-occupancy methods.

[0105] In the context of digital cultural and creative rights and interests, shared resources include digital cultural and creative product distribution inventory, copyright licensing quotas, and content distribution channel capacity. Candidate final states include successful claim, failed eligibility verification, and canceled claim. The successful claim final state occupies the distribution inventory and copyright licensing quota; other final states do not result in corresponding final occupancy.

[0106] To verify the joint expression of mutually exclusive final states, the late event confirmation, and the selective revocation process, this implementation provides the following recalculated calculation example.

[0107] The resource dimensions are, in order: AI travel photography rights inventory, service capacity of accepting entity A, service capacity of accepting entity B, and regional allocation quota. The platform has four open-ended reservation operations, each with three candidate final states: the resource contribution vector corresponding to the fulfillment final state of entity A is [1, 1, 0, 1], the resource contribution vector corresponding to the fulfillment final state of entity B is [1, 0, 1, 1], and the resource contribution vector corresponding to the reservation failure final state is [0, 0, 0, 0].

[0108] When each of the four operations selects a candidate final state, a total of eighty-one final state combinations are formed. After merging according to the resource contribution vector, fifteen different aggregate resource contribution vectors are formed. After performing dominant scene pruning, there are currently five effective non-dominated scenes, with resource contribution vectors of [4, 4, 0, 4], [4, 3, 1, 4], [4, 2, 2, 4], [4, 1, 3, 4], and [4, 0, 4, 4], respectively. The remaining scenes are retained as covered states and scene support tuples are saved.

[0109] If an independent safety margin method is adopted, taking the maximum unfavorable value for each resource, each unclosed operation simultaneously reserves one portion of capacity for both acceptor A and acceptor B. The four operations will simultaneously freeze four portions of capacity A and four portions of capacity B, for a total of eight portions of service capacity.

[0110] In this implementation, under any scenario with uncertain effective resources, each unclosed operation can only enter one of the following final states: fulfillment by A, fulfillment by B, or failure. The sum of the capacity occupancy of A and B does not exceed four parts. Under this specific input condition, the maximum amount of mutually exclusive service capacity frozen in the scenario is four parts, rather than eight parts frozen simultaneously. This result is directly calculated from the mutual exclusion relationship of the candidate final states and the scenario resource contribution vector.

[0111] Suppose the actual final states of the four unclosed operations are, in order, A fulfills, B fulfills, and reservation fails. The total actual confirmed resource contribution is [3, 2, 1, 3]. When using the control method of not writing off reserved quantities and directly superimposing late final state events, the three successful final states will be written into the inventory, corresponding service capacity, and regional quota again on the basis of the already registered candidate resource contributions, resulting in a total of nine duplicate resource component deductions.

[0112] When using this implementation method, the candidate resource contributions of the three successful final states are respectively moved to confirmed resource contributions, and the candidate contributions corresponding to the failed reservation final state are deleted or returned. The actual resource changes are not superimposed again, and the number of times duplicate resource components are deducted is zero.

[0113] Assume that the confirmed available capacity of accepting entity A is reduced by two units, forming a resource gap vector [0, 2, 0, 0]. Currently, there are three unverified scenario witness tokens for the path of accepting entity A. Each token can release one unit of A's capacity after being revoked, and accepting entity B still has one unit of pre-occupied capacity.

[0114] The platform first migrates one of the tokens from Path A to Path B of the accepting entity. The migration releases one unit of Path A capacity and adds one unit of Path B capacity, updating the resource gap to [0, 1, 0, 0]. Subsequently, revoking either of the remaining two Path A tokens will release one unit of Path A capacity and close the resource gap.

[0115] Under the specific conditions described above, this implementation revoks one scenario witness token; when using the comparative approach of revoking all affected path A tokens, three tokens need to be revoked. This calculation example is used to illustrate the execution process of alternative fulfillment path migration and minimum revocation set, and does not imply that the same reduction ratio applies under other resource conditions.

[0116] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for intelligent distribution of urban digital rights based on multi-source data fusion, characterized in that, include: Acquire user-side status data and resource events sent by multiple resource systems. Resource events carry cross-system operation identifiers, event roles, resource change vectors, and event status. Determine the target digital rights, current fulfillment path, and corresponding resource demand vector based on user-side status data; For cross-system operations that have not yet received a final state event, an unclosed operation record is established. Based on the roles of the received events and the preset operation state transition relationship, the final states that the cross-system operation can still enter and the resource contribution vectors corresponding to each final state are determined, forming a set of feasible resource contribution vectors. Select one resource contribution vector from the set of feasible resource contribution vectors for each unclosed operation and combine them to form a set of resource uncertainty scenarios; establish a scenario resource ledger for each resource uncertainty scenario, which records the amount of closed resources, the total resource contribution of each unclosed operation in the scenario, the amount occupied, the amount pre-occupied, and the amount of allocable resources. When the resource demand vector meets the pre-occupancy conditions in the scenario resource ledgers corresponding to all resource uncertain scenarios, the resource pre-occupancy of the current digital rights distribution task and the exclusive stable share that does not overlap with other tasks are simultaneously registered in each scenario resource ledger, and a scenario witness token that is bound to the resource uncertain scenario set version, the registration index of each scenario resource ledger and the current performance path is generated. In response to the arrival of late resource events or final state events of unclosed operations, update the corresponding feasible resource contribution vector set using cross-system operation identifiers and event roles, and delete resource uncertainty scenarios that are incompatible with resource events; actual When the resource contribution vector corresponding to the final state already exists in the reserved resource uncertainty scenario, the resource contribution vector is changed from the candidate state to the confirmed state without superimposing the resource change vector again. When the actual resource contribution exceeds the set of feasible resource contribution vectors, a resource gap vector is formed and resource recovery processing is triggered. When the digital rights distribution task corresponding to the scene witness token is still registered in all valid scene resource ledgers, the resource pre-occupancy is in the submitted state and there is no unprocessed resource gap, the target digital rights will be written to the target user's digital rights account and associated with the current performance path.

2. The method for intelligent distribution of urban digital rights based on multi-source data fusion according to claim 1, characterized in that: Resource events also carry the source system identifier, source event sequence number, event occurrence time, platform reception time, and resource object identifier; Establish a resource event sequence based on the source system identifier and resource object identifier, and use the source event sequence number to identify duplicate events and sequence number gaps; If the event corresponding to the sequence number gap can be attributed to an existing unclosed operation through cross-system operation identification, the sequence number gap will be written into the corresponding unclosed operation record; if it cannot be attributed to the resource object involved in the target digital rights, the allocatable resource amount in the scenario resource ledger will not be deducted based on the sequence number gap.

3. The method for intelligent distribution of urban digital rights based on multi-source data fusion according to claim 1, characterized in that: The preset operation state transition relationships include: The initial state, candidate intermediate state, and final state of cross-system operations; Event roles required for each state transition; Resource contribution vectors corresponding to each final state; Mutual exclusion between final states; The unclosed operation record also includes a set of received event roles and a set of event roles to be received; when a received event role causes a candidate final state to no longer satisfy the corresponding state transition condition, the resource contribution vector corresponding to the candidate final state is deleted from the set of feasible resource contribution vectors.

4. The method for intelligent distribution of urban digital rights based on multi-source data fusion according to claim 1, characterized in that: This forms a set of resource uncertainty scenarios, including: Combine the feasible resource contribution vector of each unclosed operation with the feasible resource contribution vectors of other unclosed operations to form the total resource contribution vector; Merge resource uncertainty scenarios with the same total resource contribution vector; When the total resource consumption of the first resource uncertainty scenario is not less than the total resource consumption of the second resource uncertainty scenario in all resource dimensions, retain the first resource uncertainty scenario and delete the second resource uncertainty scenario. A resource uncertainty scenario set version is formed by utilizing the retained resource uncertainty scenarios.

5. The method for intelligent distribution of urban digital rights based on multi-source data fusion according to claim 1, characterized in that: Synchronously register the current digital rights distribution tasks in the resource ledgers of each scenario, including: Read the version of the resource uncertain scenario set and the ledger version of the resource ledger for each scenario; Write the pre-occupancy preparation record and the exclusive stable share preparation record associated with the same digital rights distribution task identifier into the resource ledger of each scenario respectively; All available resources in each scenario's resource ledger cover the resource demand vector and dedicated stable share. When the resource uncertainty scenario set version and ledger version remain unchanged, all preparation records are submitted uniformly. If any preparation record fails to meet the submission conditions, the preparation records in other scenario resource ledgers will be revoked, and no scenario witness token will be generated.

6. The method for intelligent distribution of urban digital rights based on multi-source data fusion according to claim 1, characterized in that: Update the set of feasible resource contribution vectors, including: Use the cross-system operation identifier of late resource events to locate the corresponding unclosed operation record, and use event roles to update the set of received event roles; The still reachable final state is redefined based on the updated set of received event roles; Delete resource contribution vectors whose final states are no longer reachable, and delete resource uncertainty scenarios that contain at least one resource contribution vector; When a cross-system operation enters a unique final state, the resource contribution vector corresponding to the unique final state is marked as a confirmed resource contribution vector, and the corresponding unclosed operation record is closed.

7. The method for intelligent distribution of urban digital rights based on multi-source data fusion according to claim 6, characterized in that: When the actual resource change vector of a late resource event is consistent with the confirmed resource contribution vector, only the corresponding candidate resource contribution status is changed to the confirmed status. When the actual resource change vector is less than the confirmed resource contribution vector, the difference between the two will be returned to the allocable resource amount in the reserved scenario resource ledger; When the actual resource change vector is greater than or does not meet the confirmed resource contribution vector, the difference between the two is used to form a corrected resource vector, and the resource ledger of each effective scenario is updated based on the corrected resource vector. If the updated resource ledger cannot maintain the existing resource pre-occupancy, the corresponding shortfall will be written into the resource gap vector.

8. The method for intelligent distribution of urban digital rights based on multi-source data fusion according to claim 1, characterized in that: Resource recovery processing includes: The search function can retrieve alternative fulfillment paths that complete user qualification verification, service delivery, and write-off confirmation based on the fulfillment constraints carried by the scenario witness token. After completing the registration of resource pre-occupancy and exclusive stable share in all valid scenario resource ledgers corresponding to the alternative performance path, update the performance path bound to the scenario witness token and release the resource pre-occupancy corresponding to the original performance path. If a resource gap still exists after the fulfillment path is updated, determine the revocation set from the affected scenario witness tokens. The set with the smallest sum of resource release vectors that is not less than the resource gap vector and contains the fewest tokens is revoked. Then release the resource pre-occupancy and exclusive stable share corresponding to the revocation set.

9. The method for intelligent distribution of urban digital rights based on multi-source data fusion according to claim 1, characterized in that: The scenario witness token also includes a digital rights distribution task identifier, a resource uncertain scenario set version, a resource ledger registration index for each scenario, a resource pre-occupancy identifier, a single-use serial number, and a token validity period; Before writing the target digital rights into the target user's digital rights account, verify that each valid scenario resource ledger in the current resource uncertainty scenario set has a valid registration corresponding to the digital rights distribution task identifier, that the resource pre-occupancy is in the submitted state, and that the single-use serial number has not been used. When the target digital rights are completed and the pre-occupancy of the corresponding resources is changed to the occupied state and the digital rights distribution task is closed; when the target digital rights are canceled, expired or the scene witness token is revoked, the task registration in each valid scene resource ledger is deleted and the corresponding pre-occupancy of resources and exclusive stable share are released. When the same resource event or task status event is received repeatedly, the status change is performed only once based on the cross-system operation identifier, event role, and source event sequence number.

Images