Collaborative reconstruction method and system for owner alliance supply chain based on federated learning

Abstract

The present application relates to the field of owner alliance supply chain collaborative reconstruction, in particular to an owner alliance supply chain collaborative reconstruction method and system based on federated learning. The alliance coordination node releases a unified feature semantic version and double-tower model parameters, and the owner side, property side and merchant side nodes train the demand tower or supply tower using local retained data, perform trusted credential binding and pairwise mask on the updated pruned model, and the coordination node completes aggregation according to participation credibility, role coverage and data drift. After the model is issued, each node calculates a candidate score locally, only submits a hash resource identifier and a constraint abstract, the coordination node constructs a candidate conflict graph, forms a configuration result under the constraints of quantity, time period and service range, and the performance feedback is converted into subsequent training labels locally. The present application can establish a cross-subject joint model without collecting owner sensitive information and merchant operation details, and convert local supply and demand representation into an executable alliance resource configuration result.

Description

Technical Field

[0001] This invention relates to the field of collaborative restructuring of the supply chain of owner alliances, specifically to a method and system for collaborative restructuring of the supply chain of owner alliances based on federated learning. Background Technology

[0002] Existing homeowner alliance supply chain platforms typically involve the alliance operator building a centralized data warehouse, which is then connected to the property management system, homeowner service portal, and merchant management system. The platform unifies the fields submitted by homeowners (category preferences, budget range, residential area, acceptable service time, and transaction reviews) with those submitted by merchants (product catalogs, inventory quantities, prices, service scope, and fulfillment records). This data is then linked to a dataset based on homeowner identification, community identification, resource category, and time window. The matching service trains a demand profile model and a merchant ranking model on this linked dataset. Using the unified model, it calculates the score between each demand and candidate supply, and combines this with inventory, time period, service area, and qualification conditions to generate an invitation list. Order confirmations, fulfillment completions, rejections, and cancellations are continuously written back to the centralized warehouse to correct profile tags and ranking parameters. This processing chain places cross-subject feature association, model training, candidate calculation, and feedback updates on a central platform. Only through continuous uploading of associative detailed records from all parties can the platform maintain consistency between model samples and supply chain status.

[0003] To limit the exposure scope caused by centralized data collection, existing platforms remove names and contact information before data access, replace owner or merchant accounts with hash identifiers, and constrain data use through permission tables, interface signatures, transmission encryption, and access logs. To complete supply and demand calculations, the central platform still needs to retain correlation fields that connect regions, times, categories, orders, and fulfillment feedback. Furthermore, operational characteristics such as inventory changes, price changes, demand frequency, and service radius are constantly updated as business operations progress. If these fields are further converted to coarse-grained labels or only statistical summaries are uploaded, the central model will struggle to distinguish between different time windows, quantity constraints, and fulfillment boundaries within the same community, easily leading to a disconnect between candidate ranking and the actual available state. Conversely, if fine-grained fields sufficient for training and inference are retained, the anonymized multi-round data may be re-correlated to specific entities through time series, regional combinations, and transaction relationships. Therefore, the central platform's requirements for correlation accuracy and the participants' requirements for local data boundaries always operate within the same data processing chain.

[0004] The existing technical challenges are that when forming a sustainable and updatable joint supply and demand model across owner organizations, property owners, and merchants, model calculations rely on the centralized entry of original or related details from all parties into the same processing domain. This makes it impossible to simultaneously maintain local retention of original data and collaborative supply and demand calculations across entities. Static anonymization, hierarchical authorization, or aggregated exchange only change the presentation of uploaded data; they do not alter the computational structure where joint training requires reading centralized samples and candidate configurations require reading cross-party constraint details. Reducing fields disrupts the correspondence between demand intent, resource capabilities, and performance feedback, while retaining fields allows for the reconstructable association between sensitive owner information and merchant operational information on the central side. When participants do not upload details, the central model cannot obtain complementary samples from different nodes, nor can it form a unified configuration under conditions of shared inventory, overlapping time periods, and mutually exclusive service scopes. Therefore, the problem to be solved is how to establish a common supply and demand representation, complete cross-node model updates, and generate executable matching results that satisfy multi-party constraints when data does not leave the participants' local processing domains. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for collaborative restructuring of the owner alliance supply chain based on federated learning, which can solve the problems in the background art mentioned above.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: The federated learning-based supply chain collaborative reconstruction method for owner alliances includes: the alliance coordination node publishes a unified feature semantic version and dual-tower model parameters to the authenticated owner-side nodes, property-side nodes, and merchant-side nodes; Each participating node trains the corresponding demand tower or supply tower based on the locally retained supply and demand data, and submits the updated model after privacy protection processing. The alliance coordination node updates and distributes the updated dual-tower model based on the aggregation model according to the participation credibility and data distribution differences. Each participating node uses the updated dual-tower model to generate candidate resource scores and constraint summaries locally. The alliance coordination node constructs a candidate conflict graph based on the candidate resource scores and the constraint summary, solves the supply and demand configuration results, and returns them to the corresponding participating node. Each participating node will convert its local performance feedback into sample labels for the next training round.

[0007] Preferably, the unified feature semantic version includes a public semantic dictionary composed of resource category code, demand intent code, time period code, spatial service code, and performance status code; The owner-side node and the property-side node convert demand records into discrete identifiers corresponding to the public semantic dictionary based on the local field mapping table, and input the budget, location and preference fields that are only identifiable locally into the private feature branch of the demand tower. The merchant-side node converts the product catalog, availability and service boundary into discrete identifiers based on the local field mapping table, and inputs the price, inventory changes and fulfillment records into the private feature branch of the supply tower. Each private feature branch and the public semantic branch are integrated locally into a fixed-dimensional embedding.

[0008] Preferably, each participating node reads the newly added local samples according to the round identifier issued by the alliance coordination node, constructs training samples with local positive performance records and uncompleted records paired by time windows, and calculates the local gradient in the shared parameter layer of the dual-tower model. Each participating node generates a participation credibility credential based on the sample time decay value, the completeness of the common semantic field, and the gradient direction deviation between the previous and next rounds. The participation credibility credential is bound to the commitment value of the model update, and norm pruning is performed on the local gradient before submission, so that the update amount of different participating nodes is within the same pruning boundary published by the alliance coordination node.

[0009] Preferably, each participating node generates a pair of random masks based on the node pairing table within the round, and the clipped local gradient is superimposed with the pair of random masks to form a mask update; The alliance coordination node verifies the consistency of the participation trust credentials and commitment values, determines the aggregation weight according to the demand-side coverage, supply-side coverage, data drift degree and update direction consistency, and performs weighted aggregation on the verified mask updates. After the local candidate scores are submitted, the alliance coordination node establishes the candidate conflict graph with the candidate resource identifier as the vertex and the shared inventory, overlapping service periods or mutually exclusive fulfillment ranges as the edges, and generates the configuration result under the supply and demand quantity constraints.

[0010] Preferably, both the demand tower and the supply tower include a common semantic encoding layer, a role adaptation layer, and a shared projection layer. The common semantic encoding layer generates category embeddings according to the unified feature semantic version. The role adaptation layer is stored in the corresponding participant node and does not enter the model update. The role adaptation layer performs gated fusion of the quantile interval encoding of the local continuous field with the category embedding. The shared projection layer maps the fusion result to the alliance common embedding space. Each participating node constrains the common embedding space locally using the anchor vector corresponding to the resource category code of the same round, so that the demand embedding and the supply embedding use the same dimension and the same semantic direction.

[0011] Preferably, the participation trust credentials include digital signatures generated by participating nodes for round identifiers, semantic versions, sample time intervals, field completeness levels, gradient norm intervals, and model update commitment values. The alliance coordination node stores the credential verification results and update direction summaries of each participating node for consecutive rounds. It calculates node trust components based on the angle between the current update direction and the historical trust direction, changes in field completeness levels, and round continuity, and restricts the node trust components to the weight interval of the corresponding role. Then, it combines them with demand-side coverage or supply-side coverage to form aggregate weights.

[0012] Preferably, the node pairing table is generated by the alliance coordinating node based on the round participation list. Each participating node negotiates a random seed with the pairing node and generates a pair of random masks with opposite signs. At the same time, the random seed is fragmented and sent to the witness nodes in the round. When a participating node exits after submitting a mask update, the alliance coordinating node reconstructs the residual mask corresponding to the exiting node only after the witness node that has reached the recovery threshold submits a seed shard, and removes the residual mask from the aggregate. If the recovery threshold is not reached, the alliance coordinating node discards the current aggregation amount and regenerates the node pairing table with the surviving nodes.

[0013] Preferably, after each demand-side node obtains the resource category code, coarse-grained serviceable area code, and available time period code published by the merchant-side node, the demand tower generates demand embedding and demand constraint vectors locally, and each merchant-side node generates the corresponding resource supply embedding and supply constraint vectors locally by the supply tower. The participating node calculates the similarity score between the demand embedding and the supply embedding, quantifies the similarity score into a preset level, performs round-based salt hashing on the local candidate resource identifier, and submits only the hash identifier, score level, quantity limit, and time period intersection summary to the alliance coordination node.

[0014] Preferably, the alliance coordination node merges candidate vertices with the same hash resource identifier, establishes capacity edges based on the maximum number, establishes mutually exclusive edges based on the time period intersection summary, and sets vertex costs based on the score level submitted by the participating nodes. The alliance coordination node performs capacity constraint matching on the candidate conflict graph in batches according to demand. For unconfigured requirements, it retains the next level candidate vertices and resolves the problem. The resulting hash identifier configuration table is sent to the participating node holding the corresponding round salt value. The participating node restores the resource identifier locally and verifies the fulfillment status.

[0015] The owner alliance supply chain collaborative reconstruction system based on federated learning includes: alliance coordination nodes and owner-side nodes, property-side nodes and merchant-side nodes with identity authentication; The alliance coordination node is used to publish a unified feature semantic version and dual-tower model parameters, aggregate the privacy protection model updates submitted by each participating node according to the participation credibility and data distribution differences, and construct a candidate conflict graph based on the candidate resource scores and constraint summaries to solve the supply and demand configuration results. Each participating node is used to train the demand tower or supply tower corresponding to its role using locally stored supply and demand data, perform privacy protection processing on model updates, generate the candidate resource scores and constraint summaries locally, and receive the supply and demand configuration results. Each participating node is also used to convert local performance feedback into sample labels for subsequent training rounds.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. By training demand or supply towers at owner-side, property-side, and merchant-side nodes respectively, original preferences, locations, budgets, inventory, quotations, and fulfillment records are always stored in the local processing domain of the generated data. The alliance coordination node receives model updates processed by norm pruning and pairwise random masks, and cannot directly obtain participant samples from a single upload. A unified feature semantic version and a shared projection layer enable different nodes to form supply and demand embeddings with consistent dimensions and directions. The role adaptation layer retains local continuous fields at the participant nodes, without requiring the alliance side to establish a detailed data warehouse that can be reverse-associated. Pairwise masks cancel each other out in the aggregation volume. When a node exits, only the seed shard that reaches the recovery threshold eliminates the residual mask, allowing the joint model to continue to complete aggregation according to the authenticated identity in rounds where participating nodes change. Thus, the information connection required for cross-subject model updates is established by parameter aggregation, and the storage boundary of supply and demand samples is still controlled by each participant. This reduces the scope of long-term association records between sensitive owner information and merchant operating information on the central side, and ensures that feedback samples continuously enter the processing chain of subsequent training rounds.

[0017] 2. The trusted credentials binding round identifiers, semantic versions, sample time intervals, field completeness levels, gradient norm intervals, and model update commitment values ​​allows alliance coordinating nodes to determine aggregation weights based on credential continuity, update direction, and role coverage. This reduces interference from abnormal updates, outdated samples, or large data volumes from a single role on the shared model's direction. During the local inference phase, only candidate identifiers, score levels, quantity limits, and time period intersection summaries hashed by round salt are submitted. Supply and demand details and actual resource identifiers remain with the holding node. Alliance coordinating nodes can still use candidate conflict graphs to express shared inventory, overlapping time periods, and mutually exclusive service ranges, forming a cross-participant configuration table using capacity constraint matching. After the configuration table is returned, the node holding the round salt restores the resource identifiers locally and verifies the fulfillment status, ensuring that the similarity relationships generated by the joint model can be transformed into matching results that satisfy actual quantities and time period boundaries. This avoids the alliance side collecting complete inventory, order, and location records to handle resource competition. Attached Figure Description

[0018] Figure 1 Flowchart for trusted federated training and mask aggregation; Figure 2 Update the graph for shared parameters; Figure 3 To configure the evaluation chart. Detailed Implementation

[0019] In one embodiment, the owner alliance consists of an alliance coordination node, owner-side nodes, property management-side nodes, and merchant-side nodes. The alliance coordination node is responsible for maintaining participant identities, unified feature semantic versions, shared parameters of the dual-tower model, training rounds, and configuration tasks. Each participating node is responsible for storing local business data and performing calculations corresponding to its own role. The owner-side node stores category preferences, budget ranges, service periods, and performance feedback within the owner's authorized scope. The property management-side node stores community public needs, activity schedules, and regional service conditions. The merchant-side node stores product catalogs, availability, price changes, service boundaries, and performance records. The alliance coordination node does not establish a centralized repository containing these details. Instead, it publishes the same round of semantic versions and shared model parameters to nodes that have passed identity authentication. Each node trains the demand tower or supply tower locally and submits updates processed with privacy protection. After the aggregated model is redistributed, each node calculates candidate resource scores and constraint summaries locally. The alliance coordination node uses the summaries to construct a candidate conflict graph and returns the supply and demand configuration results. Performance feedback continues to be transformed into sample labels for the next round at the node that generated the feedback, forming a joint training, joint inference, and configuration feedback chain in which the original data remains in the local processing domain.

[0020] Specifically, the consortium coordinating node establishes a node record for each participant, bound to their organizational identity, role type, and public key certificate. The role type is limited to demand-side, supply-side, or property-side with the ability to act as a proxy for community public needs. Before joining a training round, a node signs the round request using its private key. After verifying the signature, certificate status, and role authorization scope, the consortium coordinating node generates a participant list for that round. The participant list only includes the node code, role type, semantic version, and communication public key, and does not include the number of samples, owner identifier, merchant operation fields, or order details. The consortium coordinating node then divides the demand-side coverage set and the supply-side coverage set according to the participant list, and writes the training round identifier, model summary, pruning boundary, node pairing table, and submission deadline status into the round task. Each participating node only loads the shared parameters if the semantic version stored locally is consistent with the round task. Nodes with inconsistent versions enter the mapping migration process instead of directly submitting an update. This ensures that the parameter structure, semantic space, and participant identity of each aggregation process have a verifiable correspondence.

[0021] In this embodiment, the unified semantic version consists of a resource category code, a demand intent code, a time period code, a spatial service code, and a fulfillment status code. The resource category code uses a hierarchical path to express the major category, subcategory, and service type of the resource. The demand intent code distinguishes between immediate procurement, scheduled services, periodic replenishment, and community group needs. The time period code converts the local time of each participant into the date type and service window agreed upon by the alliance. The spatial service code only represents coarse-grained community partitions or service grids. The fulfillment status code indicates statuses such as accepted, completed, rejected, unsubscribed, and pending confirmation. The alliance coordination node saves the migration relationship from the old code to the new code for each semantic version and publishes a summary. Each participant node maintains a local field mapping table, mapping the field names, enumeration values, and missing value rules in its own business system to the public semantic dictionary. The mapping table itself is only stored in the corresponding node. The alliance coordination node can only obtain the coverage level and version confirmation results of each public semantic code. Therefore, data from different sources can use the same semantic index in the model sharing layer, and local proprietary fields will not be uploaded due to semantic unification.

[0022] In a preferred embodiment, after receiving the owner's authorization record for data usage and training rounds, the owner-side node reads the demand events within the authorized scope from the local service entry. Each demand event consists of resource category, intent type, acceptable time period, coarse-grained service area, and local private fields. The local private fields may include budget quantile intervals, historical preference sequences, demand frequency, and feedback on performance status. The node converts the public parts into discrete identifiers according to the field mapping table, converts continuous values ​​into quantile interval codes according to the local distribution, writes missing fields into dedicated missing markers, and connects subsequent feedback of the same demand with local irreversible event codes. The property-side node constructs community public demand events using the same processing method, but its private branch reads the activity schedule, public space availability window, and aggregation quantity boundary. The demand tower only contacts the event code and private fields locally, and provides the shared parameter layer with the gradient formed by the encoder, without transmitting records that can restore specific owners, house locations, or budget details to the alliance coordination node.

[0023] Furthermore, the merchant-side node selects resource events within the authorized alliance scope from local inventory or service scheduling records. The public part includes resource category code, serviceable area code, available time period code, and fulfillment status code. The local private part includes price quantile interval, available quantity change, inventory turnover sequence, fulfillment duration, and cancellation reason code. The merchant-side node replaces the real product number or service number with a resource code that can only be restored locally, and maps the catalog entries to the public resource category according to the semantic version. The continuous operation field also forms a quantile interval code according to the local distribution, so that the numerical range of merchants of different sizes will not directly enter the shared space. The supply tower reads the public discrete identifier and the local private code to form a supply sample. The transaction record and the non-transaction record are connected according to the same resource code and time window. The merchant-side node retains the correlation between real inventory, price, and order. The alliance coordination node only receives model updates and candidate summaries in the later stages, so joint training does not require copying the complete business account.

[0024] In one embodiment, both the demand tower and the supply tower include a common semantic encoding layer, a role adaptation layer, and a shared projection layer. The common semantic encoding layer establishes embedding tables for resource category codes, intent codes, time period codes, spatial service codes, and performance status codes, and sets trainable indexes according to semantic versions. The role adaptation layer is stored locally on the participating nodes. The demand-side role adaptation layer performs gating fusion of budget quantiles, preference sequences, and demand frequency codes with the common embeddings. The supply-side role adaptation layer performs gating fusion of price quantiles, availability changes, and performance sequence codes with the common embeddings. The property-side role adaptation layer adds the community aggregation quantity and public service window code to the demand representation. The shared projection layer maps the gating fused different role vectors to the same dimension. The model updates uploaded by the participating parties only cover the common semantic encoding layer and the shared projection layer. The parameters, input dimensions, and local statistics of the role adaptation layer are not included in the uploaded data, so that the alliance can share the representation rules of supply and demand relationships without copying the private feature structures of each node.

[0025] Preferably, the role adaptation layer uses intra-node quantile encoding for continuous fields instead of using a unified numerical boundary. Participating nodes first calculate the quantile splitting position of each continuous field on the authorized samples, and then convert the current value into a quantile number and a relative position within the interval. The gating network generates fusion coefficients based on common semantic embedding, quantile number, missing data marker, and record freshness. The fusion coefficients are only used to adjust the proportion of local private encoding entering the shared projection layer. The original continuous values ​​are not written into the shared parameters. If a merchant's price change range is different from other merchants, the two nodes can still express their relative positions through the same resource category code and price quantile number. If a demand node lacks a budget field, the missing data marker causes the gating network to rely on category, time period, and historical feedback. During training, only the corresponding private branches are calculated for the actual fields to avoid mistaking missing values ​​for zero and changing the direction of common embedding, while preserving the local processing capabilities required for the differences in data patterns of different nodes.

[0026] In this embodiment, the alliance coordination node issues an anchor vector identifier without real business records for each resource category code. Each participating node generates anchor input locally based on the anchor identifier. The demand tower and supply tower respectively calculate the projection vector of the anchor input. The local training objective includes sample pairing loss and anchor direction constraint. The sample pairing loss brings the demand embeddings that have been fulfilled closer to the supply embeddings, and keeps the pairs that have been displayed but not accepted within the same time window spaced apart. The anchor direction constraint makes the demand tower and supply tower form comparable projection directions for the same resource category. The anchor input does not contain owner, merchant, inventory or quotation information, but only defines the reference position in the common semantic space. After each participating node completes the anchor calculation locally, it only incorporates the gradient of the shared layer into the model update. The role adaptation layer continues to retain the node-specific field relationships. Therefore, the aggregated model issued by the alliance coordination node can be loaded by both the demand side and the supply side without requiring both sides to have the same original field set.

[0027] In one embodiment, each participating node reads newly added records formed since the deadline of the previous round according to the training round identifier, and reads historical records compatible with the current semantic version from the local reservation area. Positive samples consist of demand resource pairs that have been accepted and whose performance status meets the local confirmation rules. Comparison samples consist of resources with the same demand that are visible within the same time window but have not been traded. Nodes set different labels for unsubscribe or rejection records according to the local reason code, and do not directly interpret rejections caused by inventory failure as negative preferences. The sample time weight is determined by the time interval between the record and the current round, and the field completeness is determined by the proportion of effective labels of the common semantic fields. When performing batch partitioning locally, nodes keep records with the same event code in the same data partition to prevent subsequent feedback from entering the training partition and the local verification partition at the same time. After training, nodes only save the shared layer gradient summary, verification loss interval, and participation credentials, and do not generate upload files containing the original samples.

[0028] Specifically, local training begins with the shared parameters issued by the consortium coordinating node. Participating nodes freeze semantic indexes that are not within the scope of this round's update, perform demand embedding or supply embedding calculations on local samples, and calculate the gradient of the shared projection layer based on the pairing relationship. Nodes calculate the norm of each gradient vector in the shared layer. When the norm exceeds the pruning boundary in the round's task, it is scaled according to the ratio of the boundary to the actual norm; otherwise, it is kept as is. The pruned gradient is written to a temporary update area constrained by the round identifier. Nodes also calculate a summary of the deviation between the current gradient direction and the gradient direction of their previous reliable round. This summary only records the interval to which the included angle belongs and does not save the complete historical gradient. The field completeness level, sample time interval, and validation loss interval are also represented using discrete levels. Since the pruning boundary is consistent for all participants in this round, subsequent aggregation will not change the overall parameter scale due to the update magnitude of a single node exceeding the agreed range. Node private samples remain in the local training area.

[0029] Furthermore, when generating trusted credentials, each participating node organizes the node ID, role type, training round identifier, semantic version, sample time interval, field completeness level, pruned gradient norm interval, gradient direction summary, and model update commitment value into the credential text. The model update commitment value is calculated from the pruned gradient, round random salt value, and node private random variable. The credential text is signed by the node's private key and submitted together with the mask update. The consortium coordinating node uses the node certificate to verify the signature and checks the round identifier and semantic version. Then, it compares the commitment value with the commitment summary registered by the node during the mask negotiation phase. The credential only exposes the discrete level and cryptographic commitment. The consortium coordinating node cannot read the specific number of samples or field values ​​from it. The verification results and direction summaries of consecutive rounds are saved as the node's trusted state, used to distinguish between stable updates submitted according to the protocol, updates with semantic version errors, and updates that deviate significantly from the historical direction.

[0030] Please refer to Figure 1 In a preferred embodiment, the consortium coordinating node generates a node pairing table based on the authenticated list of participants in this round, ensuring that each participating node establishes a mask relationship with at least two nodes from different organizations. Each paired node negotiates a random seed using a temporary key and generates paired random masks with opposite signs according to the node code. One side of the same pair of nodes adds the mask to the pruned gradient, while the other side subtracts the corresponding mask from the pruned gradient. The vector dimension of all paired masks is consistent with the dimension of the shared parameter update. The participating node submits its own masked update to the consortium coordinating node and simultaneously splits the random seed used for exit recovery into several parts and encrypts them before sending them to the witness nodes specified in the pairing table. The consortium coordinating node can only obtain the mask update and seed sharding commitment. It cannot read the random seed if the exit recovery condition is not met. The paired masks of all normally participating nodes cancel each other out after summing, and the aggregated input thus retains only the combined amount of the pruned gradient.

[0031] In this embodiment, before aggregation, the alliance coordinating node calculates the node trust component, role coverage component, and data drift component. The node trust component comes from the credential signature verification, commitment consistency, and update direction intervals of consecutive rounds. The role coverage component is used to control the contribution boundaries of the demand side and the supply side in the shared parameters, avoiding a certain role from occupying all update directions due to the large number of participating nodes. The data drift component is determined based on the distance between the node's current round public semantic code distribution digest and its own historical distribution digest. The distribution digest only contains the intervalized category frequency level. The alliance coordinating node combines the three components into a normalized aggregation weight, and uses the aggregation weight to calculate the shared parameter update after mask cancellation. The calculation relationship is expressed as the following formula, where each symbol maintains the same meaning throughout the text.

[0032] , ; in, This represents the shared parameters at the start of round t. This represents the shared parameters after aggregation. Here, represents the learning rate per round, N represents the number of nodes that pass validation and enter aggregation, and i and j both represent the aggregation node indices. This represents the gradient of node i after pruning and mask cancellation in round t. This represents the corresponding normalized aggregate weights. Represents the trusted components of a node. Indicates the role coverage component. This represents the data drift component, and 'e' represents the base of the natural index, obtained when three verified nodes... , , When the values ​​are 0.6, 0.3, and 0.1 respectively, the normalized values ​​are... The values ​​are 0.6, 0.3, and 0.1 respectively, and the alliance coordinating nodes are grouped into three groups according to this ratio. If one of the nodes The weight of the node increases while other components remain unchanged. The weight of the node decreases with the exponential term and is supplemented by the normalized total by the other verified nodes. Therefore, the direction of parameter update is still determined by the combined gradient of the current round that is reliable and whose role coverage meets the boundary.

[0033] Please refer to Figure 2 , Figure 2 The horizontal axis represents the dimension number of the shared parameters, ranging from 1 to 6. The vertical axis represents the parameter value of the corresponding dimension after aggregation, ranging from approximately -0.29 to 1.00. The black solid line corresponds to the formula symbol. The update results for each dimension are shown in the curve. , , and The combined effect forms a visual illustration of how the alliance coordinating node combines the pruning gradients of each participating node according to the normalized aggregate weights after mask cancellation.

[0034] from Figure 2 As can be seen, the values ​​of the first and sixth dimensions are relatively high, while the values ​​of the second and fifth dimensions show a negative decline, indicating that the influence of node gradient direction, learning rate, and aggregation weights on different parameter dimensions is not consistent. The changes in the third and fourth dimensions are relatively gradual, reflecting that the updates of shared semantic representations in this interval are relatively stable; the fifth dimension is the lowest, indicating that this dimension has formed a significant reverse correction after this round of trusted aggregation. Figure 2 With the formula right Corresponding to the weighted effect, it is emphasized that the updated shared parameters are not the result of a single node, but rather an aggregated result formed by verifying nodes under the joint constraints of trusted components, role coverage components, and data drift components.

[0035] Preferably, the consortium coordinating node does not directly trust the level claim in the credential. Instead, it maps the claim to verifiable facts within the round, verifies the semantic version against the signed round task, verifies the gradient norm interval against the commitment unsealing proof, verifies the role type against the node certificate, and performs an interval consistency check between the updated direction digest and the aggregated historical digest. If the credential signature is incorrect, the commitment value is inconsistent, or the semantic version is expired, the consortium coordinating node excludes the corresponding mask update from the current round of aggregation and notifies the witness node to enter the residual mask processing. If the direction digest deviates from the historical interval but the signature and commitment are correct, the node will not be directly excluded, but will be processed through a larger... Achieve a smaller Meanwhile, it remains in observation status in subsequent rounds. If the number of verified nodes on either the demand or supply side falls below the round requirement, the alliance coordinating node will not publish new shared parameters, but will instead retain them. And re-recruit the corresponding role nodes to avoid the model update involving only one side of the samples from disrupting the common semantic direction of the demand tower and the supply tower.

[0036] In one embodiment, a participating node may fail to complete round confirmation due to connection interruption after submitting its mask. In this case, the node's paired random mask cannot completely cancel out the opposite mask of its paired node. The consortium coordinating node identifies the witness node involved in the residual mask based on the node pairing table and sends a recovery request with a round signature to the witness node. After verifying the exit status, recovery request, and seed shard commitment, the witness node submits its locally stored encrypted shard. Only when the recovery threshold specified in the round task is reached will the consortium coordinating node reconstruct the seed corresponding to the exiting node and generate a residual mask, removing the residual mask from the mask aggregation. If the recovery threshold is not reached, the consortium coordinating node discards the current aggregation, deletes the temporary mask material for this round, and regenerates the participating list and node pairing table with nodes that are still online and have passed authentication. The recovery process only processes the random seed and mask and does not request the gradient or local sample of the exiting node.

[0037] Furthermore, after the shared parameters are updated, the alliance coordinating node becomes... The model summary is calculated, and the model summary, semantic version, participating role coverage status, and aggregation round are written to the release record. After downloading the model, participating nodes first verify the signature and summary of the release record, and then load the shared parameters into the local demand tower or supply tower. The role adaptation layer parameters maintain the local state of the previous round, and use the local verification partition to check whether the anchor direction and verification loss are within the node's own allowed range. If the shared model is incompatible with the local role adaptation layer, the node retains the previous version of the model and reports the compatibility status without sample details. The alliance coordination node decides whether to roll back the shared parameters based on the compatibility status of multiple nodes. Nodes that load normally bind the model version with the local mapping table version. Subsequent candidate calculations can only use the successfully bound combinations to avoid the discrete identifiers generated by the old semantic mapping from entering the embedding space defined by the new shared parameters.

[0038] In this embodiment, when candidate calculation is initiated by the demand side, the alliance coordination node only publishes the resource category code, coarse-grained serviceable area code, available time period code, and round candidate task identifier that have been authorized and publicly disclosed by the merchant side. It does not publish the actual inventory, price, product number, or merchant order. The owner-side node or property-side node maps the local pending demand to the public identifier of the current semantic version, and inputs the budget quantile, preference sequence, demand frequency, or community aggregation quantity into the local role adaptation layer. The demand tower generates demand embedding and demand constraint vector. The demand constraint vector includes quantity demand, acceptable time period set, coarse-grained service area, and local access status. Each field is connected by a local event code in the candidate task. The alliance coordination node cannot see the owner identity corresponding to the event code. The merchant-side node selects resources with matching semantic codes and available status from the local resource directory according to the candidate task identifier, and generates supply embedding and supply constraint vector for each resource.

[0039] Specifically, the supply constraint vector includes the upper limit of resource quantity, the set of fulfillable time periods, the set of service areas, and the local qualification status. The actual quantity, specific service address, and qualification documents are stored on the merchant-side node. The merchant-side node only provides a coarse-grained constraint summary in the candidate calculation session agreed upon with the demand-side node. After obtaining the session representation of the supply embedding, the demand-side node calculates the similarity value between the demand embedding and the supply embedding locally, and checks whether there is a time period intersection, regional intersection, and quantity allocability relationship between the demand constraint vector and the coarse-grained supply constraint. Resources that do not meet any of the preconditions do not enter the candidate set. Resources that meet the conditions are converted into score levels according to the similarity value. The level boundary is released by the alliance coordination node with the model version, but the similarity value itself and the demand embedding do not leave the demand-side node, and the merchant-side node does not upload the supply embedding or the complete supply constraint vector to the alliance coordination node.

[0040] In a preferred embodiment, demand-side nodes and merchant-side nodes establish candidate correspondences through session codes forwarded by the alliance coordination node. Merchant-side nodes attach a random salt value to the real resource identifier and calculate a hash resource identifier. The random salt value is only stored in the merchant-side node holding the real resource and the authorized demand-side session. The demand-side node submits the hash resource identifier, score level, demand quantity, time period intersection summary, and service area intersection summary, which have passed the local precondition check, to the alliance coordination node. The time period in the summary uses a common time period code set, the area uses a coarse-grained service code, and the demand quantity can be represented according to the minimum configuration unit allowed by the alliance. The submission record does not contain demand event code, real resource identifier, price details, or location details. The alliance coordination node distinguishes different candidate batches through round task identifiers. The same real resource uses different random salt values ​​in different rounds to form different hash identifiers, reducing the possibility of connecting candidate records across rounds to form an operational time series.

[0041] In one embodiment, after receiving the candidate digest, the alliance coordination node first merges the candidate vertices according to the round of tasks and hash resource identifiers. The same hash resource identifier corresponds to a supply resource capacity group. Each demand candidate forms a candidate vertex connecting the demand batch and the capacity group. The alliance coordination node establishes capacity edges based on the maximum number of submissions from merchant-side nodes, establishes mutually exclusive edges based on the relationship that the time period intersection digests overlap and resources cannot be fulfilled simultaneously, and establishes range constraint edges based on the service area intersection digests and the merchant-side concurrent service rules. The score level is written into the cost of the candidate vertex. If multiple demands compete for the same capacity group, the candidate conflict graph expresses the total allocation boundary through capacity edges. If the same service personnel or the same device can only perform one service in the overlapping time period, the candidate conflict graph prevents the corresponding vertices from being selected simultaneously through mutually exclusive edges. The graph structure only saves the hash identifier and digest relationship, and does not save the owner and merchant details used to generate these relationships.

[0042] Furthermore, the alliance coordinating node performs capacity constraint matching on the candidate conflict graph, constructs configuration targets based on score levels and conflict degrees, and the calculation relationship is expressed as the following formula. The formula is used to describe the evaluation of feasible configurations in a candidate batch. In actual solution, a constraint is also imposed on the candidate variables connected by mutually exclusive edges, which cannot take non-zero values ​​at the same time.

[0043] ; Where Q represents the configuration evaluation value of the current candidate batch, A represents the number of demand batches, K represents the number of hash resource capacity groups, a represents the demand batch index, and k represents the resource capacity group index. This represents the selection factor for allocating demand batch a to resource capacity group k; in discrete matching, it is either 0 or 1. This indicates the score level of the corresponding candidate vertex. The conflict degree represents the normalized number of conflicting edges connecting candidate vertices. This represents the constraint coefficient of conflict degree in configuration evaluation. This indicates the number of configurations required for batch a. This represents the maximum number of resource capacity groups k that can be allocated, for example, two demand batches. All are 1 and belong to the same resource capacity group When it is 1, it corresponds to two You cannot have 1 at the same time. If one of the candidates is 1, higher and If the value is low, the solver selects that candidate and moves another requirement to the next level of candidate set.

[0044] Please refer to Figure 3 , Figure 3 The horizontal axis represents the candidate number, ranging from 1 to 6. The vertical axis represents the candidate contribution value formed when the candidate is included in the current configuration evaluation, ranging from approximately 0 to 4.9. The black solid line corresponds to the formula symbol. , , and The calculation relationship between them, where candidate contributions are mainly determined by score levels. Deduct conflicting constraints Later obtained, and in When the valid selection quantity is obtained, the configuration evaluation of the current candidate batch is carried out.

[0045] from Figure 3 As can be seen, the contribution values ​​of candidates 1 and 5 are close to 4.9, indicating that their scores are high and their conflict levels have a relatively small impact, making them priority candidates for feasible configuration in the current batch. The contribution value of candidate 4 is approximately 2.0, significantly lower than its neighbors, indicating that although it is qualified as a candidate, it is more affected by the number of conflicting edges or constraint penalties. Candidates 2, 3, and 6 are in the middle range and can be used as alternative solutions under constraints of capacity, time period, or service range. Figure 3 Corresponding to the summation structure of Q in the formula, the graph shows the differences in the local contributions of different combinations of a and k to the overall evaluation, providing an intuitive basis for subsequent connected component solutions and the transfer of unconfigured requirements to the next level candidate set.

[0046] Preferably, capacity constraint matching adopts a batch solution method. The alliance coordination node first adds the highest score level candidate with clear time period intersection and service area intersection to the current subgraph, performs a feasibility check on capacity edges and mutually exclusive edges, and then calculates Q for each competing connected component. When there is no shared capacity or mutual exclusion relationship between connected components, they can be solved independently. If a certain demand batch does not obtain a configuration in the current subgraph, the alliance coordination node retains its next score level candidate and expands the corresponding connected component. The expansion process does not change the configuration of the already satisfied capacity edge and does not conflict with the newly added vertex. If all levels cannot form a feasible configuration, the alliance coordination node returns the unconfigured status and the next candidate task time to the demand side node, without returning the capacity, score or conflict reason details of other participants. The configuration table only contains the demand session code, hash resource identifier, configuration quantity and common time period code, for the local node to continue to restore and confirm.

[0047] In this embodiment, the alliance coordinating node sends the configuration table to the demand-side node holding the corresponding demand session code and the merchant-side node holding the corresponding random salt value. The merchant-side node uses the random salt value to restore the real resource identifier in the local candidate resource set and reads the real availability status, real inventory and service schedule again. The demand-side node restores the demand event locally and verifies the authorization status and acceptable time period. After both parties pass, they each use their node private key to sign the configuration confirmation digest. The alliance coordinating node only sets the configuration status to pending fulfillment after receiving confirmation from both parties. If the merchant-side real-time inventory has changed, the merchant-side node returns the resource invalidation status but does not upload the real inventory. The alliance coordinating node releases the corresponding capacity and selects the next candidate for the unconfigured demand from the candidate conflict graph. If the demand authorization has been withdrawn, the demand-side node returns the withdrawn status and terminates the demand session. The entire restoration and real-time verification process does not require the alliance coordinating node to obtain the real resource number or specific owner identity.

[0048] Furthermore, the performance results are converted into training labels locally by the participating nodes that generated the records. Records that have been confirmed by both parties and have been fulfilled form positive pairing labels. Records canceled due to immediate resource failure form supply status labels instead of negative demand preferences. Records that are actively rejected due to demand and have normal resource status can form comparison labels locally. Records canceled due to time period conflicts update local constraint branches without directly changing the public resource category embedding. Nodes connect feedback to the original candidate sessions based on the round task identifier in the configuration table. The real resource identifier and demand event code are still restored by local mapping. The alliance coordination node only receives the configuration status summary to close candidate tasks. Each participating node reads the newly added labels in the next training round and constructs training samples according to semantic version, sample time, and field completeness, so that the joint model can absorb new relationships in the performance chain, while avoiding mixing different cancellation reasons into the same negative label and changing the shared projection direction.

[0049] In a preferred embodiment, the alliance coordinating node sets up periodic training and event-triggered training based on model release records and candidate task status. Periodic training is initiated within the round window agreed upon by the alliance, while event-triggered training is initiated when multiple nodes report changes in the public semantic distribution level. The reported content only includes the frequency level of resource category codes or demand intent codes, excluding subject identifiers and original counts. The alliance coordinating node compares the current round's distribution summary with the historical summaries of each node to obtain... When issuing round tasks, the semantic indexes that need to be updated are specified. Indexes that have not changed can be frozen. Participating nodes still perform forward computation on complete local samples, but only upload updates are formed for specified shared parameters. If a newly added merchant node does not have a historical trusted state, its A restricted initial interval is used and updated round by round with continuous credential verification. If a node is absent for a long period and then rejoins, the semantic mapping and model summary are re-verified, and the role coverage component before the absence is not directly used.

[0050] In this embodiment, exception handling revolves around semantic consistency, update integrity, and configuration recoverability. When a participating node discovers that its local mapping table cannot handle new semantic codes, it submits a version migration request to the consortium coordinating node and retains the previous model, without generating gradients using unknown codes. When the consortium coordinating node discovers that the mask update length is inconsistent with the shared parameter structure, it rejects the corresponding submission and initiates residual mask recovery before entering aggregation. When the commitment value is inconsistent with the credentials, the update of the corresponding node is not entered. If the set and node trust status are recorded as verification failure; if the time period code or region code in the candidate summary does not belong to the current semantic version, the candidate vertex will not enter the conflict graph and will be re-encoded by the original node; if the node cannot restore the hash resource identifier after the configuration table is returned, the alliance coordination node will only release the relevant capacity and cancel the session, without requiring the node to provide a real identifier for central investigation, and each abnormal path will clean up temporary materials with the round task or candidate task as the boundary, and the registered model release record and performance status summary will remain unmixed.

[0051] Specifically, the audit information stored by the alliance coordination node includes node certificate status, round task summary, semantic version summary, model release summary, credential verification results, scope of aggregated participating roles, candidate task status, and configuration confirmation summary. The audit information does not include local field mapping tables, gradient plaintext, random seeds, role adaptation layer parameters, demand embedding, supply embedding, real resource identifiers, or owner identities. Participating nodes store their own authorization records, local training sample sources, mapping table versions, role adaptation layer parameters, mask negotiation materials, and candidate restoration relationships, and delete temporary random seeds and candidate session salt values ​​according to the round end status. The alliance coordination node can verify whether a model was formed by an update that meets the identity, semantic, and role coverage conditions based on the audit summary, and can also verify whether a configuration has been confirmed by the nodes on both sides. However, it cannot reconstruct owner preferences, merchant inventory, or specific order chains solely based on the central record. Data control boundaries and collaborative computing chains are carried by different records.

[0052] In a complete operational example, two owner-side nodes, one property management-side node, and three merchant-side nodes join the same training round after identity authentication. The consortium coordinating node publishes the current semantic version and dual-tower shared parameters. Demand-side nodes map periodic replenishment demands, community public procurement demands, and performance feedback to demand samples locally. Merchant-side nodes map available resources, service hours, and performance records to supply samples. After each node completes shared layer training, gradient pruning, credential signing, and pairwise masking, it submits an update. The consortium coordinating node verifies the credentials and... , and form Update after mask cancellation The results are then distributed, and each demand-side node calculates the candidate scores locally, submitting only the hash identifier and constraint digest. The alliance coordination node constructs a candidate conflict graph and selects the configuration that satisfies the capacity and time period boundaries based on Q. The merchant-side node restores the resources locally and confirms the real-time status. The owner-side or property-side node confirms the demand authorization, and the performance results are finally converted into the next round of labels on their respective nodes.

[0053] In one embodiment, participating nodes perform an authorization scope judgment before reading any local samples. The owner-side authorization record is bound to at least the data purpose, available field category, alliance scope, and failure status. The merchant-side authorization record is bound to at least the resource directory scope, business field category, eligible demand type, and failure status. The node writes the authorization judgment result into the local sample selector. Records not within the authorization scope cannot enter the public semantic mapping, role adaptation layer, or shared gradient calculation. When authorization is withdrawn after the start of a round, the node stops the training tasks that have not yet been submitted and clears the temporary gradient of this round. If the mask update has been submitted, the node completes the exit confirmation required by the protocol, so that the alliance coordinating node eliminates the residual mask through witness sharding. The formed aggregate does not contain the update plaintext that can be used to locate the node's sample independently. The authorization withdrawal in the candidate session is returned to the withdrawal status by the demand-side node and the random salt value mapping is deleted. The alliance coordinating node only releases the candidate capacity and closes the session, without saving the local identifier of the withdrawal subject. The authorization boundary thus simultaneously constrains the training sample entry, the candidate calculation entry, and the feedback label entry.

[0054] In this embodiment, semantic version migration begins with the alliance coordinating node publishing a migration summary between the old and new resource category codes, demand intent codes, time period codes, spatial service codes, and fulfillment status codes. Participating nodes locally copy the current field mapping table to form a version to be verified. For local verification partitions, they simultaneously use the old and new mappings to generate a common identifier and compare anchor direction, missing marker ratio, and mappable record ratio. Version confirmation is only signed when the new mapping meets the internal consistency condition of the node. Local enumeration values ​​that cannot be matched are automatically merged into the processing set and similar semantic codes are not automatically included. The alliance coordinating node collects the version confirmation status of each role. Only after both the demand and supply sides meet the round coverage condition is the new semantic version set as a trainable version. During the migration, the old model remains bound to the old mapping. The new model copies the parameters of the unchanged index from the old shared parameters and initializes the newly added index using anchor vectors. When each node submits a new version update for the first time, it writes a migration marker in the participation trust credentials, enabling the data drift component to distinguish between changes in real business distribution and changes in semantic index.

[0055] Furthermore, the consortium coordinating node retains the model summary and role coverage status of the previous trusted version for each shared parameter release, but does not save individual node updates. When participating nodes locally verify the new model, they check the common anchor projection order, the pairing interval of completed performance samples, and the output range of the role adaptation layer. If multiple demand-side nodes or multiple supply-side nodes report the same incompatible state, the consortium coordinating node suspends the candidate task from using the new model, restores the model version pointer to the previous trusted version, and initiates a revision round with the semantic index to which the incompatible state belongs as the range. The revision round only updates the common semantic embeddings and shared projection layer connections that have shifted, while other indexes remain frozen. Nodes continue to use local samples to complete revision training and credential binding. Rollback and revision records are associated through the model summary without copying local verification samples. The score levels generated by the old trusted version in the candidate session are still configured according to the original version. Sessions that have not yet started will wait for the revised model to be released and then recalculate, avoiding the mixing of the same candidate conflict graph with the level boundaries generated by two model versions.

[0056] In a preferred embodiment, the handling of ties in the candidate conflict graph employs a reproducible task priority key. This task priority key is generated by the request session submission time interval, retry rounds, and a hashed session ID, and does not include owner identity, merchant identity, or real resource identifier. The alliance coordinating node coordinates between the two candidate vertices. and When all are the same, the order of entering the feasible subgraph is determined according to the task priority key. Demands that were not configured in the previous round due to insufficient capacity will have their retry order added in the next round, but they cannot cross the time period intersection, service area, and capacity boundary. If adding a candidate causes both ends of the mutual exclusion edge to be 1 at the same time, the solver retains the candidate with the higher task priority key and moves the other candidate to the next level set. If the resource capacity group of the candidate fails in the local confirmation stage, the original task priority key is retained with the demand session and used to replace the candidate solution. The hash resource identifier is updated to the corresponding value of the next candidate. The processing order can therefore be reviewed from the candidate task summary, and the central node does not need to know the sensitive business fields that form the priority order.

[0057] Specifically, each participating node sets up a training area, a verification area, a credential area, and a candidate session area for its local data. The training area stores authorized samples and labels; the verification area stores local records that will not be included in the current round of gradient calculation; the credential area stores round signature materials and historical direction intervals; and the candidate session area stores temporary mappings between random salt values, hash identifiers, and real resources or demand events. Access boundaries for the four areas are established using round identifiers or candidate task identifiers. Training tasks cannot read the real identifier mappings of candidate sessions, and candidate tasks cannot read historical gradients or credential private keys. After a round is completed, the node retains the model version, mapping table version, and audit summary, and deletes temporary gradients, paired random seeds, and salt value mappings of closed sessions. The consortium coordinating node correspondingly deletes mask aggregation temporary quantities and unused recovery shards, retaining only the model release summary, candidate task status, and configuration confirmation summary. When a participating party leaves the consortium, the consortium coordinating node revokes its certificate and stops issuing subsequent tasks. Existing shared parameters do not contain separable single-node sample records, and the leaving node does not need to transfer its local training area or management database to the consortium side.

[0058] In this embodiment, the owner alliance supply chain collaborative reconstruction system based on federated learning consists of an alliance coordination node and authenticated owner-side nodes, property-side nodes, and merchant-side nodes. The alliance coordination node is used to publish a unified feature semantic version and dual-tower model parameters, aggregate the privacy-preserving model updates submitted by each participating node according to the participation credibility and data distribution differences, and construct a candidate conflict graph based on candidate resource scores and constraint summaries to solve the supply and demand configuration results. The owner-side nodes and property-side nodes are used to train the demand tower using locally retained demand data, and the merchant-side nodes are used to train the supply tower using locally retained supply data. All participating nodes are used to perform gradient pruning, credential generation, pairwise masking, local candidate calculation, and configuration confirmation, and convert local performance feedback into sample labels for subsequent training rounds. The system composition and method processing chain correspond item by item. The alliance coordination node undertakes cross-node state coordination without replacing the participating nodes in reading the original business details.

[0059] In a preferred embodiment, the property-side node can simultaneously assume the responsibilities of community public demand proxy and alliance boundary access. However, the two responsibilities use different node codes, credential keys, and local data areas. The public demand proxy only reads the aggregated demands formed by community rules, and the boundary access only forwards the encrypted round tasks, mask updates, and candidate digests. It does not decrypt the business content of the participants during the forwarding process. The merchant-side node can also be composed of multiple store local nodes and complete the same role aggregation within the merchant first. The aggregation results within the merchant still need to be pruned, credential bound, and paired masks according to the alliance round. The alliance coordinating node regards it as an certified supply-side participant. When adding a community or merchant to the network, only semantic mapping, role adaptation layer, and node certificate need to be established. The local field structure of other participants is not changed. The public semantic layer, shared projection layer, secure aggregation chain, and candidate conflict graph chain continue to operate according to the same round boundary.

Claims

1. A method for collaborative restructuring of the owner alliance supply chain based on federated learning, characterized in that: include: The alliance coordination node publishes a unified feature semantic version and dual-tower model parameters to the authenticated owner-side node, property-side node, and merchant-side node; Each participating node trains the corresponding demand tower or supply tower based on the locally retained supply and demand data, and submits the updated model after privacy protection processing. The alliance coordination node updates and distributes the updated dual-tower model based on the aggregation model according to the participation credibility and data distribution differences. Each participating node uses the updated dual-tower model to generate candidate resource scores and constraint summaries locally. The alliance coordination node constructs a candidate conflict graph based on the candidate resource scores and the constraint summary, solves the supply and demand configuration results, and returns them to the corresponding participating node. Each participating node will convert its local performance feedback into sample labels for the next training round.

2. The method for collaborative restructuring of the owner alliance supply chain based on federated learning according to claim 1, characterized in that, The unified feature semantic version includes a public semantic dictionary consisting of resource category code, demand intent code, time period code, spatial service code, and performance status code; The owner-side node and the property-side node convert demand records into discrete identifiers corresponding to the public semantic dictionary based on the local field mapping table, and input the budget, location and preference fields that are only identifiable locally into the private feature branch of the demand tower. The merchant-side node converts the product catalog, availability and service boundary into discrete identifiers based on the local field mapping table, and inputs the price, inventory changes and fulfillment records into the private feature branch of the supply tower. Each private feature branch and the public semantic branch are integrated locally into a fixed-dimensional embedding.

3. The method for collaborative restructuring of the owner alliance supply chain based on federated learning according to claim 1, characterized in that, Each participating node reads the newly added local samples according to the round identifier issued by the alliance coordination node, constructs training samples with local positive performance records and uncompleted records paired by time windows, and calculates the local gradient in the shared parameter layer of the dual-tower model. Each participating node generates a participation credibility credential based on the sample time decay value, the completeness of the common semantic field, and the gradient direction deviation between the previous and next rounds. The participation credibility credential is bound to the commitment value of the model update, and norm pruning is performed on the local gradient before submission, so that the update amount of different participating nodes is within the same pruning boundary published by the alliance coordination node.

4. The method for collaborative restructuring of the owner alliance supply chain based on federated learning according to claim 1, characterized in that, Each participating node generates a pair of random masks based on the node pairing table within the round, and the clipped local gradient is superimposed with the pair of random masks to form a mask update; The alliance coordination node verifies the consistency of the participation trust credentials and commitment values, determines the aggregation weight according to the demand-side coverage, supply-side coverage, data drift degree and update direction consistency, and performs weighted aggregation on the verified mask updates. After the local candidate scores are submitted, the alliance coordination node establishes the candidate conflict graph with the candidate resource identifier as the vertex and the shared inventory, overlapping service periods or mutually exclusive fulfillment ranges as the edges, and generates the configuration result under the supply and demand quantity constraints.

5. The method for collaborative restructuring of the owner alliance supply chain based on federated learning according to claim 2, characterized in that, Both the demand tower and the supply tower include a common semantic encoding layer, a role adaptation layer and a shared projection layer. The common semantic encoding layer generates category embeddings according to the unified feature semantic version. The role adaptation layer is stored in the corresponding participant node and does not enter the model update. The role adaptation layer performs gated fusion of the quantile interval encoding of the local continuous field with the category embedding. The shared projection layer maps the fusion result to the alliance common embedding space. Each participating node constrains the common embedding space locally using the anchor vector corresponding to the resource category code of the same round, so that the demand embedding and the supply embedding use the same dimension and the same semantic direction.

6. The method for collaborative restructuring of the owner alliance supply chain based on federated learning according to claim 3, characterized in that, The trusted credentials for participation include digital signatures generated by participating nodes for round identifiers, semantic versions, sample time intervals, field completeness levels, gradient norm intervals, and model update commitment values. The alliance coordination node stores the credentials verification results and update direction summaries of each participating node for consecutive rounds. It calculates node trust components based on the angle between the current update direction and the historical trusted direction, changes in field completeness levels, and round continuity, and restricts the node trust components to the weight interval of the corresponding role. Then, it combines them with demand-side coverage or supply-side coverage to form aggregate weights.

7. The method for collaborative restructuring of the owner alliance supply chain based on federated learning according to claim 4, characterized in that, The node pairing table is generated by the alliance coordinating node based on the round participation list. Each participating node negotiates a random seed with the pairing node and generates a pair of random masks with opposite signs. At the same time, the random seed is fragmented and sent to the witness nodes in the round. When a participating node exits after submitting a mask update, the alliance coordinating node reconstructs the residual mask corresponding to the exiting node only after the witness node that has reached the recovery threshold submits a seed shard, and removes the residual mask from the aggregate. If the recovery threshold is not reached, the alliance coordinating node discards the current aggregation amount and regenerates the node pairing table with the surviving nodes.

8. The method for collaborative restructuring of the owner alliance supply chain based on federated learning according to claim 7, characterized in that, After each demand-side node obtains the resource category code, coarse-grained serviceable area code, and available time period code published by the merchant-side node, the demand tower generates demand embedding and demand constraint vectors locally, and each merchant-side node generates the corresponding resource supply embedding and supply constraint vectors locally by the supply tower. The participating node calculates the similarity score between the demand embedding and the supply embedding, quantifies the similarity score into a preset level, performs round-based salt hashing on the local candidate resource identifier, and submits only the hash identifier, score level, quantity limit, and time period intersection summary to the alliance coordination node.

9. The method for collaborative restructuring of the owner alliance supply chain based on federated learning according to claim 8, characterized in that, The alliance coordination node merges candidate vertices with the same hash resource identifier, establishes capacity edges based on the maximum number, establishes mutually exclusive edges based on the intersection summary of the time periods, and sets vertex costs based on the score levels submitted by the participating nodes. The alliance coordination node performs capacity constraint matching on the candidate conflict graph in batches according to demand. For unconfigured requirements, it retains the next level candidate vertices and resolves the problem. The resulting hash identifier configuration table is sent to the participating node holding the corresponding round salt value. The participating node restores the resource identifier locally and verifies the fulfillment status.

10. A supply chain collaborative restructuring system for owner alliances based on federated learning, characterized in that: include: Alliance coordination nodes, as well as owner-side nodes, property-side nodes, and merchant-side nodes that have been verified; The alliance coordination node is used to publish a unified feature semantic version and dual-tower model parameters, aggregate the privacy protection model updates submitted by each participating node according to the participation credibility and data distribution differences, and construct a candidate conflict graph based on the candidate resource scores and constraint summaries to solve the supply and demand configuration results. Each participating node is used to train the demand tower or supply tower corresponding to its role using locally stored supply and demand data, perform privacy protection processing on model updates, generate the candidate resource scores and constraint summaries locally, and receive the supply and demand configuration results. Each participating node is also used to convert local performance feedback into sample labels for subsequent training rounds.

Images