Efficient Knowledge Transfer in Federated Recommendation for Joint Venture Ecosystem

Thank you for providing such valuable comments. We have carefully addressed these critical comments, and responses have been given one by one.

W1&2. Performance analysis and choice of varying $K$ values.

R1&2: Thank you for this valuable comment. In Table 7, we present the impact of different $K$ values on model performance. When the value of $K$ is too small, the client fails to migrate sufficient knowledge from the limited number of similar users, resulting in negligible performance improvement. Conversely, when too much user knowledge is migrated, it may introduce redundant information, which can negatively affect the model's judgment.

The choice of the hyperparameter $K$ is determined through a simple parameter search, and the corresponding results are presented in Table 4. However, by examining Table 7, we observe that for the score prediction task, the selected $K$ values are roughly between 1/4 to 1/2 of the total number of users, while for the top-$k$ recommendation task, $K$ is around 1/50. This reveals some basic patterns. Although the value of $K$ does have an impact on our method, FR-JVE still outperforms other baselines within the observed performance variation. We plan to further explore the relationship between $K$ and data distribution in future work.

W3. Concerns about the chart presentation.

R3: Thank you for your careful review. This was a mistake on our part. We have corrected the order of figure references in the manuscript to ensure they appear in the proper sequence. We will also carefully proofread the whole manuscript to avoid such issues in the future.

Q1. More details about the bridge funcition.

A1: Thanks for this question. In FR‑JVE, each client uses a lightweight bridge function $\phi_k$—a single linear layer to translate the server’s aggregated rating‑preference vectors into its own local preference space without ever exposing raw embeddings. Before training, clients distill their user–item interactions into fixed preference vectors $P^i_k$ via a small inversion network and upload these to the server; the server then aggregates them and returns each client’s aggregated $P^i_{k,t}$. During each communication round, clients update their item embeddings using standard matrix‑factorization objectives and simultaneously train $\phi_k$by minimizing the squared error $||\phi_k(P^i_{k,t})-P^i_k||^2$. At inference time, $\phi_k$ maps other clients’ aggregated preferences into the local space, enabling efficient top‑K neighbor search for final rating predictions—thereby achieving cross‑client knowledge transfer with strong privacy guarantees. The limitation of the bridge function mainly lies in the choice of its network architecture. Since we conduct experiments on commonly used datasets, we can empirically adopt a linear function for the mapping. However, real-world datasets are often much more complex, which requires additional experiments and reference to relevant literature to ensure an appropriate choice of the bridge function. This may introduce extra computational overhead due to parameter search.

Q2. Employment of FR-JVE in other downstream tasks like sequential recommendation.

A2: Thanks for this question. FR-JVE is designed to address the unique challenges present in joint venture ecosystems, where each client represents a business group (rather than individual users) and user/item sets are partially overlapping. Despite being tailored for this setting, the underlying principles of FR-JVE offer promising generalization potential to broader federated recommendation scenarios.

1. Adaptability of the Rating Preference Mechanism FR-JVE introduces a novel rating preference representation derived from model inversion with frozen user gradients, which avoids direct sharing of user embeddings and thus preserves privacy. This form of knowledge representation is generalizable and can be employed in other settings where clients are individual users, mobile devices, or even regional service centers. The idea of distilling user preferences without exposing raw data or embeddings can be beneficial wherever privacy is a concern.
2. Bridge Function for Domain Adaptation The bridge function in FR-JVE enables mapping between local and global preferences, effectively facilitating cross-domain knowledge transfer. This mechanism draws inspiration from cross-domain recommendation systems and can be applied in other contexts where domain heterogeneity (e.g., different user behaviors across platforms or regions) poses a challenge. Thus, FR-JVE could be extended to federated recommendation settings involving highly Non-IID data.

while FR-JVE is motivated by joint venture ecosystems, its core ideas make it well-suited to generalize across other federated recommendation scenarios that require balancing performance with user privacy. Future work could explore its adaptation to cold-start problems and sequential recommendation scenarios with highly skewed client distributions.

Thank you very much for this professional review. The critical comments have been addressed carefully, and responses have been given one by one.

W1. Limitation of bridge function design.

R1: Thank you very much for this helpful comment. The limitation of the bridge function mainly lies in the choice of its network architecture. Since we conduct experiments on commonly used datasets, we can empirically adopt a linear function for the mapping. However, real-world datasets are often much more complex, which requires additional experiments and reference to relevant literature to ensure an appropriate choice of the bridge function. This may introduce extra computational overhead due to parameter search. Here, we expolre the bridge function with a more complex architecture and experiments show that the model performance will not improve significantly. A complex bridge function may lead to overfitting, especially when the amount of transferred knowledge is limited or noisy. In contrast, a simple linear network is often sufficient to capture the essential relationships between users across clients, providing a better balance between generalization and model complexity.

W2. Robustness and training cost of rating preference.

R2: Thank you for this valuable comment. In our paper, the rating preference is generated using a simple linear function, which incurs relatively low training cost. Moreover, in our federated recommendation scenario, the participating clients are subsidiaries that typically possess sufficient computational resources to handle such training. Most importantly, the distillation of rating preference is performed locally and takes place before federated training, meaning it can be executed at any time and in any setting. In the context of federated recommendation, we generally focus only on the computational overhead during the federated training stage.

In Section 4.4, we prove that the user rating preference will not pose privacy risk. First, the rating preference is distilled by each client from the local dataset without uploading gradients. Then, the server only can reveive the rating preference, which is the linear combination of the column vectors of item embedding $V_k$ using the elements of $p_k$ as the coefficients. The input of the model is the frozen user representation and item representation. Under the premise that gradients are not uploaded and the sizes of embeddings and rating preferences are inconsistent, attackers are unable to obtain user information with the rating preference.

Regarding collaborative filtering (matrix factorization algorithm), it serves as the most widely used and foundational algorithm in the research of RS and FRS (similar to the role of FedAvg in FL). Since our article does not focus on the field of security and privacy, there is no need for us to optimize this backbone algorithm. Instead, we only need to ensure that our proposed user rating preference can migrate more effective user information without introducing additional privacy risks.

Q1. Concerns about conflicting preferences between different subsidiaries.

A1: Thanks for this question. In FR‑JVE, each client uses a lightweight bridge function $\phi_k$—a single linear layer to translate the server’s aggregated rating‑preference vectors into its own local preference space to align the preferences between different subsidiaries. Before training, clients distill their user–item interactions into fixed preference vectors $P^i_k$ via a small inversion network and upload these to the server; the server then aggregates them and returns each client’s aggregated $P^i_{k,t}$. During each communication round, clients update their item embeddings using standard matrix‑factorization objectives and simultaneously train $\phi_k$by minimizing the squared error $||\phi_k(P^i_{k,t})-P^i_k||^2$. At inference time, $\phi_k$ maps other clients’ aggregated preferences into the local space, enabling efficient top‑K neighbor search for final rating predictions—thereby achieving cross‑client knowledge transfer with strong privacy guarantees.

Q2. Performance degradation with increasing subsidiaries.

A2: Thanks for this question. In this paper, we focus on the federated recommendation scenario under a joint venture ecosystem. Each participant is a subsidiary, possessing a large amount of user and item information, which naturally leads to overlapping data. Essentially, this setting corresponds to cross-silo federated learning, where the number of participants is relatively small, but the data distribution across parties is complex. If we instead involve a large number of participants ($C > 20$), the setting becomes that of cross-device federated learning, where each participant typically represents an individual user with limited local data for training. This is inconsistent with the challenges we aim to address in this work. To better validate our approach, we conduct parameterized experiments on the number of participants $C$, selecting three different values on two datasets. Experimental results demonstrate the effectiveness of our method.

Q3. More details about model inversion techniques.

A3: Thank you for your thoughtful suggestion. Model inversion techniques are indeed a key concept, and we understand that readers who are less familiar with this area may find it difficult to follow without sufficient background. Model inversion is a type of privacy attack where an adversary attempts to reconstruct sensitive input data from the outputs or parameters of a trained machine learning model. The core idea is that, given access to a model, one can exploit the correlations learned during training to infer information about the training data. We use this technique to train a robust model to obtain the rating preference. We will revise the manuscript to include more detailed descriptions and relevant references to help readers better understand how model inversion works and why it is important in our method.

We thank you very much for providing the positive comments. In the following, we give detailed responses to each review.

W1. Concerns about the theoretical analysis.

R1: Thanks a lot for raising this concern. In Section 4.4, we prove that the user rating preference will not pose privacy risk. First, the rating preference is distilled by each client from the local dataset without uploading gradients. Then, the server only can reveive the rating preference, which is the linear combination of the column vectors of item embedding $V_k$ using the elements of $p_k$ as the coefficients. The input of the model is the frozen user representation and item representation. Under the premise that gradients are not uploaded and the sizes of embeddings and rating preferences are inconsistent, attackers are unable to obtain user information with the rating preference.

Regarding collaborative filtering (matrix factorization algorithm), it serves as the most widely used and foundational algorithm in the research of RS and FRS (similar to the role of FedAvg in FL). Since our article does not focus on the field of security and privacy, there is no need for us to optimize this backbone algorithm. Instead, we only need to ensure that our proposed user rating preference can migrate more effective user information without introducing additional privacy risks.

W2. Combination of FR-JVE with other baselines.

R2: Thank you for this helpful comment. The key of FR-JVE is to allow each client transfers more common knowledge from other clients with a distilled user's rating preference from the local dataset. Since this rating preference is unrelated to the backbone of federated recommendation algorithms, we can integrate it with other basic algorithms. In our paper, we employed the most common collaborative filtering (matrix factorization algorithm, FedMF). Here, we will supplement the integration with well-known FedNCF and pFedRec algorithms (two recommendation algorithms using linear function systems). Experimental results demonstrate that our algorithm can be combined with any basic federated recommendation algorithm to enhance performance.

W3. Validation on real datasets.

R3: Thank you for your valuable comment. We fully agree that conducting experiments on real data would be highly meaningful. However, such experiments are currently very time-consuming and involve significant resource costs. To the best of our knowledge, existing FedRS studies have not yet tested on real-world data either. In this work, we followed the experimental setup commonly used in existed methods and made some appropriate adjustments. We will strive to explore experiments on real joint venture data in future work to further advance research in federated recommendation systems.

W4. Concerns about the abbreviation consistency.

R4: Thank you for pointing this out. You are absolutely right and this was a mistake on our part due to a typo. "FRS" and "FedRS" refer to the same concept, namely the Federated Recommendation System. We have now corrected this in the manuscript with FedRS. We will also thoroughly proofread the whole manuscript to prevent similar issues in the future.

Q1. Inpororation of FR-JVE and lightweight DP.

A1: Thank you for this question. In our paper, we propose the method FR-JVE that allow each client transfers privacy-friendly common knowledge from other clients <u>without using LDP algorithm</u> but with a distilled user's rating preference from the local dataset. Furthermore, we also provide experiments applying differential privacy to our rating preference for reference. However, our method itself can guarantee user information privacy. Considering that differential privacy can affect performance, we did not additionally use it. Section 4.4 presents the theoretical analysis of this aspect.

Q2. Perofrmance under highly skewed data distributions.

A2: Thank you for this question. In the experimental setup of Table 7, we assume 5 participants and 50% shared users. Each participant's local users account for only 1/9 of the entire dataset, which already represents highly skewed data distributions. Since the number of shared users is determined by the number of participants, increasing the number of participants can further enhance data heterogeneity. We conduct experiments with different numbers of participants and show that FR-JVE achieves competitive performance under highly heterogeneous data distributions.

Thank you for your careful review and valuable comments. In the following, we give point-by-point responses to each comment.

W1. Concerns about the ablation study.

R1: Thank you for this constructive suggestion. We have included an ablation study experiment regarding the bridging function (BF) and rating preference (RP) in Table 5, and the results confirm the effectiveness of each module in our method. Experimental results verify the effectiveness of both modules. Specifically, the RP module plays a more important role in our method, as using only item embeddings to transfer local knowledge is insufficient for training a satisfactory recommendation model. This also aligns with the motivation of this paper. In a joint venture ecosystem, the overlap of users/items across different subsidiaries makes it difficult for the model to learn personalized knowledge from item embeddings. The BF module is designed to better align the knowledge from different rating preferences. Without the BF module, our method can still perform a simple extraction of knowledge based on rating preferences, which leads to some performance improvement compared to using only the RP module.

W2. Concerns about the scalability and efficiency.

R2: Thank you for raising this concern. In this paper, we focus on the federated recommendation scenario under a joint venture ecosystem. Each participant is a subsidiary, possessing a large amount of user and item information, which naturally leads to overlapping data. Essentially, this setting corresponds to cross-silo federated learning, where the number of participants is relatively small, but the data distribution across parties is complex. If we instead involve a large number of participants ($C > 20$), the setting becomes that of cross-device federated learning, where each participant typically represents an individual user with limited local data for training. This is inconsistent with the challenges we aim to address in this work. To better validate our approach, we conduct parameterized experiments on the number of participants $C$, selecting three different values on two datasets. Experimental results demonstrate the effectiveness of our method.

W3. Concerns about clarity and organization.

R3: Thank you for raising this concern. We apologize if Section 4 seems difficult to understand for you. However, to better describe our method, we first outlined the preliminaries of federated recommendation, cross-domain recommendation, and local differential privacy. Subsequently, we started with the application of the traditional CDR method EMCDR in FL, analyzed the shortcomings of the EMCDR+DP algorithm, and finally proposed the FR-JVE algorithm.

For the bridge function module: In FR‑JVE, each client uses a lightweight bridge function $\phi_k$—a single linear layer to translate the server’s aggregated rating‑preference vectors into its own local preference space without ever exposing raw embeddings. Before training, clients distill their user–item interactions into fixed preference vectors $P^i_k$ via a small inversion network and upload these to the server; the server then aggregates them and returns each client’s aggregated $P^i_{k,t}$. During each communication round, clients update their item embeddings using standard matrix‑factorization objectives and simultaneously train $\phi_k$by minimizing the squared error $||\phi_k(P^i_{k,t})-P^i_k||^2$. At inference time, $\phi_k$ maps other clients’ aggregated preferences into the local space, enabling efficient top‑K neighbor search for final rating predictions—thereby achieving cross‑client knowledge transfer with strong privacy guarantees.

Q1. Effects of privacy budgets on FR-JVE and optimization approach.

A1: Thank you for this question. In our paper, we propose the method FR-JVE that allow each client transfers privacy-friendly common knowledge from other clients <u>without using LDP algorithm</u> but with a distilled user's rating preference from the local dataset.

To investigate our joint venture ecosystem, we first explore the feasibility of CDR method EMCDR but find it will pose privacy risk by directly sharing the user embedding. Then, like most FL and RS research, we apply the LDP algorithm to EMCDR, enhancing the privacy protection. However, it fails to achieve a balance between user privacy and recommendation performance (Table 1). In Table 1, we use Laplacian noise and add noise to the user embedding parameters. Since each client represents a subsidiary with a large user base, it is neither algorithmically feasible nor practical for the client to distinguish between different users and apply separate LDP algorithms.

Therefore, we abandon the use of the LDP algorithm for user privacy protection in this paper and instead propose our user rating preference method to transfer privacy-preserving yet informative knowledge. We have theoretically and experimentally proven the effectiveness of this new method in federated recommendation systems.

Q2. Generalization of FR-JVE to other recommendation scenarios.

A2: Thank you for this question. FR-JVE is designed to address the unique challenges present in joint venture ecosystems, where each client represents a business group (rather than individual users) and user/item sets are partially overlapping. Despite being tailored for this setting, the underlying principles of FR-JVE offer promising generalization potential to broader federated recommendation scenarios.

1. Adaptability of the Rating Preference Mechanism FR-JVE introduces a novel rating preference representation derived from model inversion with frozen user gradients, which avoids direct sharing of user embeddings and thus preserves privacy. This form of knowledge representation is generalizable and can be employed in other settings where clients are individual users, mobile devices, or even regional service centers. The idea of distilling user preferences without exposing raw data or embeddings can be beneficial wherever privacy is a concern.
2. Bridge Function for Domain Adaptation The bridge function in FR-JVE enables mapping between local and global preferences, effectively facilitating cross-domain knowledge transfer. This mechanism draws inspiration from cross-domain recommendation systems and can be applied in other contexts where domain heterogeneity (e.g., different user behaviors across platforms or regions) poses a challenge. Thus, FR-JVE could be extended to federated recommendation settings involving highly Non-IID data.

while FR-JVE is motivated by joint venture ecosystems, its core ideas make it well-suited to generalize across other federated recommendation scenarios that require balancing performance with user privacy. Future work could explore its adaptation to cold-start problems and sequential recommendation scenarios with highly skewed client distributions.