A cross-game benefit inventory linkage configuration method and system for digital wine marketing

Abstract

The application belongs to the technical field of internet marketing data processing, and discloses a cross-game right interest inventory linkage configuration method and system for digital wine marketing. The method and system receive configuration of activities such as synthesis, blind box, drawing, check-in, and preferential purchase, and construct wine order, wine product right interest, collection, points, preferential purchase coupon and resource position into a right interest resource graph. Activity rules are compiled into a rule execution tree, a resource occupation topology chain and a unique lock sequence are generated, and a right interest inventory account book is established. When a user participates in an activity, a right interest transaction voucher is generated, and pre-freezing, formal deduction, rollback release and compensation processing are performed. Real participation fields, display participation fields, winning fields and right interest deduction fields are separated, and inventory consistency verification is performed through graph edge quantity, account conservation and transaction closed loop, thereby improving the accuracy and traceability of cross-game right interest inventory processing.

Description

TECHNICAL FIELD

[0001] The invention belongs to the technical field of internet marketing data processing, and specifically relates to a cross-play benefit inventory linkage configuration method and system for digital alcohol marketing. BACKGROUND ART

[0002] With the combination of alcohol consumption scenarios and internet platforms, alcohol product sales have gradually expanded from a single transaction mode to a composite marketing mode including membership benefits, digital vouchers, blind box draws, lottery-based alcohol purchases, check-in rewards, priority purchase coupons, resource placement, etc. In such businesses, the platform usually needs to simultaneously manage multiple benefit resources such as physical alcohol products, wine orders, points, digital collections, priority purchase coupons, discount qualifications, and advertising resource positions. Especially in holiday promotions, new product launches, regional pub promotions, member activities and brand co-branding activities, the same benefit resource may be called by multiple plays at the same time. For example, a certain wine order can be used as a synthesis material, a blind box purchase condition, and a lottery qualification; a certain point resource can be used as a check-in reward and a blind box prize; a certain priority purchase coupon can be obtained through synthesis or directly distributed by the background in a targeted manner. Therefore, cross-play benefit inventory processing has become an important data processing link for the stable operation of digital alcohol marketing platforms.

[0003] In the prior art, CN109598542A discloses a marketing benefit delivery method, device and electronic equipment, which determines the target marketing benefits to be delivered to users by grouping marketing benefits and based on factors such as the number of target user groups and benefit utilization rate, and can improve the matching and use efficiency of marketing benefit delivery. Such solutions mainly focus on "which benefits to deliver to which users" and "how to improve the effect of benefit delivery", and are suitable for the delivery management of benefits such as coupons, red envelopes and points. However, in digital alcohol marketing platforms, activity configuration is not simply benefit delivery, it also involves problems such as multiple activity plays accessing the same benefit resource at the same time, multiple activity versions generated after activity copying or modification, delayed transaction status caused by payment callback or network interruption, inventory freeze release after activity removal, and isolation between display heat fields and real participation fields. If a conventional single-activity inventory table or single-benefit delivery table is still used for management, the inventory fields between different activities are independent of each other, making it difficult to determine the occupation order and circulation path of a benefit resource among multiple plays.

[0004] In practice, typical activity inventory management methods usually control deductions within a single activity through database transactions, optimistic locking, or status fields. While this can reduce the risk of overselling within a single activity, it still has shortcomings when dealing with shared benefits across different gameplay modes: First, when the same benefit resource is called by multiple activity versions, the lack of a unified resource locking order can easily lead to duplicate freezing, loop waiting, or inconsistent concurrent deductions. Second, after an activity is copied, modified, or relisted, the inventory records of the old and new versions may be mixed, resulting in inconsistencies between the inventory ledger and the actual distribution results. Third, after payment failure, drawing failure, synthesis failure, duplicate client submissions, or temporary removal of the activity, pre-frozen inventory may not be released in a timely manner. Fourth, in blind box or lottery activities, fields such as virtual participation counts and displayed pageviews set to demonstrate activity popularity may be mistakenly included in prize determination or benefit distribution if they are not isolated from real participation data. Fifth, after the activity ends, there is a lack of graph-based benefit flow records and transaction closure verification. Operations personnel need to manually check the activity table, payment records, user benefit table, and inventory table, resulting in low accounting efficiency and difficulty in tracing abnormal transactions.

[0005] Therefore, it is necessary to provide a cross-game rights inventory linkage configuration method and system for digital wine marketing, which unifies the modeling of multiple types of rights resources and forms a traceable data processing link in the process of activity rule execution, inventory freezing, formal deduction, rollback release, anomaly compensation and activity end verification, so as to improve the consistency and processing reliability of rights inventory data in multi-game concurrent marketing scenarios. Summary of the Invention

[0006] This invention aims to provide a method and system for cross-marketing rights inventory linkage configuration for digital wine marketing, in order to solve the problems of inconsistent inventory locking order, non-closed transaction status, mixed use of displayed data and real data, and difficulty in verifying activity version inventory when multiple marketing activities concurrently call the same rights resource.

[0007] To achieve the above objectives, the present invention provides the following technical solution.

[0008] In a first aspect, the present invention provides a method for configuring cross-gameplay benefits inventory linkage for digital wine marketing, executed by a server, comprising the following steps:

[0009] S1. Receive the configuration of digital wine marketing activities, extract the fields of gameplay type, benefit recipients, activity version, applicable community and inventory, and construct the rights and benefits resource graph by combining wine tokens, wine benefits, collections, points, priority purchase coupons and resource slots. The graph edges record the consumption, freezing, release, issuance, cancellation and expiration relationships.

[0010] S2. Compile the activity rules into a rule execution tree, generate a resource occupation topology chain based on the equity resource graph, and write the resource locking order into the leaf nodes of the rule execution tree; when the same equity resource is called by different activity versions, generate a unique lock order according to the activity version number, resource priority and transaction timestamp, and generate an equity inventory ledger;

[0011] S3. When a user participates in an activity, a rights transaction certificate is generated. The required rights resources are pre-frozen according to the unique lock sequence. The rights transaction certificate carries a summary of the previous inventory and a summary of the expected subsequent inventory.

[0012] S4. Based on the payment, extraction, synthesis, check-in, receipt, or verification results, the pre-frozen resources will be officially deducted or rolled back and released; if the deduction result summary is inconsistent with the expected subsequent inventory summary, it will be written to the compensation queue and field overwriting will be paused.

[0013] S5 separates the fields for actual participation, display participation, winning, and equity deduction, and outputs the inventory consistency verification results based on the graph edge quantity, equity inventory ledger, and equity transaction voucher.

[0014] Specifically, in step S1, the rights and interests resource graph includes rights and interests resource nodes and rights and interests relationship edges; the rights and interests resource nodes include resource identifier, resource type, wine product identifier, wine order identifier, applicable community, total inventory, available inventory, frozen inventory, deducted inventory, rollback inventory, expiration time, and scope of playable activities; the rights and interests relationship edges include synthesis consumption edge, blind box distribution edge, lottery quota edge, sign-in reward edge, priority purchase qualification edge, wine product redemption edge, and resource position exposure edge.

[0015] Specifically, in step S2, the rule execution tree includes activity time nodes, user qualification nodes, community scope nodes, single user count nodes, whitelist nodes, blacklist nodes, rights consumption nodes, rights distribution nodes, inventory threshold nodes, and resource locking nodes; the resource locking nodes determine the locking order according to the resource occupation topology chain, so that upstream consumable resources are locked before downstream distribution resources, and resources at the same level are locked according to resource priority.

[0016] Specifically, in step S2, when two or more activity versions call the same equity resource at the same time, the system first compares the activity version number, then compares the resource priority, and finally compares the transaction timestamp to generate a globally unique resource lock order; the activity transaction that does not obtain the resource lock order enters the waiting queue or is downgraded to a candidate transaction and does not perform inventory deduction.

[0017] Specifically, the equity inventory ledger records the initial inventory, available inventory, pre-frozen inventory, officially deducted inventory, rollback inventory, expired inventory, manually adjusted inventory, and ledger summary according to the activity version; when the activity is copied, modified, put on the shelves, taken off the shelves, or republished, a new activity version is generated and the equity inventory ledger corresponding to the previous activity version is retained.

[0018] Specifically, in step S3, the rights and interests transaction certificate includes user identifier, activity identifier, activity version, rights and interests resource identifier, transaction type, resource lock sequence, pre-frozen quantity, previous inventory summary, expected subsequent inventory summary, actual subsequent inventory summary, and transaction status; the transaction status includes pending freezing, frozen, deducted, rolled back, pending compensation, and closed.

[0019] Specifically, in step S4, the compensation queue records the compensation reason, the most recent consistent inventory summary, the abnormal resource node, the abnormal graph edge, the quantity to be compensated, and the compensation action according to the equity transaction certificate; the compensation action includes one or more of the following: re-deduction, rollback release, freeze and hold, manual review, and activity suspension.

[0020] Specifically, in step S5, the actual participation field is used to record the user's actual participation behavior, the display participation field is used for front-end popularity display, the winning field is used to record the results of the lottery, draw, or blind box draw, and the rights deduction field is used to trigger inventory deduction; the display participation field does not participate in the winning determination, inventory deduction, and rights distribution.

[0021] Secondly, this invention also provides a cross-game benefit inventory linkage configuration system for digital wine marketing, used to implement the method described in the first aspect. The system includes: an activity configuration receiving module, used to receive digital wine marketing activity configurations and extract the game type, benefit object, activity version, applicable community, and inventory fields; a benefit resource graph module, used to construct a benefit resource graph from wine tokens, wine benefits, collections, points, priority purchase coupons, and resource slots; a rule compilation module, used to compile activity rules into a rule execution tree and generate a resource occupation topology chain and resource locking order; a lock order generation module, used to generate a unique lock order according to the activity version number, resource priority, and transaction timestamp when the same benefit resource is called by different activity versions; an inventory ledger module, used to generate and maintain the benefit inventory ledger corresponding to the activity version; a transaction processing module, used to generate benefit transaction vouchers and execute benefit resource pre-freezing, formal deduction, rollback release, and compensation queue writing; a data isolation module, used to separate the record real participation field, display participation field, winning field, and benefit deduction field; and a consistency verification module, used to output inventory consistency verification results based on the number of graph edges, the benefit inventory ledger, and the benefit transaction vouchers.

[0022] Thirdly, the present invention also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0023] Fourthly, the present invention also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the method described in the first aspect.

[0024] This invention unifies the construction of a rights and resources map by integrating drinking games, wine privileges, collectibles, points, priority purchase coupons, and resource slots. It also compiles activity rules into a rule execution tree, enabling unified recording of the consumption, freezing, release, distribution, redemption, and expiration relationships of various rights and resources in gameplay such as synthesis, blind boxes, lotteries, check-ins, priority purchases, and redemption. Through resource occupation topology chains and unique locking sequences, it ensures that when different activity versions concurrently call the same rights and resources, pre-freezing and deduction are executed in a predetermined order, reducing the risks of duplicate freezing, inconsistent concurrent deductions, and mixed inventory across activity versions. Furthermore, it records a summary of prior inventory and pre-existing inventory through rights and resources transaction vouchers. The post-event inventory summary and the actual post-event inventory summary enable abnormal scenarios such as payment failure, extraction failure, synthesis failure, event removal, and duplicate submission to enter the compensation queue and be rolled back, re-deducted, or manually reviewed. By separating the real participation field, the display participation field, the winning field, and the rights deduction field, the display popularity data is excluded from the winning determination, inventory deduction, and rights distribution. Through graph edge quantity verification, ledger inventory conservation verification, and transaction voucher closed-loop verification, consistent inventory results can be output during and after the event, thereby improving the accuracy, traceability, and reconciliation efficiency of cross-game rights inventory processing. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the cross-game rights and interests inventory linkage configuration method of the present invention.

[0026] Figure 2 This is a schematic diagram of the cross-play rights and interests inventory linkage configuration system of the present invention. Detailed Implementation

[0027] The specific embodiments of the present invention will now be described with reference to the accompanying drawings. It should be understood that the following embodiments are used to illustrate the technical solutions of the present invention and are not intended to limit the scope of protection of the present invention. Equivalent substitutions made by those skilled in the art for certain field names, data structures, execution orders, deployment methods, or interface forms without departing from the technical solutions of the present invention should all be included within the scope of protection of the present invention.

[0028] This implementation provides a method and system for cross-game activity rights inventory linkage configuration in digital wine marketing, applicable to scenarios where multiple activities run concurrently on a digital wine marketing platform. For example, when the platform simultaneously configures activities such as wine purchase with free wine tokens, wine token synthesis, blind box draws, lottery-based wine purchases, daily check-in for points, priority coupon redemption, and splash screen ad promotion, the same type of rights resource may be called by multiple activity versions simultaneously. If managed only through ordinary activity tables and ordinary inventory fields, problems can easily arise such as the same wine token being frozen repeatedly, the same collectible being deducted from multiple activities simultaneously, blind box display participants being included in prize calculations, mixed inventory ledgers after activity duplication, and frozen inventory not being released after an activity ends. Therefore, this implementation uses a rights resource graph, rule execution tree, resource occupation topology chain, unique lock sequence, rights transaction certificate, inventory summary verification, compensation queue, and consistency verification mechanism to perform linkage configuration and control of cross-game rights inventory.

[0029] I. Terminology Explanation

[0030] The terms used in this specification are briefly explained as follows.

[0031] Digital wine marketing campaign configuration refers to the campaign configuration data that operators create, copy, modify, upload, delist, or republish in the backend of the digital wine marketing platform. These campaigns can include one or more of the following: composite campaigns, blind box campaigns, lottery campaigns, check-in campaigns, priority purchase campaigns, wine redemption campaigns, and resource placement campaigns.

[0032] A "wine token" is a digital rights certificate associated with the purchase of wine, wine benefits, activity rewards, user qualifications, or platform redemption. Wine tokens can serve as conditions for users to participate in crafting, blind boxes, lotteries, priority purchases, or redemption activities, and can also be issued, frozen, deducted, verified, or reclaimed by the platform.

[0033] Wine rights refer to rights related to physical wines, such as the right to pick up the wine, the right to discount, the right to redeem, the right to give away the wine, the right to redeem, or the right to purchase first. Wine rights can be linked to specific wine batches, wine SKUs, store inventory, promotional inventory, or user accounts.

[0034] Collectibles refer to digital collectibles, event props, synthetic materials, or virtual rights objects that can be used for blind boxes, lotteries, exchanges, and reward distribution within a digital wine marketing platform.

[0035] "Resource slots" refer to the locations on a platform used to display event or benefit content, including splash screen ads, announcement slots, homepage event slots, channel page recommendation slots, community recommendation slots, and event link slots. Resource slots may have fields such as impressions, clicks, placement time, applicable communities, and weight.

[0036] Rights and resource nodes refer to resource objects within the system that can be invoked, frozen, deducted, issued, cancelled, or expired. Rights and resource nodes can correspond to any of the following: wine tokens, wine rights, collectibles, points, priority purchase coupons, and resource slots.

[0037] A rights and resources graph is a data structure consisting of rights and resources nodes and rights and resources relationship edges. Rights and resources relationship edges are used to record the relationships between different rights and resources or between rights and resources and activities, such as consumption, freezing, release, issuance, write-off, expiration, and exposure.

[0038] The rule execution tree refers to a tree-shaped data structure generated by compiling activity rules. Its root node corresponds to the activity version, the intermediate nodes correspond to conditions such as activity time, user qualification, community scope, number of times per user, whitelist, blacklist, and inventory threshold, and the leaf nodes correspond to the rights and resources that need to be frozen, deducted, issued, cancelled, or released.

[0039] Resource occupancy topology refers to the resource access order generated based on the upstream and downstream relationships in the equity resource graph. This order is used to determine which equity resources should be locked first and which should be locked next in an activity transaction, thereby reducing duplicate occupancy or order conflicts of the same equity resource by concurrent activities.

[0040] Unique lock order refers to the globally unique resource locking order generated by the system based on the activity version number, resource priority, and transaction timestamp when the same resource is invoked by two or more activity versions or two or more activity transactions. Transactions that acquire a unique lock order can continue to execute pre-freeze or deduction, while transactions that do not acquire a unique lock order enter a waiting queue or are downgraded to candidate transactions.

[0041] Equity inventory ledger refers to a data structure that records changes in equity resource inventory according to the active version. It records at least the initial inventory, available inventory, pre-frozen inventory, officially deducted inventory, rollback inventory, expired inventory, manually adjusted inventory, and ledger summary.

[0042] Equity transaction certificate refers to the transaction record generated by the system when a user participates in an activity. It is used to describe the equity resources invoked by the user's participation in the activity, the resource lock order, the pre-frozen quantity, the summary of the previous inventory, the summary of the expected subsequent inventory, the summary of the actual subsequent inventory, and the transaction status.

[0043] The pre-emptive inventory summary refers to the summary value generated by the system based on the current inventory status of an equity resource before it is pre-frozen, formally deducted, or rolled back. This summary value is used to verify whether the inventory status before the transaction is executed is consistent with expectations.

[0044] The expected subsequent inventory summary refers to the inventory status summary calculated by the system based on the expected execution result of this transaction. This summary value is used to compare with the actual subsequent inventory summary.

[0045] The compensation queue is a data queue used to record abnormal transactions and perform subsequent recovery processing. When the deduction result summary is inconsistent with the expected subsequent inventory summary, or when a transaction is frozen for a long time, the system writes the corresponding transaction to the compensation queue.

[0046] Field overwriting refers to the operation of writing the execution result of a transaction into the final valid inventory field, user rights account field, activity statistics field, or rights distribution field. Pausing field overwriting means not writing abnormal results into the final valid data until the abnormal transaction has been processed.

[0047] The "actual participation" field refers to the field that records the user's actual participation behavior, such as actual purchase records, actual check-in records, actual lottery records, actual synthesis records, and actual verification records.

[0048] The "participation display field" refers to fields used to display front-end popularity, such as the number of virtual participations, the number of displayed pageviews, the number of displayed raffle entries, or the activity's popularity score. The participation display field does not participate in prize determination, inventory deduction, or reward distribution.

[0049] The winning field refers to the field used to record the results of lotteries, raffles, or blind box draws, including the winning user, winning benefits, winning time, and winning activity version.

[0050] The equity deduction field refers to the field used to trigger inventory deductions and changes in user account equity.

[0051] II. Method Implementation

[0052] like Figure 1 As shown, the method of the present invention includes the following steps.

[0053] S1. Receive digital wine marketing campaign configurations and build a rights and benefits resource map.

[0054] The server receives the configuration of the digital wine marketing campaign, extracts the fields of gameplay type, target beneficiaries, campaign version, applicable community and inventory, and constructs a rights and resources graph by combining wine tokens, wine rights, collections, points, priority purchase coupons and resource slots. The graph edges record the relationships of consumption, freezing, release, issuance, cancellation and expiration.

[0055] In this step, the server receives the activity configuration submitted from the operations backend. The activity configuration can originate from adding, copying, modifying, relisting, or batch importing activities. The server first parses the activity configuration fields, extracting the activity identifier, gameplay type, activity version, beneficiary group, activity period, applicable communities, number of participations per user, total number of participations, beneficiary consumption quantity, beneficiary distribution quantity, inventory field, activity status field, and resource slot field.

[0056] The "Gameplay Type" field distinguishes whether the activity falls under the categories of crafting, blind boxes, lotteries, daily check-ins, priority purchases, wine redemption, or ad placement. "Benefit Target" identifies the specific resource involved in the activity, such as a wine token, a wine benefit, a collectible, a points account, a priority purchase coupon, or an advertising ad placement. "Activity Version" differentiates different configuration versions of the same activity after modification, duplication, or re-launch. "Applicable Community" limits the scope of users, stores, or service areas from which the activity can participate. The "Inventory" field records the total inventory, available inventory, frozen inventory, deducted inventory, rolled-back inventory, and expired inventory of the benefit resource during the activity.

[0057] After completing field parsing, the server establishes a rights and interests resource graph. This graph includes rights and interests resource nodes and rights and interests relationship edges. Each rights and interests resource node includes at least a resource identifier, resource type, associated wine identifier, associated wine token identifier, applicable community, total inventory, available inventory, frozen inventory, deducted inventory, rollback inventory, expiration time, and scope of applicable gameplay. Resource types may include wine tokens, wine rights, collectibles, points, priority purchase coupons, and resource slots.

[0058] Rights and interests relationships are used to represent the operational relationships between rights and interests resource nodes, including synthesis consumption edges, blind box distribution edges, lottery quota edges, sign-in reward edges, priority purchase qualification edges, wine redemption edges, and resource slot exposure edges. Each rights and interests relationship edge must include at least the edge identifier, starting node, ending node, edge type, activity version, occupied quantity, release conditions, deduction conditions, and expiration conditions.

[0059] For example, in an event where users "buy wine, receive a wine token, and participate in a lottery," users obtain a wine token after purchasing physical wine, which can then be used as a qualification to participate in the lottery. The server can establish a distribution edge between the wine benefit node and the wine token node, and a qualification edge or consumption edge between the wine token node and the lottery qualification node. In an event where "synthesize wine tokens to obtain priority purchase coupons," the server can establish synthesis consumption edges and distribution edges between multiple wine token nodes and priority purchase coupon nodes. Through this method, the flow of the same benefit resource across different gameplay modes can be uniformly recorded using a graph structure.

[0060] S2. Compile the rule execution tree to generate resource usage topology chains and unique lock sequences.

[0061] The server compiles the activity rules into a rule execution tree, generates a resource occupancy topology chain based on the equity resource graph, and writes the resource locking order into the leaf nodes of the rule execution tree. When the same equity resource is called by different activity versions, a unique lock order is generated according to the activity version number, resource priority, and transaction timestamp, and an equity inventory ledger is generated.

[0062] This step is used to establish an executable rule structure and inventory control structure before the activity goes live.

[0063] The server first compiles the activity rules into a rule execution tree. This rule execution tree can include activity time nodes, user eligibility nodes, community scope nodes, single-user count nodes, whitelist nodes, blacklist nodes, benefit consumption nodes, benefit distribution nodes, inventory threshold nodes, and resource locking nodes. The root node of the rule execution tree identifies the activity version; intermediate nodes represent participation conditions, user scope, activity status, and inventory thresholds; and leaf nodes represent the benefit resources that ultimately need to be occupied, frozen, deducted, distributed, or cancelled.

[0064] Taking a blind box event as an example, the rule execution tree can be sequentially divided into the event time node, community scope node, user qualification node, purchase count node, payment status node, blind box inventory node, prize distribution node, and benefit distribution node. Taking a synthesis event as an example, the rule execution tree can be sequentially divided into the event time node, user qualification node, synthesis material node, material quantity node, synthesis count node, reward inventory node, and reward distribution node.

[0065] After generating the rule execution tree, the server generates a resource occupancy topology chain based on the equity resource graph. This resource occupancy topology chain represents the order in which an activity transaction needs to access equity resource nodes during execution. The server determines upstream and downstream resources based on the consumption, freezing, release, issuance, cancellation, and expiration relationships between nodes in the graph. For example, in a synthesis activity, consumed wine tokens or collectibles are upstream consumable resources, while priority purchase coupons or wine rights issued after synthesis are downstream issuance resources; in a blind box activity, blind box inventory is an upstream sales resource, while prize rights are a downstream issuance resource.

[0066] The server writes the resource locking order into the leaf nodes of the rule execution tree. Specifically, upstream consumable resources are locked before downstream release resources; when multiple resources exist at the same level, they are locked according to resource priority; when resource priorities are the same, they are locked according to transaction timestamps. Resource priority can be determined by resource scarcity, activity level, resource type, and applicable community. For example, limited-edition wine tokens, high-value wine privileges, and limited priority purchase coupons can be assigned higher priorities; ordinary points or ordinary resource slots can be assigned lower priorities.

[0067] When two or more activity versions simultaneously request the same resource, the system generates a globally unique resource lock order based on the activity version number, resource priority, and transaction timestamp. Specifically, the following sorting principle can be adopted: first, compare the activity version numbers, prioritizing valid activity versions that are already listed and executing over those awaiting listing; then, compare resource priorities, ensuring higher-priority resources acquire the lock first; finally, compare transaction timestamps, allowing transactions arriving at the server first to execute. Through this multi-level sorting, the server can generate a unique locking order for multiple concurrent access requests to the same resource, preventing duplicate freezing, circular waiting, or inconsistent concurrent deductions caused by different activity transactions locking multiple resources in different orders.

[0068] In this embodiment, the resource lock order can be represented as:

[0069]

[0070] In the formula, Indicates the resource lock order; Indicates the activity version number; Indicates resource priority; Represents the transaction timestamp; Indicates the rights and resources identifier. The server follows... , , A unique lock order is generated based on the preset sorting rules. Active transactions that do not acquire a resource lock order enter the waiting queue or are downgraded to candidate transactions, and inventory deduction is not performed.

[0071] Simultaneously, the server generates an equity inventory ledger for each activity version. This ledger records initial inventory, available inventory, pre-frozen inventory, officially deducted inventory, rolled-back inventory, expired inventory, manually adjusted inventory, and a ledger summary, categorized by activity version. When an activity is copied, modified, uploaded, removed, or republished, a new activity version is generated while retaining the equity inventory ledger corresponding to the previous version. This ensures that inventory changes for the same activity across different versions are not mixed, facilitating subsequent auditing and verification.

[0072] The state-based inventory conservation relationship in the equity inventory ledger can be represented as:

[0073]

[0074] In the formula, Indicates the initial inventory of the active version; This indicates manual adjustment of inventory; a positive value is used when increasing inventory and a negative value is used when decreasing inventory. Indicates available inventory; This indicates pre-frozen inventory; This indicates a formal deduction from inventory; This indicates expired inventory; This indicates a compensation lock-in for inventory, meaning inventory temporarily locked due to inconsistencies in the summary, incomplete transaction closure, or manual review. The server can use this relationship to perform ledger verification after each change in inventory status.

[0075] For rollback inventory, this implementation method verifies it as a cumulative record item, rather than repeatedly including it as status-based inventory on the right side of the above equation. Rollback inventory can be expressed as:

[0076]

[0077] In the formula, This indicates the cumulative rollback of inventory; Indicates the first The amount of inventory released by the rollback transaction; This indicates the number of transactions to be rolled back. After the rollback transactions are completed, the corresponding number will decrease from [previous number]. Turn back At the same time, the corresponding quantity is added to the cumulative rollback record. Thus, the system can both verify the inventory balance and track the rollback process.

[0078] S3. Generate equity transaction vouchers and execute pre-freeze.

[0079] When a user participates in an activity, the server generates an equity transaction certificate and pre-freezes the required equity resources according to the unique lock sequence. The equity transaction certificate carries a summary of the previous inventory and a summary of the expected subsequent inventory.

[0080] When users participate in digital wine marketing activities through the client, such as purchasing blind boxes, submitting synthesis, participating in lotteries, completing check-ins, receiving priority purchase coupons, or redeeming wine benefits, the server first reads the rule execution tree and benefit inventory ledger corresponding to the activity, and generates benefit transaction certificates based on user identifier, activity identifier, activity version, and benefit resource identifier.

[0081] The rights and interests transaction certificate includes a user identifier, an activity identifier, an activity version, a rights and interests resource identifier, a transaction type, a resource lock sequence, a pre-frozen quantity, a summary of the preceding inventory, a summary of the expected subsequent inventory, a summary of the actual subsequent inventory, and a transaction status. Transaction types may include purchase, extraction, synthesis, check-in, receipt, cancellation, release, rollback, and compensation. Transaction status may include pending freezing, frozen, deducted, rolled back, pending compensation, and closed.

[0082] Before executing the pre-freeze, the server first reads the current inventory status from the equity inventory ledger and generates a pre-emptive inventory summary based on the current inventory status. The pre-emptive inventory summary can be generated based on the activity version, equity resource identifier, available inventory, frozen inventory, deducted inventory, rolled-back inventory, and the most recent transaction number. The summary generation can use existing hash digest methods or an irreversible digest method defined internally by the platform. Subsequently, the server calculates the expected subsequent inventory status based on the pre-frozen quantity and generates the expected subsequent inventory summary.

[0083] For example, if a certain drinking game resource currently has an available inventory of 100 and a frozen inventory of 10, and a user needs to pre-freeze 1 drinking game right to participate in the blind box, then the expected subsequent state will be an available inventory of 99 and a frozen inventory of 11. The server generates an expected subsequent inventory summary based on this.

[0084] After the server acquires the resource lock sequence, it pre-freezes the corresponding equity resources. If the pre-freezing is successful, the available inventory and pre-frozen inventory in the equity inventory ledger are updated, and the equity transaction voucher status is updated to frozen. If the available inventory is insufficient, the activity status is abnormal, the user's qualifications are not met, or the resource lock sequence has not been acquired, the pre-freezing fails, the transaction status remains pending freezing or changes to closed, and the equity deduction stage is not allowed.

[0085] By introducing a pre-freeze inventory summary and an expected post-freeze inventory summary, the server can confirm whether the inventory status is consistent with expectations during subsequent formal deductions, rollback releases, and abnormal compensations, thus avoiding the ledger status being incorrectly overwritten due to concurrent updates, manual adjustments, or abnormal interruptions.

[0086] S4. Perform formal deduction, rollback release, and compensation queue processing.

[0087] Based on the results of payment, extraction, synthesis, check-in, receipt, or verification, the server will officially deduct or roll back the pre-frozen resources; when the deduction result summary is inconsistent with the expected subsequent inventory summary, it will be written to the compensation queue and the field overwriting will be suspended.

[0088] When a user's participation in an activity meets the activity rules, the server will convert the corresponding pre-frozen resources into official deductions. For example, after a user successfully pays for a blind box and completes the draw, the blind box inventory and prize benefits are deducted according to the draw results; after a user submits a synthesis and the materials are verified to meet the requirements, the consumed wine tokens or collectibles are officially deducted, and the synthesis rewards are officially issued; after a user completes a sign-in and meets the activity rules, the sign-in rewards are officially issued or the corresponding supplementary sign-in consumption is deducted; after a user receives a priority purchase coupon, the claimable inventory of the priority purchase coupon is officially deducted; after a user redeems wine benefits offline or online, the corresponding redeemed benefits are officially deducted.

[0089] When a user's payment times out, extraction fails, synthesis fails, check-in fails, claim fails, verification fails, the activity is removed, a system error occurs, or the connection is interrupted, the server will roll back and release the pre-frozen resources. During the rollback, the server reduces the pre-frozen inventory based on the pre-frozen inventory summary and pre-frozen quantity recorded in the equity transaction certificate, and restores the corresponding quantity to the available inventory. After the rollback is completed, the equity transaction certificate status is updated to "rolled back".

[0090] During the formal deduction or rollback release process, the server generates an actual subsequent inventory summary and compares it with the expected subsequent inventory summary in the equity transaction document. For the subsequent summary in the pre-freeze phase, it is used to verify whether the pre-freeze was executed correctly; for the formal deduction phase, the server can regenerate the pre-deduction summary and post-deduction summary based on the frozen state. If the deduction result summary is inconsistent with the expected subsequent inventory summary, it indicates that the inventory status may be affected by concurrent transactions, abnormal updates, or manual adjustments. In this case, the server writes the transaction to the compensation queue and suspends field overwriting.

[0091] The compensation queue records the compensation reason, most recent consistent inventory summary, abnormal resource node, abnormal graph edge, quantity to be compensated, and compensation action according to the equity transaction voucher. Compensation actions include one or more of the following: re-deduction, rollback release, freeze retention, manual review, and activity suspension.

[0092] For example, when the deduction results show that the inventory has been deducted in advance by other transactions, the server can remain frozen and recalculate the deduction order; when the inventory summary shows that the activity version is inconsistent, the server can transfer the transaction to manual review; when multiple activity versions continue to show inconsistent summaries, the server can suspend the associated activities and lock the corresponding equity resource nodes.

[0093] S5. Separate the fields involved in the record and perform inventory consistency verification.

[0094] The server separates the fields for actual participation, displayed participation, winning, and equity deduction from the records, and outputs inventory consistency verification results based on the number of graph edges, equity inventory ledger, and equity transaction vouchers.

[0095] The server categorizes activity participation data into four fields: Actual Participation, Display Participation, Winning, and Benefit Deduction. The Actual Participation field records actual user participation behavior, such as actual purchase records, actual check-in records, actual lottery records, actual synthesis records, and actual redemption records. The Display Participation field is used for front-end popularity display, such as the number of virtual participations, the number of displayed views, the number of displayed lottery draws, or the activity's popularity value. The Winning field records the results of lotteries, raffles, or blind box draws, including the winning user, winning benefits, winning time, and winning activity version. The Benefit Deduction field triggers inventory deductions and changes to user account benefits.

[0096] In this implementation, the participation field is not involved in prize determination, inventory deduction, or prize distribution. For lottery activities, the server only forms a set of lottery candidate users based on the actual participation field and writes the winning results based on the winning field; the number of participations is only used to display the activity's popularity on the user's end. For blind box activities, the server only triggers inventory deduction based on actual purchase records and actual draw results, and does not allow the number of purchasers or the popularity field to influence the number of prizes distributed.

[0097] Inventory consistency verification includes graph edge quantity verification, ledger inventory conservation verification, and transaction voucher closed-loop verification. Graph edge quantity verification is used to determine whether the consumption edges, frozen edges, released edges, distribution edges, write-off edges, and expired edges in the equity resource graph corresponding to a certain activity version are consistent with the actual transaction records. For example, each successful synthesis transaction in a synthesis activity should correspond to at least one material consumption edge and one reward distribution edge; if only distribution edges exist but no consumption edges exist, an anomaly verification result is generated.

[0098] The ledger inventory conservation check determines whether the initial inventory, manually adjusted inventory, available inventory, pre-frozen inventory, officially deducted inventory, expired inventory, and compensation-locked inventory in the equity inventory ledger satisfy a preset inventory conservation relationship, and verifies the rolled-back inventory as a cumulative record item. If the condition is not met, the server locks the corresponding equity resource node and stops the associated active version from further accessing that equity resource.

[0099] The transaction credential closed-loop verification is used to determine whether each equity transaction credential has ultimately progressed from the pending-freeze state to the deducted, rolled-back, or closed state. If there are transactions that have been in the frozen or pending-compensation state for an extended period, the system outputs a pending exception and executes compensation actions according to the compensation queue.

[0100] III. System Implementation

[0101] like Figure 2 As shown, this embodiment also provides a cross-game benefits inventory linkage configuration system for digital wine marketing, used to implement the above method. The system includes an activity configuration receiving module, a benefits resource graph module, a rule compilation module, a lock sequence generation module, an inventory ledger module, a transaction processing module, a data isolation module, and a consistency verification module.

[0102] The activity configuration receiving module receives configurations for digital wine marketing activities and extracts fields such as activity type, target audience, activity version, applicable communities, and inventory. This module can connect to the operations backend to receive configurations from operations personnel for activities such as composite activities, blind box activities, lottery activities, check-in activities, priority purchase activities, wine redemption activities, or resource placement activities.

[0103] The Rights and Resources Graph module is used to construct a rights and resources graph from drinking games, wine rights, collectibles, points, priority purchase coupons, and resource slots. This module maintains rights and resources nodes and rights and resources relationship edges, and updates the graph status when an activity is created, modified, listed, delisted, executed, and ends.

[0104] The rule compilation module is used to compile activity rules into a rule execution tree and generate a resource occupancy topology chain and resource locking order. This module converts the business rules configured by operations personnel into a server-executable data structure, enabling activity participation conditions, inventory conditions, and benefit deduction conditions to be executed in a preset order.

[0105] The lock order generation module generates a unique lock order based on the activity version number, resource priority, and transaction timestamp when the same equity resource is accessed by different activity versions. This module controls the execution order when multiple activity transactions concurrently access the same equity resource.

[0106] The Inventory Ledger module is used to generate and maintain the equity inventory ledger corresponding to the activity version. This module records the initial inventory, available inventory, pre-frozen inventory, officially deducted inventory, rollback inventory, expired inventory, manually adjusted inventory, and ledger summary.

[0107] The transaction processing module is used to generate equity transaction credentials and perform equity resource pre-freezing, formal deduction, rollback release, and compensation queue writing. This module creates transaction credentials when a user participates in an activity and updates the transaction status based on the activity execution results.

[0108] The data isolation module is used to separate the fields for recording actual participation, displaying participation, winning prizes, and benefit deductions. This module ensures that the display fields are not involved in prize determination, inventory deduction, or benefit distribution.

[0109] The consistency verification module outputs inventory consistency verification results based on the number of graph edges, equity inventory ledger, and equity transaction vouchers. When the verification fails, this module can lock equity resource nodes, suspend active versions, generate an anomaly report, or trigger compensation queue processing.

[0110] In another embodiment, the present invention also provides a computer-readable storage medium having a computer program or instructions stored thereon. The computer-readable storage medium may be one or more of a read-only memory, random access memory, flash memory, hard disk, solid-state drive, optical disk, server storage array, or cloud storage medium. When the computer program or instructions are executed by a processor, the processor performs the aforementioned cross-game benefit inventory linkage configuration method for digital wine marketing, including: receiving digital wine marketing activity configuration and constructing a benefit resource graph; compiling activity rules into a rule execution tree and generating a resource occupation topology chain, a unique lock sequence, and a benefit inventory ledger; generating benefit transaction vouchers and performing pre-freezing when a user participates in the activity; performing formal deduction, rollback release, or compensation queue processing based on the activity execution results; separating and recording the actual participation field, the displayed participation field, the winning field, and the benefit deduction field, and outputting inventory consistency verification results based on the graph edge quantity, the benefit inventory ledger, and the benefit transaction voucher.

[0111] Furthermore, the computer program or instructions can be stored as a software module, service program, script program, or executable file, and can be invoked and executed by a processor in a single server, a distributed server cluster, or a cloud computing platform. During execution, the computer program or instructions can invoke databases, message queues, caching services, or log services to complete tasks such as maintaining the equity resource graph, updating the equity inventory ledger, generating equity transaction certificates, writing to the compensation queue, and outputting consistency verification results.

[0112] In another embodiment, the present invention also provides a computer program product, including a computer program or instructions. When the computer program or instructions are executed by a processor, the steps of the aforementioned method for cross-game benefit inventory linkage configuration for digital wine marketing are implemented, including: receiving digital wine marketing activity configuration and constructing a benefit resource graph; compiling the activity rules into a rule execution tree and generating a resource occupation topology chain, a unique lock sequence, and a benefit inventory ledger; generating benefit transaction vouchers and performing pre-freezing when users participate in the activity; performing formal deduction, rollback release, or compensation processing based on the activity execution results; separating and recording the actual participation field, the display participation field, the winning field, and the benefit deduction field, and outputting the inventory consistency verification result.

[0113] The computer program product can be provided in the form of an application program, a service program, an installation package, or a cloud program component, and can be deployed on a server, a distributed server cluster, or a cloud computing platform. Its specific carrying form does not affect the implementation of the method steps of the present invention. IV. Specific Implementation Example 1

[0115] This embodiment uses a scenario where "buying wine and receiving wine tokens, synthesizing wine tokens to prioritize purchasing coupons, drawing collectibles from blind boxes, winning wine benefits through lotteries, and earning points through daily check-ins" in a digital wine marketing platform as an example to illustrate the implementation process of the present invention.

[0116] The server is deployed on the backend of the digital wine marketing platform, and the clients include a user app, a mini-program, and the main tavern control panel. Operations personnel configure the following activities in the backend:

[0117] Activity A: Users will receive a Wine Token J1 after purchasing designated wines. Each wine will correspond to one Wine Token J1.

[0118] Activity B: Users consume 2 drinking tokens J1 to synthesize 1 priority purchase coupon Q1.

[0119] Activity C: Users consume 1 drinking token J1 to purchase a blind box. The blind box prizes include collectible C1 and points P1.

[0120] Activity D: Users holding a wine token J1 can participate in a lottery, and those who win will receive wine benefits W1.

[0121] Activity E: Users earn points P1 by checking in daily.

[0122] All of the above activities apply to the same community S1, and activities B, C, and D simultaneously call upon the wine token J1. The platform's initial configuration includes a wine token J1 inventory of 10,000, a priority purchase coupon Q1 inventory of 1,000, a collection C1 inventory of 500, a wine rights W1 inventory of 200, and a total of 100,000 points P1 that can be issued.

[0123] After receiving the activity configuration, the server registers J1, Q1, C1, W1, and P1 as equity resource nodes, and establishes equity relationship edges according to the rules of each activity. For example, Activity B establishes a synthesis consumption edge and a distribution edge between nodes J1 and Q1; Activity C establishes a consumption edge, an allocation edge, and a distribution edge between nodes J1, the blind box node, C1, and P1; Activity D establishes an eligibility edge and a distribution edge between nodes J1 and W1; and Activity E establishes a sign-in reward edge between the sign-in node and the P1 node.

[0124] The server generates rule execution trees for activities B, C, and D respectively. Since activities B, C, and D all call J1, the server generates a resource occupancy topology chain for J1 based on the equity resource graph and generates a unique lock order according to the activity version number, resource priority, and transaction timestamp. Assume that activity B's version number is B-3, activity C's version number is C-2, and activity D's version number is D-1; the platform sets the priority of synthetic consumption transactions higher than blind box purchase transactions, and blind box purchase transactions higher than lottery qualification transactions; then, within the same time period, the server first processes transactions in activity B that have already acquired a lock order, and then processes the corresponding transactions in activities C and D. Transactions that have not acquired a lock order enter a waiting queue and do not perform inventory deduction.

[0125] When user U001 participates in activity B, the server generates a rights transaction certificate T001. This certificate records the user identifier U001, activity identifier B, activity version B-3, rights resource J1, transaction type (synthesis), resource lock order L001, pre-frozen quantity 2, preceding inventory summary H001, and expected subsequent inventory summary H002. After acquiring the resource lock order for J1, the server pre-freezes both J1s. After the user submits the synthesis confirmation, the system verifies that the number of J1s held by the user account, the activity time, the number of times per user, and the inventory status all meet the requirements. The system then officially deducts the two J1s and issues one Q1. If the actual subsequent inventory summary after deduction matches the expected subsequent inventory summary, the transaction status is updated to "deducted"; otherwise, the transaction is written to the compensation queue and the overwriting of the Q1 issuance field in the user account is paused.

[0126] When user U002 participates in activity C to purchase blind boxes, the server generates a rights transaction certificate T002 and pre-freezes J1 and the blind box inventory. After successful payment, the server generates the drawing results according to the blind box configuration. If the user wins collectible C1, J1, the blind box inventory, and the C1 inventory are deducted simultaneously, and a winning record is generated. If the payment times out, the pre-frozen quantities of J1 and the blind box inventory are released, and no winning or rights deduction record is generated.

[0127] When Activity D is conducted via lottery, the server only uses the "actual participation" field to form the lottery user set. If the front-end is configured with a "display participation" field to show the activity's popularity, for example, by increasing the number of displayed participations by 1000, this field only enters the front-end display data table, not the lottery candidate set, and does not trigger the deduction of W1 benefits. After the lottery, the server deducts W1 inventory based on the winning field and records the corresponding benefit transaction voucher.

[0128] After the event concludes, the server performs an inventory consistency check. First, it verifies the number of graph edges, checking if each successful synthesis transaction has a J1 consumption edge and a Q1 distribution edge, if each blind box winning transaction has a blind box distribution edge and a prize distribution edge, and if each wine prize winning transaction has an eligibility edge and a distribution edge. Second, it performs a ledger inventory conservation check, verifying that the initial inventory, manually adjusted inventory, available inventory, pre-frozen inventory, officially deducted inventory, expired inventory, and compensation locked inventory in each event version satisfy the inventory conservation relationship. Finally, it performs a transaction voucher closure check, determining if all transaction vouchers are in a deducted, rolled-back, or closed state. If there are transactions that are frozen but not deducted or rolled back, the system processes them according to the compensation queue.

[0129] V. Specific Implementation Example 2 and Comparative Data

[0130] To verify the effectiveness of this implementation method in cross-game rights inventory management, a test environment closely resembling the actual platform was built. The test environment included an application server, a database server, and a set of simulated clients. The application server deployed the activity configuration receiving module, rights resource graph module, rule compilation module, lock sequence generation module, inventory ledger module, transaction processing module, data isolation module, and consistency verification module. The database server stored the activity version table, rights resource graph table, rights inventory ledger table, rights transaction voucher table, compensation team list, and activity statistics field table.

[0131] The test involved running five types of activities simultaneously: a synthesis activity, a blind box activity, a lottery activity, a check-in activity, and a priority purchase activity. Test resources included a wine token J1, a collectible C1, points P1, a priority purchase coupon Q1, and wine benefits W1. Wine token J1 was simultaneously used by the synthesis, blind box, and lottery activities; points P1 was simultaneously used by the blind box and check-in activities; and priority purchase coupon Q1 was simultaneously used by the synthesis and priority purchase activities. The test was conducted with 1000 concurrent users for 30 minutes, generating a total of 120,000 API requests. Approximately 84,000 requests were for activity browsing, inventory queries, activity status queries, and user benefit queries; approximately 36,000 requests involved pre-freezing, formal deduction, rollback release, and compensation processing of benefits; and approximately 18,000 benefit transaction vouchers were actually generated. The test simulated abnormal events such as payment timeouts, duplicate client submissions, temporary activity removal, manual inventory adjustments by the operations team, network interruption recovery, and payment callback delays.

[0132] The comparative model adopts a conventional single-activity inventory management scheme. In this model, each activity maintains an independent inventory field, and database transactions or optimistic locking are used to control inventory deductions within a single activity. When a deduction request occurs within a single activity, the system can perform the deduction or rollback within the activity's inventory table. However, this comparative model does not establish a cross-game equity resource graph, does not generate resource occupation topology chains and unique lock sequences, does not generate equity transaction vouchers carrying previous inventory summaries and expected subsequent inventory summaries, does not distinguish between actual participation fields and displayed participation fields, and does not perform graph edge quantity verification, ledger inventory conservation verification, and transaction voucher closed-loop verification.

[0133] The results obtained under the above test conditions are shown in Table 1.

[0134] Table 1. Comparison of cross-game equity inventory processing results between this embodiment and the comparative example.

[0135]

[0136] As shown in Table 1, when multiple gameplay modes call the same rights and benefits resources at the same time, although the comparison ratio can reduce the error of single-event inventory deduction by using database transactions or optimistic locking within a single event, problems such as over-issuance of inventory, effective duplicate freezing, mixed use of event version inventory, and incorrect participation of display fields in winning prizes or rights and benefits distribution still occur due to the lack of a unified graph of shared rights and benefits resources across events.

[0137] This embodiment controls the concurrent access order through a unique lock sequence, records the pre-inventory summary and expected post-inventory summary through equity transaction certificates, handles abnormal transactions through a compensation queue, and performs inventory verification after the event by verifying the number of graph edges, the ledger inventory conservation verification, and the transaction certificate closed-loop verification, so that the number of times inventory is over-issued, the number of times valid duplicate freezes are valid, the number of times the event version inventory is mixed, and the number of times the display field is mistakenly used for winning prizes or equity distribution are all 0.

[0138] During testing, this embodiment identified six instances of duplicate client submissions. These events included users clicking to submit synthesis repeatedly, clients automatically resending blind box purchase requests after network interruption recovery, and repeated inventory confirmations triggered after payment callback delays. After comparing the user identifier, activity identifier, activity version, equity resource identifier, and prior inventory summary in the equity transaction certificate, the system wrote the later-arriving duplicate requests into the compensation queue and executed rollback release or transaction closure processing, thus preventing effective duplicate freezing.

[0139] During testing, this embodiment's solution exhibited two instances of incomplete transaction status closure. Both occurred after manual inventory adjustments in the simulated operations backend, resulting in inconsistencies between the transaction execution summary and the expected subsequent inventory summary. The system marked the corresponding transaction status as pending compensation and locked the corresponding rights and resources node, ceasing the distribution of rights and resources to users. After manual review, the system rolled back the release or re-deducted based on the most recent consistent inventory summary. This process demonstrates that this embodiment can isolate, track, and recover from abnormal transactions in actual operation.

[0140] The statistical scope of the anomaly transaction traceability rate includes transactions that have generated equity transaction certificates and entered an anomaly state. In contrast, due to the lack of a unified equity transaction certificate, backtracking can only be performed based on activity logs, payment records, and inventory field change records. Therefore, in scenarios involving delayed payment callbacks, activity version switching, and manual inventory adjustments, the transaction state cannot be fully reconstructed. This embodiment, however, tracks anomaly transactions through equity transaction certificates, pre-existing inventory summaries, expected post-existing inventory summaries, actual post-existing inventory summaries, and compensation queue records, achieving an anomaly transaction traceability rate of 99.6%.

[0141] The reconciliation process for the five types of activities involves five types of activities, five types of shared rights and resources, and approximately 18,000 rights and interests transactions. The previous method required manual cross-checking of the activity table, inventory table, user rights and interests table, payment records, and activity winning records, taking approximately 95 minutes. This embodiment's solution automatically generates an anomaly list through graph edge quantity verification, ledger inventory conservation verification, and transaction voucher closed-loop verification. Manual processing is only required for a small number of abnormal transactions in the compensation queue, reducing reconciliation time to approximately 16 minutes.

[0142] This implementation method can also be applied to digital wine marketing scenarios involving regional tavern owners, service providers, and consumers. The server can configure different regional taverns, communities, wine batches, or service providers as associated attributes in the resource graph, ensuring that rights and benefits resources are only accessed within designated communities or activity versions. When a resource slot in a certain region has high exposure but a low redemption rate, the system can reduce the resource slot weight for that activity based on the resource slot feedback results. When the inventory of a synthetic activity corresponding to a wine order is nearly exhausted, the system can increase the restriction level of the inventory threshold node and reduce the allocation for subsequent activities. All of the above processing can be completed through the rights and benefits resource graph, rule execution tree, and rights and benefits inventory ledger, eliminating the need for manual calculation for each activity module separately.

[0143] It should be noted that the hash digest, ledger digest, and configuration evidence digest in this implementation can be implemented using existing digest algorithms or the platform's internal irreversible digest generation rules; their function is to provide a basis for verifying inventory status and activity configuration status, without limiting the specific digest algorithm. Resource priority can be preset by operations personnel or automatically calculated based on resource type, inventory scarcity, activity level, and community scope; its function is to generate a stable locking order for resources of the same level, without limiting the specific priority value. Transaction timestamps can use server reception time, message queue enqueue time, or database transaction creation time; their function is to determine the order of transactions of the same version and priority.

[0144] The system in this embodiment can be deployed on a single server or in a distributed server cluster. In a distributed deployment, the equity resource graph module and the inventory ledger module can use a centralized database or a distributed consistent storage; the lock order generation module can be deployed as an independent service to provide a unified resource lock order to different activity modules; the transaction processing module can asynchronously process pre-freeze, deduction, rollback, and compensation actions through a message queue. These deployment changes do not affect the implementation of the method of this invention.

[0145] In summary, this implementation method unifies the rights and resources under different gameplay modes into a rights and resources graph, converts activity rules into rule execution trees, and then realizes inventory linkage control when multiple gameplay modes, multiple activity versions, and multiple rights and resources are called concurrently in the digital wine marketing platform through resource occupation topology chain, unique lock sequence, rights and resources transaction certificate, inventory summary verification, compensation queue and consistency verification. This enables those skilled in the art to complete system development, interface configuration and database table design based on this.

Claims

1. A method for configuring cross-gameplay benefits inventory linkage for digital wine marketing, executed by a server, characterized in that: include: S1. Receive the configuration of digital wine marketing activities, extract the fields of gameplay type, benefit recipients, activity version, applicable community and inventory, and construct the rights and benefits resource graph by combining wine tokens, wine benefits, collections, points, priority purchase coupons and resource slots. The graph edges record the consumption, freezing, release, issuance, cancellation and expiration relationships. S2. Compile the activity rules into a rule execution tree, generate a resource occupation topology chain based on the equity resource graph, and write the resource locking order into the leaf nodes of the rule execution tree; when the same equity resource is called by different activity versions, generate a unique lock order according to the activity version number, resource priority and transaction timestamp, and generate an equity inventory ledger; S3. When a user participates in an activity, a rights transaction certificate is generated. The required rights resources are pre-frozen according to the unique lock sequence. The rights transaction certificate carries a summary of the previous inventory and a summary of the expected subsequent inventory. S4. Based on the payment, extraction, synthesis, check-in, receipt, or verification results, the pre-frozen resources will be officially deducted or rolled back and released; if the deduction result summary is inconsistent with the expected subsequent inventory summary, it will be written to the compensation queue and field overwriting will be paused. S5 separates the fields for actual participation, display participation, winning, and equity deduction, and outputs the inventory consistency verification results based on the graph edge quantity, equity inventory ledger, and equity transaction voucher.

2. The method for cross-game benefit inventory linkage configuration for digital wine marketing according to claim 1, characterized in that, In step S1, the rights and interests resource graph includes rights and interests resource nodes and rights and interests relationship edges; the rights and interests resource nodes include resource identifier, resource type, wine product identifier, wine order identifier, applicable community, total inventory, available inventory, frozen inventory, deducted inventory, rollback inventory, expiration time and scope of playable activities; the rights and interests relationship edges include synthesis consumption edge, blind box distribution edge, lottery quota edge, sign-in reward edge, priority purchase qualification edge, wine product redemption edge and resource position exposure edge.

3. The method for cross-game benefit inventory linkage configuration for digital wine marketing according to claim 1, characterized in that, In step S2, the rule execution tree includes activity time nodes, user qualification nodes, community scope nodes, single user count nodes, whitelist nodes, blacklist nodes, rights consumption nodes, rights distribution nodes, inventory threshold nodes, and resource locking nodes; the resource locking nodes determine the locking order according to the resource occupation topology chain, so that upstream consumable resources are locked before downstream distribution resources, and resources at the same level are locked according to resource priority.

4. The method for cross-game benefit inventory linkage configuration for digital wine marketing according to claim 1, characterized in that, In step S2, when two or more activity versions call the same resource simultaneously, the system first compares the activity version number, then compares the resource priority, and finally compares the transaction timestamp to generate a globally unique resource lock order; the activity transaction that does not obtain the resource lock order enters the waiting queue or is downgraded to a candidate transaction and does not perform inventory deduction. And / or, the equity inventory ledger records initial inventory, available inventory, pre-frozen inventory, officially deducted inventory, rollback inventory, expired inventory, manually adjusted inventory, and ledger summary according to the active version; When an activity is copied, modified, uploaded, removed, or republished, a new version of the activity is generated while retaining the equity inventory ledger corresponding to the previous version.

5. The method for cross-game benefit inventory linkage configuration for digital wine marketing according to claim 1, characterized in that, In step S3, the rights transaction certificate includes user identifier, activity identifier, activity version, rights resource identifier, transaction type, resource lock sequence, pre-frozen quantity, previous inventory summary, expected subsequent inventory summary, actual subsequent inventory summary, and transaction status; the transaction status includes pending freezing, frozen, deducted, rolled back, pending compensation, and closed.

6. The method for cross-game benefit inventory linkage configuration for digital wine marketing according to claim 1, characterized in that, In step S4, the compensation queue records the compensation reason, the most recent consistent inventory summary, the abnormal resource node, the abnormal graph edge, the quantity to be compensated, and the compensation action according to the equity transaction certificate; the compensation action includes one or more of the following: re-deduction, rollback release, freeze and hold, manual review, and activity suspension.

7. The method for cross-game benefit inventory linkage configuration for digital wine marketing according to claim 1, characterized in that, In step S5, the actual participation field is used to record the user's actual participation behavior, the display participation field is used for front-end popularity display, the winning field is used to record the results of the lottery, draw or blind box draw, and the rights deduction field is used to trigger inventory deduction. The participation field is not involved in prize determination, inventory deduction, or rights distribution.

8. A cross-platform rights and benefits inventory linkage configuration system for digital wine marketing, characterized in that, The system for implementing the method according to any one of claims 1-7, the system comprising: an activity configuration receiving module for receiving digital wine marketing activity configurations and extracting fields such as gameplay type, benefit object, activity version, applicable community, and inventory; a benefit resource graph module for constructing a benefit resource graph from wine tokens, wine benefits, collections, points, priority purchase coupons, and resource slots; a rule compilation module for compiling activity rules into a rule execution tree and generating a resource occupation topology chain and resource locking order; a lock order generation module for generating a unique lock order according to the activity version number, resource priority, and transaction timestamp when the same benefit resource is called by different activity versions; an inventory ledger module for generating and maintaining a benefit inventory ledger corresponding to the activity version; a transaction processing module for generating benefit transaction vouchers and executing benefit resource pre-freezing, formal deduction, rollback release, and compensation queue writing; a data isolation module for separating the record real participation field, display participation field, winning field, and benefit deduction field; and a consistency verification module for outputting inventory consistency verification results based on the number of graph edges, the benefit inventory ledger, and the benefit transaction vouchers.

9. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the method described in any one of claims 1-7.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the method described in any one of claims 1-7.

Images